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?
Asked
Active
Viewed 2,109 times
4 Answers
13
There are several problems with OCSP. Some of them:
- It puts too strain on the OCSP responder (minor issue)
- It makes your browser respond slower, as it has to ask the CA before visiting the site.
- 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...
- There are some man-in-the-middle attacks targeting it (paper)
- 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.
john
- 10,998
- 1
- 36
- 43
-
In 5. "the current implementation" is what the option in the question is all about. / EV certs (if specifically supported) must be checked by OCSP. – Tom Hawtin - tackline Oct 05 '11 at 08:26
-
@TomHawtin-tackline "_must be checked by OCSP_" Actually, the browser MUST do what the user prefers. – curiousguy Jun 01 '12 at 07:18
-
@curiousguy I believe the EV specification require that OCSP be checked. User agents with user options to disable that check are broken. – Tom Hawtin - tackline Jun 01 '12 at 11:40
-
@TomHawtin-tackline So they are "broken" in a useful way. Nobody cares about the EV nonsense anyway. – curiousguy Jun 01 '12 at 13:23
-
@curiousguy I don't think breaking security is useful for the user. There might be an option to disable EV features, but that's another issue. – Tom Hawtin - tackline Jun 01 '12 at 19:19
-
I don't agree with (3).CA gets a request for a certificate status from some IP.It can "sell" this IP with the certificate it requested for validation but that IP can not be bound with a specific client.IPs are dynamically assigned and this information would not be of much use – Jim Oct 31 '12 at 18:43
-
I also don't agree with (2).Performance is not an issue when it comes to security.Browsers already are slower establishing an SSL connection in comparison to plain http connections.I don't think that a delay of 1-2 second more would be an issue – Jim Oct 31 '12 at 18:45
-
As far as (5) is concerned the action is not mandated by a standard.But it could be delegated to the user whether the connection should be dropped or not the same way as the responsibility is delegated to the user when a server sends a certificate not part of the trusted ones – Jim Oct 31 '12 at 18:47
7
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.
Thomas Pornin
- 322,884
- 58
- 787
- 955
-
An example of OCSP relying on CRL is Microsoft PKI implementation. But I don't think the verification of the OCSP responder certificate is an issue. First of all because OCSP is not over SSL but plain HTTP. And if it is set to be over SSL and the responder certificate has been compromised the whole infrastructure goes down the drain, but this is also what happens if a CA certificate is compromised.And it is usually the CA that is the OCSP responder just using a different certificate – Jim Oct 31 '12 at 18:51
5
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.
bethlakshmi
- 11,656
- 1
- 28
- 59
2
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?
Nam Nguyen
- 1,460
- 12
- 14