certificate revocation, OCSP and CRLite

[fxbrit]

what we have atm

• CRLite: mode 2, so we trust all CRLite reponses (revoked and not-revoked).
• OCSP:
  • used when CRLite cannot provide an answer;
  • stapled if possible;
  • hard-fail.

some data

• how often crlite is used vs ocsp stapled vs ocsp in Nightly 107. CRLite covers ~ 62% of the checks, the rest uses some variation of OCSP.
• how often using CRLite mode 3 helps detecting a false positive in Nightly 105. this happens ~ 83% of the time.

proposal

• keep CRLite: mode 3 is default to avoid false positives but mode 2 minimizes OCSP checks. either is good IMO.
• keep OCSP: stapling is default so we don't need to do anything about that.
• get rid of OCSP hard-fail: it appears more secure on the surface level but it has usability issues and it's not a real solution.

this should also be what TB does moving forwards.

1212 could be moved to section 5500, 1211 could be moved to 6000 waiting for mozilla to eventually get rid of OCSP once CRLite is mature enough.

[Thorin-Oakenpants]

The point of hard-fail is BECAUSE soft fail is not a real solution. No way am I flipping that (1212). YMMV and that's why there is a setup-web tag - e.g. no issues here, haven't never seen a SEC_ERROR_OCSP_SERVER_ERROR in many years and a user does, for a frequent site or it happens repeatedly, the error name is blinding obvious to add an override. If you're going to talk to a CA, and in plaintext, then make it at least be meaning and count for something

---

I'm not entirely sure, but if you follow what ma1 said, Tor is a special case as the OCSP plaintext request is only seen by the exit node (or rather observed as being sent to the exit node). IDK if that's accurate, TBH. I also wonder if exit nodes cause latency and more OCSP failures than normal. Goes without saying that the CA sees the request as well, but in Tor you are two layers behind it (if ma1 is correct).

What I did say was that I was inclined to align with TB (and LW) depending on what they came up with, regards crlilte mode: i.e 2 vs 3 - and the entire narrative has been driven by you and me anyway, so ma1's just parroting what we dug up, because it makes sense :) Good parrot :)

So we have the option of mode 2 or 3. Mode 2 3 means more OCSP but less false positives <- that's it. That's the entire tradeoff. Personally, I've never seen a false positive - because I haven't seen any revocation errors, so therefore cogito ergo sum. YMMV. Moz are rolling out CRLite. I'm inclined to sit on this until CRLite is enabled by default (and we can move security.remote_settings.crlite_filters.enabled to DON'T TOUCH and eventually remove it entirely). I personally still think we should use 3 as default and users can override - we're just lacking a setup tag.

[fxbrit]

I would argue that hard-fail is not a solution either: while trying to solve a security issue you could very well introduce another one (eg. denial of service, I block your way to CAs and you can't use a part of the internet now), plus all the usability downsides. it's a very extreme scenario but it's further proof, alongside the article I linked above, that it is not the way to go.

I think ma1 is correct about exit nodes, but the real point here is that it doesn't matter if OCSP is plain text, because the exit node can already see the websites you visit if it looks hard enough: in the case of Firefox this is also true, your LAN and ISP (or your VPN provider if you use one) can already see the destination of your packets if they want to.

PS I think you inverted modes 2 and 3 in the above comment

[KOLANICH]

For example, if the proof of non-revocation could not be obtained for a valid certificate, a hard-fail strategy will show a security warning. Showing a security warning when no security issue exists is dangerous because it can lead to warning fatigue and teach users to click through security warnings, which is a bad idea.

1. One cannot proove that the server was inaccessible because of a real failure, not that an adversary has intentionally tampered with it or with data sent through your Internet connection to make your browser accept a revoked certificate

2. Even if the connection wasn't intentionally tampered, it can coincide that the certificate was really revoked, that there was an attack on you and that the OCSP server accidentially got down, all within the same timespan.

3. Security and availability is always a tradeoff. Oppressive regimes, for example, force people to compromise on security by doing MiTM on TLS sessions. If you are not ready to accept and tolerate the interception - don't use the internet. If you are an ISP and not doing what is prescribed by the law, if you don't install the middleboxes, if your clients have TLS sessions unintercepted - face felony charges and go to prison. To keep peoples' souls in peace they require them to install new root CAs to access govt websites. Those so called "patriots", who have done the required, later will gaslight the ones who haven't obeyed with "there are no issues, it's only you who have the issues, it is because you are amoron who plays an idiot" and "aren't you an agent of our Duce enemies".

The only way that can (in some cases, if they really need, they would prefer to shut down the Internet completely, if they cannot control it) anyhow deter the MiTM cyberattack is that there must be total disruption of services in the case when secure Internet operation of them is made impossible, without any possibility to satisfy the blackmailers.

4. The real solution to OCSP stapling problem should be incremental generation of the Bloom filters with revoked certificates and a peer-to-peer network client embedded into each browser and updating the filters in almost real time and lifting the most part of the load from the central servers generating the filters.

[Thorin-Oakenpants]

I would argue that hard-fail is not a solution either

Yes. We all know OCSP is not a full/final solution - that's why CRLite exists. But soft-fail is means you are at risk. Hard-fail means you are not. Capisce!

while trying to solve a security issue you could very well introduce another one

That's not a security risk because you're hard-failing. Even if someone wanted to DDoS you (and you are insignificant), even if they didn't attack you but happened to attack a CA and affect your traffic, then all it means is inconvenience, no risk.

I will not be disabling hard-fail as a default. Users can override if they are constantly affected

but the real point here is that it doesn't matter if OCSP is plain text, because the exit node can already see the websites you visit if it looks hard enough: in the case of Firefox this is also true, your LAN and ISP (or your VPN provider if you use one) can already see the destination of your packets if they want to

it's about reducing the connections to a CA and the amount of plaintext. In Tor, the ISP doesn't see it. With a VPN, the ISP doesn't see it. Of course the proxy or ISP-with-no-proxy will see it. That's not the privacy issue

[fxbrit]

even if they didn't attack you but happened to attack a CA and affect your traffic, then all it means is inconvenience, no risk

potentially OCSP traffic could be blocked at any point of the path towards the CA, so there are several ways in which hard-failing makes you prone to DDoS. I know it's not as relevant for a browser when compared to strong certificate mechanism, but not being able to access websites because of a malicious actor is an attack.

but if you want to keep hard-fail because you prefer that side of the trade-off (there's one indeed so I don't blame ya) it's fine.

it's about reducing the connections to a CA and the amount of plaintext

connections to the CA I get it because of the IP address, but what's the deal with plaintext really? I don't see it, IP headers are still unencrypted so no need to look at hashes and serial numbers IMO. enough OT anyway, this is just me being petty, bad fish 🎣

---

@KOLANICH

One cannot proove that the server was inaccessible because of a real failure, not that an adversary has intentionally tampered with it or with data sent through your Internet connection to make your browser accept a revoked certificate

the browser can tell if it received a response or not, and error codes for responses exist. also the response status is signed with the same key that signed the certificate, meaning it must be produced by a valid responder.

Oppressive regimes, for example, force people...

if you can't trust the whole certificate infrastructure then yeah. I don't think there's a solution in that case, at least not one related to failing strategy. as for point 4, I like CRLite but I'm nobody so..

[Thorin-Oakenpants]

this is interesting

• https://old.reddit.com/r/firefox/comments/1ayqhvc/crlite_not_recognizing_revoked_certificate/

edit: title is misleading: we know revoked certs are being sent to crlite, it's in their telemetry results

[simurq]

I hope it's not off-topic, but recently I started getting this error on seemingly safe websites like Distrowatch and even Mozilla's own Bugzilla:

Secure Connection Failed

An error occurred during a connection to bugzilla.mozilla.org. The OCSP server experienced an internal error.

Error code: SEC_ERROR_OCSP_SERVER_ERROR

To "solve" this, I currently set security.OCSP.require to false temporarily (during the browser session), which obviously re-enables itself on the next browser launch. So is there may be an option to add certain websites to sort of ignore list, leaving the setting at true/on for the rest?

Thank you!

[Thorin-Oakenpants]

rather than change security.OCSP.enabled for the session, you should use the one designed for it ... it even has the error code for you :)

/* 1212: set OCSP fetch failures (non-stapled, see 1211) to hard-fail
 * [SETUP-WEB] SEC_ERROR_OCSP_SERVER_ERROR
 * snip ***/
user_pref("security.OCSP.require", true);

if it is repeatedly happening and is becoming a PITA, then add it as a permanent override and revisit it in 3 months.

is there may be an option to add certain websites to sort of ignore list

I don't think so, but I've never had this issue myself so haven't dug deeply, and it's not a normal FF config, so I doubt it - I mean the user chose to hard-fail

[Thorin-Oakenpants]

https://bugzilla.mozilla.org/show_bug.cgi?id=1908481
https://bugzilla.mozilla.org/show_bug.cgi?id=1909762

[opusforlife2]

https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html

Does this mean security.OCSP.require no longer needs to be enabled?

[Thorin-Oakenpants]

why? ocsp as a fallback is perfect - the fact that let's encrypt will be using crl only makes crl better, not perfect

[opusforlife2]

Oh. It's the one pref that gives me the most grief when using AF. https://bugzilla.mozilla.org/show_bug.cgi?id=1908714

[Thorin-Oakenpants]

users can add an override if it's problematic - it's one of like 8 things to worry about for usability - so I am not likely to change it just yet

I need to rethink this at some stage

• I do not know the impact of let's encrypt no longer sending adding ocsp data (I assume what they used to send to various endpoints would filter out to all endpoints)
• i need to re-learn what we do in our current setup which I think is if it's not crl revoked we fallback and use ocsp (which hard fails e.g. if unreachable)

hopefully one day we can just use crl - good things take time