496780 - with default options, firefox doesn't warn the user if OCSP server is not reachable

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[marco.pallotta]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.0.10) Gecko/2009042513 Ubuntu/8.04 (hardy) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.0.10) Gecko/2009042513 Ubuntu/8.04 (hardy) Firefox/3.0.10

This issue was posted on launchpad
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/331984

and is related, in some ways, to bugzilla bug 496661 that I opened some days ago.

With firefox  configured with the default security options ("Use the online certificate status protocol to confirm the current validity of certificates" enabled and "when an OCSP server connection fails, treat the certificate as invalid" disabled) I noticed that if OCSP server is not reachable (I forced this dropping the connection to an OCSP Verisign server) firefox doesn't warn the user about this and shows that SSL connection was established without errors (this is obvious as the option "when an OCSP server connection fails, treat the certificate as invalid" is disabled by default).
This is, potentially, a high security issue as if the target SSL certificate was revoked the user shall never know this (as OCSP server were not contacted) and he shall think that the site, he is going to visit, is a secure site.

Reproducible: Always

Comment 1

[Johnathan Nightingale [:johnath]]

This is by design.  The state of revocation information for low-cost DV certificates right now is mixed, some responders are significantly more likely to be live than others. Even turning on OCSP checking by default was controversial, if you can believe it, but it is certainly not yet the case that we can treat any failure to receive OCSP information in a timely fashion as a hard-stop by default: it would break a significant chunk of the secure internet for most of our users.

For users such as yourself who are able to make that distinction yourself, and who involve themselves in the validation workings of their browser, we do provide an option (Advanced->Encryption->Validation) to treat failures to contact an OCSP provider as fatal.

We'll re-evaluate this in a few years, but right now turning this on would create more problems than it would solve, in my opinion. I wish the situation were different, and that reliable revocation information was available across the board.

One thing we've done with the CAs to help that along is insist that the new, EV, certificates have high-availability revocation information (OCSP or CRLs until 2010, OCSP only thereafter). The hope is that as CAs learn to operate and scale these OCSP responders, they will be better able to deploy them across their product range.  If you do start browsing with OCSP errors treated as fatal, I would encourage you to take note of the CAs who consistently seem to fail these checks, and bring it to their attention.

Comment 2

[marco.pallotta]

I respect your opinion about this issue even if I think the real situation about the security of SSL connections is misleading towards users, as I already sayd in bug 496661 and should be fixed anyway.
I think finding a way to inform every user of the potential risk of SSL transactions is a good point of start. Finding a way to do it technically implementing a sort of colored icons (as I proposed in bug 496661), about this issue, in the browser, could be a potential way to fix it. Do it by default, in the browser, should be, for me, mandatory just because of the criticality of the question (SSL transaction also involves bank transactions).

However thanks for your attention and reply.

Comment 3

[Eddy Nigg (StartCom)]

Johnath, it might be of interest to you, that I'm browsing for a while with hard failure for OCSP and there are surprisingly very little failures. Obviously some CAs don't have the OCSP URI in the certificate, but those that do seem to work. Sometimes it happens that I have to refresh or hit the same URL again - I'm doing this after waiting some ten second, and most of the times it corrects it. This could be due to some wait for the DNS and very low time-out which would be perhaps worth investigating. Hope this helps.

Comment 4

[Jo Hermans]

see also bug 340551