firefox doesn't warn the user if SSL certificates do not include OCSP extension

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 bug was reported in launchpad
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/332176

Firefox doesn't warn the user if SSL certificate doesn't include OCSP extension. I think this is a high security issue for the user as, if the site he is visiting is protected by a SSL certificate that doesn't include this extension he cannot know if the certificate is valid (It could have been revoked but the browser, if OCSP protocol is anabled, cannot contact the OCSP server of the certification authority), or rather, he will think that the connection is safe (and this is worse!).
I think this bug, together the fact that only Firefox (that has maybe 20% of the browser market) has OCSP protocol enabled by default (MS Internet Explorer enables this only in Vista while Apple Safari doesn't enable it by default) makes world SSL connections virtually unsure.

Reproducible: Always

I have seen, txs to one of my friends, that Apple Mac OSX includes this feature and this is not only related to the browser (Safari) but to the whole systems so also the email client can use it.
Another security feature that Mac OSX includes in Safari is the ability to warn the user if at least one of the parent certificates has not OCSP extension. This is for me another mandatory option for ssl connections as the SSL certificates of the site you visit can be valid (that is OCSP server of the parent certification authority replies that the certificate is valid) but if the parent certificate was revoked you cannot never know this if your browser doesn't follow up OCSP extensions in the certification authority certificates tree and it doesn't warn the user if it doesn't find an OCSP extension.

The friend I spoke about in my previous comment did some tests with Safari (Mac OSX) with OCSP enabled (it hasn't enable this by default, as I already sayd in this bug description), with the feature through which Safari warns the user either if OCSP server isn't reachable or if the certificate doesn't include OCSP extension or if at least one of the parent certificates hasn't the OCSP extension and the result is that almost in every SSL connection Safari warns the user that the site isn't secure (either because OCSP server isn't reachable or because the certificate hasn't the OCSP extension or because one of the parent certificate hasn't the OCSP extension or it has the extension but the OCSP server isn't reachable).
I think this behaviour is ok because if one of these conditions aren't satisfied the SSL connection is potentially unsafe. The test shows that, in spite of the various advertisements about the fact the SSL connection is today a safe mechanism (let's think about what the world banks say about on-line transactions) the reality is different. The worse thing is, for me, that, with the actual situation about browser security (apart Safari if you enable all of the option I spoke about above) the user has the percept that everything is safe because he knows that he has only to see if the padlock is closed or not.
Now Let's speak about Firefox. The question is: is "commercially" "opportune" to include these options (but Firefox doesn't include all this features) by default (let's think about a typical user that cannot establish almost any SSL connection)? They should be just because SSL connection also include, from the others, money transactions (so I think all of we can agree that they have to be safe) but to be realistic I think we could start to include these feature in Firefox as optional (as Safari does) and warn the user (it could be at his first SSL connection) that he can increase firefox security enabling all the option features in the Firefox OCSP section.

Not security sensitive. No exploit is disclosed here.

The reporter apparently is unaware that there are other methods of revocation checking than OCSP. I'm pretty sure his concern is really with lack of
revocation checking, and not specifically lack of OCSP.

It would be useful to get some statistics on what percentage of SSL server
certs have any form of revocation checking info in them. Unless that number
is very close to 100%, this would just become another nuisance warning that
users would become conditioned to ignore.

This seems like a good candidate to become a browser extension.

Nelson, I know that there are other methods of revocation checking as CRL but I also read (and I may be wrong) the OCSP is the basically the "new" method so I have focused my attentions to this.
Anyway the message behind my post was: the user should have the assurance that a SSL connection should be safety. The closed padlock is misleading as the browser, to set it, doesn't take consideration about all the security aspects, as the revocation checking info. The problem is that every typical user only knows about the padlock and so his security perception is altered.

I also think that if developed as an extension, this last should be enabled by default: for example a simple icon (for example green if ok or red if ko), about revocation checking info, near the padlock should be, for me, a good solution. The user should be driven to consider that right, or better, the secure, combination about the two icons.

(In reply to comment #3)
> Not security sensitive. No exploit is disclosed here.
>
> The reporter apparently is unaware that there are other methods of revocation
> checking than OCSP.

Nelson, as you fully know, at the moment FF doesn't fetch any CRLs. Once it does, I suggest to fall back to CRL in case either OCSP doesn't exist or is unreachable. I also suggest that once either fails to view the connection as not encrypted.

Basically the user is to lose in case the CA revoked a certificate, but the user used a software which doesn't care about the revocation status. I think I share some of Marco's concern.

Eddy, this bug isn't about how to do revocation checking. It's about what
UI treatment to give to sites whose certs offer no revocation checking.

Knowing, as we do, the extreme dislike that the majority of Firefox users
and Firefox developers have for any sort of annoying interaction, and the
fact that the vast majority of users and developers alike will "click past"
ANY dialog that you put in their way, I think it is VERY VERY unlikely that
any Firefox developers will add any new annoyances to the http web site
experience.

The presence of absence of revocation information is not the browser user's
choice, but rather the policy of the CA from whom the site operator obtained
his certificate. It really comes down to whether the user trusts the certs
issued by that CA, or not. If the user distrusts all certs without revocation info, then the user should simply distrust the CA cert for any CA that issues certs without revocation info. I can see offering the user some visual clue,
such as a different icon (instead of the ordinary padlock) for such certs,
but a warning dialog seems right out of the question.

Surprising comment indeed! I'm not here to argue, we both know where to do this, just...what's the difference between any certificate and one that its status hasn't been checked?

Also, users don't have any way to know if the CA implements OCSP or CRLs or both. When FF starts to support CRLs the problem will be certainly of lesser extend (except in case neither OCSP nor CRL are accessible).

However for UI indicators we have our specialist of human shield :-)

The last browser to insist on successful revocation checks in order to activate SSL indicators, iinm, was Opera's experiment a year or two ago. They quickly reverted it because it broke too much of the web.

I am keenly interested in ensuring that users are safe online, but you will reliably find me opposed to introducing new details to users if I think that:

a) they will not understand it, and hence it will tend to undermine their ability to make informed security decisions, or

b) false positives are likely to be frequent, and inevitable, harming the trust they have in our UI and their ability to rely on it when making security decisions

The treatment we gave to expired/self-signed made me uncomfortable because it toed that second point pretty hard, but that's why we defaulted to permanent exceptions - it lets people express their security decisions once and, for most users, never see the error page again.

If we receive revocation information saying that a cert should no longer be trusted, fine, obviously we respond to that. Once we get CRLDP support into the product, our ability to detect those revocations will improve substantially, and as more of the mainstream CAs start supporting OCSP at scale, things will get better again. When that happens, revisiting this makes sense to me although, even then, I suspect my impulse will be to just remove trust indicators, rather than trying to invent a new one that expresses the concept of "We didn't get word that the certificate was revoked, but we also didn't get word that it wasn't revoked."

Right now, though, I don't think that taking such a step will help users be safer. It *would* help the much smaller group of people who understand what revocation checking means, but Firefox's defaults need to be appropriate for a quarter of a billion people. Any constituency which is substantially smaller than that is better served through an add-on. I'd actually really love to see some of the energy and ideas here expressed as an add-on, to see how popular they become, and how the user interface evolves.

I think Firefox has two problems:

1) fixing the gap with Apple Safari about this issue (I sayd, in one of my previous comments how with Safari we can obtain, even if not by default, the maximum security about SSL checking info, either with OCSP or CRL, while with Firefox we cannot do it);
2) deciding if going a step forward to others browser about this issue and, once fixed the previous problem, choosing if it's opportune to implement, by default, a sort of simple and immediate visual details that users can understand. About these last details we can think, as I already sayd, to a sort of colored triffic lights near the padlock or, maybe better, a colored padlock instead of white and black padlock (the friend I spoke about in one of my previous comment, and with whom I made some tests about this issue, has told to me that just Safari implements a sort of colored padlock if you enable all the optional functions about SSL checking info).

Anyway I also understand to Johnathan doubts about introducing new details with the risk that typical users don't understand them. The real problem is that web users have been educated (by mass media, informatics papers, banks and all the commercial sites) to only realize of the status of the padlock (and so implicitly ignore revocation issues) and so, any new added info can be considered misleading: that is typical user can think "if the closed padlock means that I have 100% of security what does it means this other icon?". But we know that the problem is not the other info (in this case the colored icon) but
the fact that he's wrong to think that closed padlock assures 100% of security.
Changing this perception is really not an easy task.

from comments it seems this bug is not unconfirmed at least. changing status.

(In reply to comment #10)
> from comments it seems this bug is not unconfirmed at least. changing status.

What is unconfirmed is that this behavior is a bug.
It's not a bug merely because some user says "I don't like it".

I view Johnathan's comment 8 as an "INVALID" or "WONTFIX" resolution.
I don't believe Mozilla's position with respect to this issue is
"Yes, we agree that this is incorrect behavior that needs to be fixed"
and THAT is the definition of a confirmed bug, I believe.