According to the following screenshot, taken from firefox-3.6.17-1.fc14.i686, Firefox has an option to fail closed when unable to connect to OCSP servers.
Can someone please explain why this isn't enabled by default?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
There are several problems with OCSP. Some of them:
Some CA do not offer an OCSP server, relying instead on CRL (notably, full OCSP with support for client nonces is rather expensive for the CA). And among those who do implement OCSP, many botch the job, resulting in OCSP responses which are not, per se, verifiable (e.g. the OCSP response is signed with a dedicated OCSP responder certificate for which the revocation status cannot be obtained). Hence, making OCSP checks mandatory means, right now, refusing to talk to a non-negligible proportion of existing SSL web sites. The world is simply "not ready" for wide acceptance of OCSP.
The big one - IMO - is the speed. I've used a couple different plugs and configurations to enable OCSP in browsers, and even in a lab environment where the OCSP server is unburdened and one hop away in a high bandwidth environment, the OCSP checking can be a serious delay in session establishment. I've even gotten plenty of user complaints, even when the users are other engineers who understand exactly what's going on.
In a public browser like Firefox, they aren't going to want to have your out of the box settings make your browser seem painfully slow whenever you do online shopping.
Also - there's a certain amount of configuration in OCSP checks - do you have a local OCSP server that's a preference to the configuration in the certificate? How, exactly is the certificate configured - there's not 1 perfect way of setting a URL for OCSP checks. Will your browser be required to sign the OCSP requests? Will it require a nonce? And for a secure system, it's not 1 OCSP check, it's a check for every certificate in the chain except for the self-signed Root.
And how many times will the browser retry a request with no response? And how long will it wait to decide that it didn't get a response?
These aren't questions an average user can answer, and browsers are absolutely built for the lowest common denominator.
I disagree with some of the positions that it's because it's too burdensome to the CA. Generally OCSP servers are separate from the CA. The CA signs the CRL and passes this CRL to an OCSP responder. A suite of load balanced OCSP responders can be staged to handle traffic. OCSP, by itself, is not a heavy load. It's a pretty small transaction, with fairly simple data in it. The performance is generally related to the size of the CRL and any connection setup/teardown impact. This kind of service is absolutely doable if the push is there to have it. The bigger problem is that the service itself is still complicated enough that it isn't easy to configure or universal. And it's not the kind of thing that average end users appreciate enough to have their SSL sessions delayed for.