1314470 - cert error page not showing clock-skew warning

Status: RESOLVED FIXED

(Firefox :: Security, defect, P3)

Description

[Justin Dolske [:Dolske]]

Asa mentioned he's still commonly seeing Twitter reports of people who can't load SSL pages due to their system clock being wrong. We fixed bug 712612 not that long ago, and it's in Firefox 49, so one would hope this is less common...

We tried to get the error to show by setting his system clock back in time, but nothing came up. I noticed the fix in bug 712612 is guarded by a check to services.kinto.clock_skew_seconds (now services.blocklist.clock_skew_seconds), but even adding that pref with a large value wasn't working.

I also can't trigger it on my desktop. I set a breakpoint in onCertErrorDetails() in content.js, but that's not being hit at all. So seems like this code isn't working? D: The receiveMessage() that should be driving that isn't getting hit either, but I didn't trace it beyond that.

Comment 1

[Johann Hofmann [:johannh]]

Ok after some digging I think found the issue. It's very likely (at least it was the case for me) that the errors you are getting have the error code MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE which was simply forgotten in my original implementation.

Back then I filed bug 1281129 to deal with this and the issue was resolved by a contributor on the fly in bug 1282455, which we should have uplifted to 49 but failed to do so.

Dolske, can you please:

- Verify that the error code where the time message isn't shown for you is MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE
- Go to https://expired.badssl.com/ and verify that you indeed get the time message (this page produces SEC_ERROR_EXPIRED_CERTIFICATE, you can also set your time forward in time instead of backwards, which produces SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE for valid certs)
- Verify that it works fine using 50 or later.

Thank you!

Bug 1281129 landed in 50 and is not that far away from going to stable so I'd say we can close this bug if my assumptions are correct.

There is also bug 1267229 which was started by a contributor to deal with the case of missing services.blocklist.clock_skew_seconds by using the build date to determine clock skew. Since it's been inactive for some time I'll finish it up now.

Comment 2

[Johann Hofmann [:johannh]]

> Bug 1281129 landed in 50 and is not that far away from going to stable so I'd say we can close this bug if my assumptions are correct.

I meant bug 1281129. Too many bugs.

Comment 3

[Justin Dolske [:Dolske]]

One of the errors I'm getting is SEC_ERROR_OCSP_FUTURE_RESPONSE. This is unfortunately easy to see by clicking the "Learn More" link on a certerror page, whereupon https://support.mozilla.org fails to load. :)

I think I'm able to confirm that the errors I was getting when filing this were due to MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE, and that it's working on Nightly. But this is a bit of a pain -- it seems like we cache something, as I was getting inconsistent results unless I started with a new profile. (ie, I initially couldn't even reproduce my original report, as something happened such that I was correctly getting the "wrong time" error page). And of course with a new profile I forgot to manually set services.blocklist.clock_skew_second, so that was confusing me too.

When does services.blocklist.clock_skew_second normally get set? Seems like it doesn't happen for a while, which would result in a new Firefox user with a bad clock not getting the "wrong time" flavor of the error page... Maybe we can kick off a kinto request ASAP on first run, or when a cert error happens and we notice there's no clock skew stored yet? [The triggering error page would still have the generic error, but that's ok since I'd assume someone with this problem is going to end up trying again on a few sites.]

Comment 4

[Johann Hofmann [:johannh]]

(In reply to Justin Dolske [:Dolske] from comment #3)
> One of the errors I'm getting is SEC_ERROR_OCSP_FUTURE_RESPONSE. This is
> unfortunately easy to see by clicking the "Learn More" link on a certerror
> page, whereupon https://support.mozilla.org fails to load. :)
> 

Yeah, the fact that people might not be able to visit the "Learn More" link was discussed but nobody has come up with a better solution so far. We could make a bug, maybe someone has an idea how to solve this (without copying the whole troubleshooting page into m-c).

> I think I'm able to confirm that the errors I was getting when filing this
> were due to MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE, and that it's
> working on Nightly. But this is a bit of a pain -- it seems like we cache
> something, as I was getting inconsistent results unless I started with a new
> profile. (ie, I initially couldn't even reproduce my original report, as
> something happened such that I was correctly getting the "wrong time" error
> page).

Something like bug 1299403? Though that bug only affects if the pref gets set or not.

Generally speaking, if you manually set services.blocklist.clock_skew_second to a large positive or negative number (more than 60 * 60 * 24) and navigate to any cert error page with a time issue, it should _always_ show the warning, starting from Firefox 50. If not, that's definitely a bug I'd like to hear about. :)

This is also what's being tested in http://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_aboutCertError.js#110.

> When does services.blocklist.clock_skew_second normally get set?

I'm not 100% sure, mgoodwin probably knows.

> Seems like it doesn't happen for a while, which would result in a new Firefox user with
> a bad clock not getting the "wrong time" flavor of the error page... Maybe
> we can kick off a kinto request ASAP on first run, or when a cert error
> happens and we notice there's no clock skew stored yet? [The triggering
> error page would still have the generic error, but that's ok since I'd
> assume someone with this problem is going to end up trying again on a few
> sites.]

Kinto pings are also HTTPS, which wouldn't work if the user had a broken time from the start (assuming they somehow already downloaded Firefox via HTTP without noticing anything strange), hence bug 1267229.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

P3 in the hope that bug 1299403 was/is the real issue here.

Comment 6

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 7

[Johann Hofmann [:johannh]]

Let's resolve this(?) As fixed by bug 1282455. There are other bugs which handle the imprecision of the warning, but it should be shown now.