Posts and replies

For future reference - after taking various respondents advice and disabling OCSP in my browser, this problem has not recurred in a week of regular use.

@mhoye eh, I think that's a bug. slow ocsp shouldn't cause the browser to think that https isn't available...

@dana @mhoye

Yeah, what Dana said. OCSP was notoriously unreliable that browsers learned to ignore lack of response.

Unless you cracked open about:config and stumbled on the pref to turn that into a hard fail. If you did, now you know why that more-secure setting isn't the default

@dveditz @dana It didn't make my life difficult enough that I can't turn it back on, see if it starts again.

Everything I have in my prefs that says OCSP is set to default, but admittedly my setup is otherwise pretty eccentric.

If it is a bug, how would I go about best capturing it for filing?

@mhoye @dveditz I would probably just describe the behavior you saw and how turning off ocsp fixed it. a packet trace could help, but since it's intermittent, you'd have to be capturing continuously until you encountered it...

@dana
@mhoye

Dana: Would capturing the certs of the affected sites help any? We might see some pattern in which OCSP responders are affected or some feature of the certs themselves that triggers different handling

If you view the certificate in Firefox the "about:certificate" URL contains the cert chain and could be mailed to us. I doubt that's the problem; this would be more of a Hail Mary "might as well rule it out" thing

@dveditz @mhoye potentially, if it's a particular responder that's slow (although it's maybe unlikely we'll hit the same one, since we're not in the same area)

@dana @dveditz I'm also locked into DoH on a Canadian provider, but I guess I don't understand how DoH and OCSP intersect/interact, if at all.

@mhoye @dana

Is your DoH also slow?

Are you using "HTTPS-Only", and not explicitly specifying the scheme? An explicit https:// URL should eventually give you a generic "site not available" timeout, or a specific error code. But if we're trying to upgrade and don't get a response "soon enough" we might show that error asking if you want to try unencrypted when you're using HTTPS-Only.

Slightly more complicated: we wait a bit, then send an http: request to see if the site responds to that. If we find out the site is quick to reply to http and _still_ hasn't replied to https we assume it doesn't have https. A slow or flaky OCSP might occasionally bump initial https connections over the timeout while not affecting the http probe.

You could lengthen the timeout by changing dom.security.https_only_fire_http_request_background_timer_ms

You can turn off the http probe entirely with dom.security.https_only_mode_send_http_background_request

security.OCSP.timeoutMilliseconds.soft is shorter than the time we wait before sending the http probe, but maybe combined with a slow DoH responses for both the initial site and then the OCSP server it's going over.

@dveditz @dana

My OCSP theory seems to be incorrect? But Firefox has an update pending....

Edit: updated Firefox and now I cannot reproduce.

(Y'all I know this isn't your fault but "Firefox stops working right when there's an update pending" has been haunting me for at least a decade.)

@dana @dveditz no, my understanding is that’s limited to Linux. This is a cross platform problem that we have never solved.