Explicitly document that security.OCSP.enabled only affects OCSP fetching, not stapling

[smithfred]

Per https://hg.mozilla.org/mozilla-central/file/bd02f1cb9f4f/security/manager/ssl/nsNSSComponent.cpp#l828, setting the above pref to false doesn't (or shouldn't) affect stapling.

Though the user.js comments are correct in describing the actual effect, the pref. name itself is inaccurate/misleading - would be useful to specifically mention this, and that setting it to false (e.g. for privacy reasons) doesn't affect the non-trash-fire version of cert verification (stapling+must-staple) ;)

[earthlng]

@smithfred good find, thanks for reporting.
While researching this I also found that this line 2=enable and use values in security.OCSP.URL and security.OCSP.signing. is (a) no longer the case and (b) was incorrect anyway. From what I can gather there never was a pref security.OCSP.signing. Back in ESR17 (!) there used to be a security.OCSP.signingCA but it does not exist anymore in ESR24 and newer.
So that's another thing we need to fix. How is this? ...

/* 1211: control use of OCSP responder servers to confirm current validity of certificates
 * 0=disabled, 1=enabled (default), 2=enabled for EV certificates only.
 * OCSP (non-stapled) leaks information about the sites you visit to the CA (cert authority)
 * It's a trade-off between security (checking) and privacy (leaking info to the CA).
 * [NOTE] This pref only controls OCSP fetching and does not affect OCSP stapling.
 * [1] https://en.wikipedia.org/wiki/Ocsp ***/
user_pref("security.OCSP.enabled", 1);
/* 1212: set non-stapled OCSP to hard-fail
 * When a CA cannot be reached to validate a cert, Firefox just continues the connection (=soft-fail).
 * Setting this pref to true tells Firefox to instead terminate the connection (=hard-fail).
 * For more info about the problems with soft/hard-fail (and OCSP in general) see [2].
 * [NOTE] this pref is ignored if 'security.OCSP.enabled' is set to 0.
 * [1] https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
 * [2] https://www.imperialviolet.org/2014/04/19/revchecking.html ***/
user_pref("security.OCSP.require", true);

FYI mozilla set 1211 to 2 in nightly for a while but apparently it didn't produce the outcome they'd hoped because in the latest nightly the default value is 1 again.

[smithfred]

Looks good to me re. the note. Could optionally refer to the source code comments, but that's the Wikipedia mentality in me ("citation needed") :D

Edit: also, it's arguably also worth explicitly pointing out in the comments that enabling OCSP fetching without enabling "require" is completely fucking pointless (as highlighted in [2]), resulting in the worst of all worlds (privacy+security) ;)

[smithfred]

Yep, that was me. I ticked the "break GitHub" box when I was submitting my comment, should I not have done that?

[earthlng]

so what about Mr. Fred's EDIT, Pantsky? Very eloquently written indeed, and I couldn't agree more :)

[NOTE] OCSP fetching without hard-fail is completely fucking pointless or something like that

[smithfred]

I only license my characterisation colourfully verbatim (last 3 words at least) 😁

[grauenwolfe]

I only license my characterisation colourfully verbatim (last 3 words at least) 😁

LOL, this guy!

[earthlng]

^^ do an commit then

8c35bf5

[smithfred]

If a cert cannot be validated, then you cannot tell if it is valid or not, so therefore a soft-fail puts you at risk

The user might think the "unable to validate" condition would only be coincidental (e.g. OCSP server down) rather than maliciously blocked, and consider it a reasonable trade-off on that basis.

Fetching on it's own has merit, right? - eg when a CA is reached and it revokes a cert? In other words, 1212 only handles FAILURES not successes

And this kind of makes my point (i.e. believing it has any use against a competent attack). With a competent attacker, and given the likely prerequisites of a revoked cert attack, they will be a position to block, and will block, access to the OCSP server.

[earthlng]

The seat belt bit needs to go - no humor allowed

no humor - it's a quote from a google engineer hence the quotation marks ;)

You're right though, maybe we should change it to "OCSP fetching without hard-fail is almost completely pointless" or "OCSP fetching without hard-fail is mostly pointless" or something like that.
But the point and the question is, have you ever encountered a site that failed to load due to the cert being revoked? I have not, at least not that I remember.
In most cases companies will probably issue a new cert before revoking the old one. The potential damage has already been done at that point anyway and it would just be more bad publicity to revoke the cert first.

[earthlng]

👍 to the 1211 title change. Big fat 👎 to the changes in 1212.
"pointless" vs. "completely pointless" - it's still an absolute statement.
Like "dead" vs "completely dead" - not much difference, is it?
If you don't like that 1 line I added in 1212, just remove it again. We now also have [2] which explains it much better than we ever could with a few short sentences, anyway.
And what you wrote is also wrong btw. If a cert has been revoked the fetch wouldn't fail and soft-fail would still block the connection.

[earthlng]

when an OCSP fetch FAILS. What I wrote is 100% true

you're right, I'm sorry mate.

I'll butt out of this one and leave it up to @earthlng

why are you even in here + annoying me? ;)
I like 1212 the way I committed it. But if you hate it go ahead and change it to whatever you want.

[smithfred]

My take is soft-fail is of theoretical value only. If the cert is revoked but OCSP fetch succeeds, it's either a shit attacker (can interfere with DNS/routing to MITM to another endpoint serving the stolen cert), but doesn't know they need to prevent OCSP fetch using the same mechanism) or a useless sysadmin (still "legitimately" serving a revoked cert). And on that basis soft-fail would only be of any real-world use if there were some sort of notification of the soft-fail. Which there ain't.

"OCSP fetching without hard-fail is mostly pointless"

I like this one. Mostly because Mostly Harmless.

PS: @smithfred - I have invited you to be a collaborator - go here to accept if you want:

https://www.youtube.com/watch?v=t7Dc1ZD-hMQ

[smithfred]

It means you're inviting me to look after the news stand. I'll just nick it.

[smithfred]

No no no, digital duplication is theft, please re-insert MPAA/RIAA consumer compliance needle into brain.

Also, where's the fun if I can't trash your whole repo? Boo.