Pale Moon forum

Am currently learning more about web security. It's sobering to learn the limitations of the OCSP-based CA system:
https://www.imperialviolet.org/2012/02/05/crlsets.html
http://www.zdnet.com/article/chrome-doe ... on-better/

The above links summarize the problem and emphasize Chrome's ability to push CRLs via auto-update. This definitely seems like a better approach, though given the heft of Google it's an effort they can take on. Would such an effort be remotely feasible for PM at some point? (I'm aware you're in the thick of Tycho right now so just curious.)

For now will leave PM's OCSP settings as default. The drawbacks are extra latency incurred during "soft fail" scenarios and possibly privacy concerns with CA's tracking sites visited. But it still may be worth the slight chance it actually provides better security. (For reference, Moonchild briefly addressed this last year: viewtopic.php?f=26&t=9424&hilit=ocsp)

didn't think to ask earlier -- does anyone disable OCSP requests (security.OCSP.enabled = 0) and if so, any complementary measures taken? (i.e. other non-default security settings, 3rd party tools, etc.)

For context, I'm using uBlock Origin in Advanced mode. I keep its default of whitelisting what it calls "behind the scene" traffic, which includes all OCSP requests. These can be blocked in the tool, but if I'm going to disable it I'd prefer to simply do so with the PM setting.

I have a Custom Button to toggle OCSP-enabled. Since so many sites have started using https, it is less important to check for cert every time.

CustomButtons is on Mozilla Addons. Get Preferences Switcher button from CB forum on Sourceforge.

You can use the Pale Moon Commander addon to toogle OSCP on/ off, but i recommend to not disable that.

I never see any websites which doesn't work with OCSP on.
Also i think turn it off doesn't make problems too.

I strongly suggest leaving OCSP enabled. CRLs are never going to be real-time.
As for the latency involved, and additionally the matter of people concerned about OCSP requests: this is why we have OCSP stapling, where a signed OCSP reply is stapled to the certificate response by the server you visit. No delay, no extra request to a CA server.

OCSP in perspective: is a brief delay connecting to a new secure server problematic when your security is at stake?

Thanks for the responses.

@GreenGeek - that's interesting you've made a button to toggle OCSP revocation checks on/off. I'm curious how you use it... do you leave it on or off by default? And what situations would cause you to toggle it?

@Moonchild - yes, OSCP stapling is indeed a better method than client OSCP checks. In fact, the Google engineer who advocated for and implemented the CRL push capability in Chrome is also an advocate for the "OSCP Must Staple" RFC (per links above + this one). But seems like the business realities of the Web are such that the status quo is likely to persist, rendering Must Staple unrealistic -- hence Chrome adding CRL push to mitigate the gaping flaws of the client-CA OSCP check system (as explained in the links).

And to clarify my position, I'm only thinking specifically about disabling browser OSCP checks; stapling would of course remain enabled. I've seen a number of browser OSCP checks in my recent traffic logs in uBlock. This tells me that a number of sites I use do not deploy stapling.

edit: just in last 15 minutes uBO has logged OSCP requests to 4 CAs: godaddy, digicert, letsencrypt, and google (who oh-so-conveniently are their own CA)

@Moonchild -- can you clarify how these 2 settings relate?
security.OCSP.enabled
security.ssl.enable_ocsp_stapling

In particular, if the first is disabled will stapling still be enabled?

I leave it off for routine browsing. Enable for bank or Paypal,etc. (I'm not advocating other people should do this. Moonchild's advice is best for people who know little about computers and internet threats.)

joe04 wrote:@Moonchild -- can you clarify how these 2 settings relate?
security.OCSP.enabled

Does what it says - enables or disables OCSP checking for certificates.

joe04 wrote:security.ssl.enable_ocsp_stapling

Enables the parsing and verifying of stapled OCSP responses. If not present, falls back to an OCSP lookup at the designated CA.

joe04 wrote:In particular, if the first is disabled will stapling still be enabled?

No. If you disable OCSP checking, it will not check OCSP of any type. A stapled response check is still an OCSP type check.

GreenGeek wrote:I leave it off for routine browsing. Enable for bank or Paypal,etc. (I'm not advocating other people should do this. Moonchild's advice is best for people who know little about computers and internet threats.)

I don't recommend this. It's more involved to have to remember to switch it on and off every time, and not performing a revocation check on routine browsing will allow connections to sites with revoked certificates. Certificates are not revoked without good reason (and it often costs money to have a certificate revoked, too) so you can be pretty sure that if a certificate is revoked, you are connecting to a server that is involved with criminal activity or malware of one sort or another. Do you want that to happen?

Moonchild wrote:No. If you disable OCSP checking, it will not check OCSP of any type. A stapled response check is still an OCSP type check.

I'm glad I asked. Definitely will leave OCSP enabled!

Thanks guys for all the helpful responses. I'm actually running an experiment now with security.OCSP.require=true to see if any hard fails will occur in the course of ordinary browsing. So far no fails but will report back if I see anything interesting happen.

Just a quick follow-up on requiring OCSP validation, i.e. hard fails -- didn't see one after a few days (a good thing) so I forced one with a uBO block just to see what would happen. I like that PM shows an "OCSP failed" page that forces you to decide whether to proceed with the SSL session or not.

But I reverted the setting back to the default, as I haven't ever disallowed soft fails before and don't think I gain much by doing so (per the links above). So now I'm back where I began with all OCSP settings default. Thus only a certificate revocation notification triggers OCSP failure.

And this is why we have the defaults we do