Why isn't OCSP required by default in browsers?

Question

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?

Answer 1

There are several problems with OCSP. Some of them:

1. It puts too strain on the OCSP responder (minor issue)
2. It makes your browser respond slower, as it has to ask the CA before visiting the site.
3. Privacy reasons: The CA gets the serial number requests for all the certificates you ask, so it can pinpoint which sites you visit. Who says it will not sell that data, do you trust it? Of course you are supposed to trust your CA, but...
4. There are some man-in-the-middle attacks targeting it (paper)
5. Also, the current implementation is somewhat weak. If an OCSP validation attempt fails (because the server does not respond for example), the browser has two choices: Continue anyway or fail hard and stop the connection to the site. Both of these choices are bad: If the browser ignores the fail, a possible attacker can mitm the server, if he has access to the potentially invalid certificate. If the browser stops the connection, then an attacker in the network can do a simple but effective Denial of Service attack, just by blocking somehow all OCSP requests.

Answer 2

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.

Answer 3

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.

Answer 4

Because OCSP puts too much strain on the CA. Imagine you are a trusted CA. Now imagine the infrastructure that you must put in place to handle millions OCSP requests to your server each second. Good business?