Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
tech.lgbt is one of the many independent Mastodon servers you can use to participate in the fediverse.
We welcome all marginalized identities. This Mastodon instance is generally for folks who are LGBTQIA+ and Allies with an interest in tech work, academics, or technology in general.

Administered by:

Server stats:

2.9K
active users

tech.lgbt: AboutStatusProfiles directoryPrivacy policyTerms of service

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.4+glitch

Public

Anyone else out there getting intermittent "HTTPS not available" errors on sites where HTTPS is definitely available, on sites where you're confident the team doesn't make that grade of mistake?

Public

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...

Feb 22, 2025, 11:43 PM·Public
0boosts·1favorite
Public

@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 🙂

Public

@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?

*
Public

@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...

Public

@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

Public

@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)

Public

@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.

*
Public

@mhoye @dveditz well, DoH would cause one more OCSP request, but after that, it would be cached, so I doubt that's the issue

Public

@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.

Public

@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.)

*
Public

@mhoye @dveditz is that the "firefox has been updated out from under you, so you have to restart the main process so it can launch the right content processes" issue?

Public

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

Public

@mhoye @dana @dveditz We are aware of slow DoH in Canada. It appears to be a bug in the server software that is being investigated by the vendor.

Public

@lars @dana @dveditz OK, thank you - I'll wait it out. Is there a bug number I can follow?

Public

@mhoye @dana @dveditz There isn't a bug number, this is being discussed on the partner mailing list for the most part.

Public

@lars @dana @dveditz Thank you. If it helps at all, I'm seeing it a few times a day now; my ISP is TekSavvy, if that matters.

One thing is that waiting briefly and reloading doesn't seem to help, which suggests there's also a caching problem on my end. Is there anything I can do about that?

(also: why does about:prefs say "cloudflare" when my settings say CIRA?)

Public

@mhoye @dana @dveditz Would you email necko@mozilla.com

Explore
About