(In reply to Johann Hofmann [:johannh] from comment #2)
When you're backdating your time we compare against the build date and should be able to determine clock skew independently of remote settings.
But OCSP errors will start appearing after just one or 2 days skew, and the build date can be many weeks or even months ago.
I think this is just a dupe of bug 1491498
1491498 is about where we show the error, and showing it for OCSP errors; this bug is about how we fetch the data that we use to determine if the clock is skewed, and that potentially failing due to similar OCSP errors (but in the background, so no errors are displayed). So no, I don't think they're dupes at all...
(In reply to Ethan Glasser-Camp (:glasserc) from comment #1)
I'm not sure I'm the best person to ask, but I'll do my best.
- I think your analysis is correct. It seems like https://searchfox.org/mozilla-central/source/browser/actors/NetErrorChild.jsm#473-485 is consulting the Remote Settings pref. This was added in https://hg.mozilla.org/mozilla-central/rev/d65b48650a68a678f5d4c2aabca7e539e647e3d4. This pref is only set on successful polling of the latest-changes endpoint (https://searchfox.org/mozilla-central/source/services/settings/remote-settings.js#231). If the fetch fails because of TLS error, I guess we would never set it. I'm guessing we would report this using uptake telemetry as a network error. The absence of this pref would mean that we would never show the nice "your clock is wrong" message. However, as far as I know, this check only happens when connecting fails in content, so other situations would fail regardless of the presence of this pref.
- OCSP Stapling seems to be enabled on all Cloudfront distributions, so yes, we're probably affected.
OK, good to know.
- I'm not really sure what to do about it. When this fails, I imagine it happens during the TLS handshake, so we don't even make a request so we don't have a response, so I don't see how we could access the
Age headers. Is there a way to tell our network stack to make a request while disregarding a certain specific kind of TLS failure?
I don't know. Dana?
I know for captive portal detection we've started using non-TLS requests to avoid issues. I don't know if that makes sense specifically for clock skew (and signing them separately with a longer-validity, non-public-web-PKI trusted cert or something). I mean, rolling your own crypto is always bad, except when necessary. Not sure "standard" TLS will work for us here...
I don't see anything we can do on the server side since the client doesn't send its timestamp and I don't think we could make Cloudfront serve backdated certs or anything like that.
Yeah, I imagine we have very little control over cloudfront...
I'm also not sure how to write an automated test for this -- it seems like I'd have to stand up a HTTPS server and generate a future-dated cert. Do we have anything like that available in the test suite?
Our test infrastructure has an http server and some weird TLS wrappers and certs for it. So in principle, yes, but when I last had to touch it at this kind of level it was not super straightforward.