Random SSL/TLS 101 - OCSP/CRL in practice

Reading Ivan Ristic’s SSL Rating Guide 2011, among other things, I've noticed the discussion about certificate revocation status checking options: none, OCSP and CRL.
And I cannot resist ranting a little bit…(did not comment yet on that paper though)

What quickly come on my mind regarding certificate revocation status checking that is really great…
But just in theory. :)

For a start I would ask myself, why do I need certificate revocation status checking?
From a security point of view, to not be MITMed, either with a stolen revoked cert or with one revoked due being improper issued by a CA to some “friendly” people.

And if so, in reality, can OCSP and/or CRL protect me from such a MITM?
Errr, not really.

First thing one may note is that it has to take into account the entire picture, so what if the server’s certificate includes both OCSP and CRL information?
How does the client deals with this information, how the CRL or OCSP are being provided to the clients?

OCSP
OCSP, in terms of freshness, performance and scalability, is superior to a CRL solution.
In terms of security, depends on how it is used, is susceptible to replay or fails to assure any protection at all.

Freshness for OCSP responses is provided by two means, time-based freshness and with the help of nonces.
To counter OCSP response replay, nonces must be used(since it binds the client’s request to the responder’s response), time based freshness provides a variable window of replay opportunity.

On the responder side, scalability must be taken into account, the use of nonces does not scale.
With time based freshness, responses can be cached. At a large scale the validity period of an OCSP response can be up to even a week, which even for an “unlucky” attacker may provide a good 24h of replay window.

For example, if we take a look at PayPal’s EV certificate, obtained from VeriSign we can note a validity period of about 7 days which matches the validity period of the CRL, thus the replay window opportunity is the same with the CRL’s one; the OCSP response’s freshness security will match the CRL based validation solution.

On responder’s side, for maximum client compatibility, both GET and POST OCSP requests must be supported(it has been noted that some clienst only do GET requests, some only do POST requests, and some both).
Depending on the scale of the infrastructure, the responder may choose not to support nonces.

On the client side, first OCSP must be supported, and for maximum responder compatibility both GET and POST OCSP requests must be supported(it has been noted that some responders failed to handle GET requests), with fallback support from one method to another.
Another option may be available for clients, OCSP stapling, the OCSP response being returned by the TLS server during the TLS handshake.
From a security point of view, things vary a little.
If the client wants maximum security it must use nonces, must issue a fresh OCSP request for new connections avoiding client side OCSP response caching, and must not fallback to OCSP without nonces or to CRL download.
However, in reality, for compatibility issues, the clients will not use nonces, do OCSP response caching and implement a CRL fallback, anyway the replay window, like in the above VeriSign example, is the same for OCSP and CRL.
Thus attackers have a replay window opportunity.
Also, it depends how the clients treats a bogus OCSP response, we saw here(http://www.carbonwind.net/blog/post/Random-SSLTLS-101-HTTP-Strict-Transport-Security.aspx) that some clients do not mind at all after receiving such answers(Firefox 3.6.x or 4 Beta), some may have some UI flags(Chrome 9 shows a broken padlock, Opera 11 does not show the padlock at all), some show a warning message(Safari 5.0.x), and only a few in certain situations abort the connection(like Chrome 9 on Windows 7 in case of a domain was marked as an HSTS site).

So basically, in most cases an attacker would not even have to worry about replay attacks; just present a bogus OCSP answer.

CRL
CRL was a prior to OCSP solution to revocation status checking.
The issue with CRL is that the list can get quite long(especially on large CAs that have experienced significant amounts of certificate revocation), and to attempt to download it very often is not good in terms of performance and scalability.
Thus the validity period of a CRL can be quite long, offering a “reasonable” replay window opportunity.
To mitigate this issue, delta CRLs can be used. A delta CRL provides an update to a previously issued complete CRL, containing only the changes in revocation status that have been made since a previous base CRL publication.
This allow the clients to download the latest delta CRL and in combination with the most current base CRL(which usually is cached locally) to have the complete list of revoked certificates. 

The problem in practice is that both clients and CAs must support delta CRLs, which is not quite the case(due to some complexities associated with delta CRL deployments).

With CRL is difficult to provide freshness for a certificate revocation status and to mitigate replay window opportunity, especially at a medium/large scale.
Also, like with OCSP responses, it depends how the clients treats a bogus CRL response, terminate the connection, warn/prompt to continue the user, UI change or do nothing(ignore).

Again, like with OCSP, basically, in most cases an attacker would not even have to worry about replay attacks; just present a bogus CRL answer.

Tables listing a few browsers
Tried to see which browser uses OCSP and/or attempts CRL downloads, has any fallback mechanism, UI changes/alerts/prompts, connection terminated in case of revocation status failure. 
Not tested, Opera/Firefox on Mac, other popular Linux distros, like Debian or Fedora.
Not tested if the checks are applied to every certficate from the chain.

As can be noted most clients listed support OCSP.

* (Apparently) Uses Windows Crypto API for certificate revocation status checking
** If by default uses nonces
*** Fallback from OCSP to CRL
**** Does not specify exactly what happens for the two main cases: when no revocation info(OCSP/CRL) is available within server’s certificate and the OCSP responses/CRL downloads attempts were unsuccessful.
***** Probably behavior noted, but not thoroughly tested to be mentioned.
Red = not seen as enabled by default
Green = seen as enabled by default
Chrome 9.0.x = Chrome 9.0.597.94 was tested.
On Ubuntu 10 Desktop, Chrome was installed from Google’s web site, and the Firefox version is the one shipped with the OS.
On Mac OS X 10.5, Chrome was installed from Google’s web site.
Opera 11 does not fallback from OCSP to CRL if OCSP fails, tries CRL only if the certificate does not contain any OCSP info(just CRL info), apparently can use POST instead of GET OCSP requests for a list of pre-defined site.

Conclusion
What conclusion ?
Basically is useful to offer both OCSP and CRL, OCSP itself will probably do in most cases. No fuzz.

Some screenshots with certificate revocation status settings
Chrome 9.0.597.94: on Windows 7, Mac OS X 10.5.8, and Ubuntu 10 desktop.

Firefox: on Windows 7(3.6.13), Ubuntu 10 desktop(3.6.8)

Internet Explorer 8: on Windows 7

 Opera 11.0.1: on Windows 7

Safari 5.0.3: on Mac OS X 10.5.8, we can play with the OCSP/CRL settings from the Keychain Access Preferences, under the Certificates pane, the "Online Certificate Status Protocol (OCSP)" and "Certificate Revocation List (CRL)" pop-up menu choices.

Some references:
http://en.wikipedia.org/wiki/Revocation_list
http://www.corestreet.com/about/library/whitepapers/w03-07v1_nonce-sense.pdf
http://technet.microsoft.com/en-us/library/bb457027.aspx
http://www.microsoft.com/industry/government/solutions/usgcb/default.aspx
http://support.apple.com/kb/TS3168
http://my.opera.com/yngve/blog/2008/06/27/nobody-checks-the-padlock-debunked-by-opera-users
http://www.carbonwind.net/blog/post/You-may-receive-warnings-while-accessing-secure-web-sites-with-Opera-and-Safari-on-Windows-behind-Forefront-TMG-2010-RTM-doing-Outbound-HTTPS-Inspection.aspx