Open Bug 1352720 Opened 5 years ago Updated 3 years ago

Endless loop while connecting to https://id.avast.com/ when OS clock is (a few minutes) ahead of server time

Categories

(Web Compatibility :: Desktop, defect, P5)

x86_64
Windows 7
defect

Tracking

(Not tracked)

People

(Reporter: epinal99-bugzilla2, Unassigned, NeedInfo)

References

Details

(Keywords: regression, webcompat:site-wait, Whiteboard: [sitewait])

Issue reported on the French support board:
https://forums.mozfr.org/viewtopic.php?f=5&t=132520

STR:
1) Make your OS clock a few minutes ahead of the real time (supposed to be the server time, I guess)
2) Open https://id.avast.com/
3) Log in with these (guest) credentials:
Email: mozfr@monmail.fr.nf
Pwd: azerty123!

Result: endless loop while connecting to Avast's user account, loading never ends (infinite spinning circle).

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ca7974ddccc11ec992834b8563d381d16b56ee42&tochange=8cc4907776c85b5f57c1778bdd5b2a4ad8eb8055

amy — Bug 368964 - Cookie expires attribute should be absolute, not relative to server time. r=ehsan
Amy, could you check this regression issue, please. Is it expected? If yes, may Avast's team fix it on its server side?
Blocks: 368964
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(amchung)
Keywords: regression
Too late for firefox 52, mass-wontfix.
Assignee: nobody → amchung
Whiteboard: [necko-active]
Hi Loic,
I can't reproduce, would I confirm the reproducing steps to you?
"Make your OS clock a few minutes ahead of the real time.", It means I change my OS clock to the time zone in French?

Thanks!
Flags: needinfo?(amchung) → needinfo?(epinal99-bugzilla2)
My Windows clock is synchronized with time.windows.com (UTC+2), and I just changed the clock to be 2 minutes ahead of the real time.

If it's not reproducible with your time zone, try to switch to UTC+2 + 2-3 minutes ahead.
Flags: needinfo?(epinal99-bugzilla2)
Hi Loic,
I found I can reproduce when I switched to UTC+2 + 2-3 minutes ahead, but the behavior is normal when I switched to UTC+2.
And expiry time is base on client time on nsCookieService::GetExpiry(), do you confirm the expiry time of cookie base on server time?
Flags: needinfo?(epinal99-bugzilla2)
Hi,
I do not know if the attached screenshot can be useful, but the avast server cookie seems to expire 10 seconds after UTC + 2.
If we set 1 minute more in our local time -> endless loop while connecting to Avast's user account
http://pix.toile-libre.org/upload/original/1492238157.jpg
Yes, I think the issue is related to both cookies "mySessionId" and "myLocalIdSession" from the domain ".my.avast.com".
When you connect to my.avast.com with normal local time (UTC+2), these cookies are set with a expiration date UTC+2 + ~1 min ahead.

If you modify the OS clock to be UTC+2 + 30/60 sec ahead, it's still OK to connect. But if the clock is ahead 120 sec, connection fails and these cookies are not created.

So I'd say the server time is UTC+2, and expiration date set by the server for these 2 cookies is UTC+2 + 1 min. Any OS clock with time > (UTC+2 + 1 min) will fail to connect.
Flags: needinfo?(epinal99-bugzilla2)
It remains to be seen why with an old version of firefox, there are no problems
I have tested with an old portable version and the expiration is not fixed, it is always more or less than 1 minute but on the local time of the computer nor on absolute value UTC+2, we can advance by 23 hours without it Blocks access.
Expiration time increases step by step independently of world time.
So , I don't know what thing Avast's team will have to fix on its server side ?
Can be what you name by regression issue ?
According to bug 368964 comment 14, the cookie expiration behaviors of Firefox and other browsers are as below:

Firefox(before 51): relative to server time
Chrome: relative to server time
Safari: absolute time

According to bug 368964 comment 15, using absolute time seems to be a correct behavior.

Does this issue happen in Safari browser?  If not, a possible reason could be:
Safari uses absolute time, but there is one thing different from Firefox(mentioned in bug 368964 comment 14) that "Safari would be saving the expiration of cookie as absolute time, but it didn't confirm the expiration of cookie earlier than client time that still saves this cookie to database.".
I am not sure saving already expired coookies to database is meaningful, but if that fixes the problem and doens't bring side-effects, maybe we can consider that.  What do you think, Amy?
Flags: needinfo?(amchung)
[Test]
1. Purpose: modify code to let the behavior of Firefox same as Safari.
   Try to comment the code about confirming the expiry time when setting cookie,
   let the cookie which already expired still can save to database.
2. Purpose: confirm the behavior of this issue on Safari.
   Test this bug on Safari.

[Result]
1. [Fail]
   i.  The cookie "mySessionId" and "myLocalIdSession" saved in database.
   ii. The situation of this bug still occurs.
2. [Fail]
   This bug also occurs on Safari.

Does the server side confirm which cookies expire?
Flags: needinfo?(amchung) → needinfo?(epinal99-bugzilla2)
Sorry, but I don't know how to do that and I'll not test more. I reported the bug, it's out my scope now.
As you're able to reproduce on your side, I consider you can debug without my help.
Flags: needinfo?(epinal99-bugzilla2)
According to comment 10, the issue occurs when using Safari browser too.

Old behavior -- relative to server time
  Firefox(before 51)
  Chrome

New behavior -- absolute time
  Firefox(51 and beyond)
  Safari

This seems to be web compat issue.
Component: Networking: Cookies → Desktop
Flags: needinfo?(etsai)
Product: Core → Tech Evangelism
Version: 51 Branch → Firefox 51
See Also: → 1357127
Whiteboard: [necko-active] → [necko-active][needsdiagnosis]
Per-discussion with :swu, current implementation on Gecko is correct (absolute time). So it would worth to contact avast to know if we can change server behavior or not.
Flags: needinfo?(etsai)
Too late for 54, let's see if we can fix it in 55.
Whiteboard: [necko-active][needsdiagnosis] → [necko-active][needscontact]
Whiteboard: [necko-active][needscontact] → [needscontact]
Assignee: amchung → nobody
Component: Desktop → General
Product: Tech Evangelism → Web Compatibility
Version: Firefox 51 → unspecified
Component: General → Desktop
Product: Web Compatibility Tools → Tech Evangelism
Priority: -- → P5
Pinging Lukas from Avast to let them know about this issue.
Flags: needinfo?(rypacek)
Whiteboard: [needscontact] → [sitewait]
Product: Tech Evangelism → Web Compatibility

See bug 1547409. Moving webcompat whiteboard tags to keywords.

You need to log in before you can comment on or make changes to this bug.