OCSP: “This fail brought to you by the number three”

There is much to write about the disclosure of vulnerabilities in X509, independently found by Moxie Marlinspike and Dan Kaminsky. There was some overlap in their discoveries, but also unique aspects. One worth highlighting is Moxie’s attack on defeating OCSP with a single byte.

Online Certificate Status Protocol attempts to verify the validity of web site certificates by contacting an OCSP responder, operated by the certification authority (CA) and asking the question “is the certificate with serial number #123 still valid?” This is one of two approaches to doing revocation checks– the Achilles heel of PKI. The other option is CRLs or certificate revocation lists. In that model the CA publishes a list of revoked certificates periodically and client download these (hopefully in advance, so that by the time you have to check it is locally cached) and look for the certificate in question there.

Now since the revocation status of a certificate is critical bit of information, the answer from the CA, whether packaged into a CRL or generated on-demand in response to an OCSP ping, has to be somehow protected. Otherwise the bad guys– on top of having obtained a bogus certificate and private key– can simply forge a response to suggest that all is well with the certificate.

It’s tempting to say “download the CRL / run the OCSP check over SSL” but that would create a circularity for boot-strapping. Not to mention that SSL is a very expensive solution to the problem of content integrity. Instead CRLs and OCSP responses are digitally signed, typically by another certificate that chains up to the issuing root CA.

Now if that had been the entire story revocation checking would be sound.

But Moxie noticed that by design OCSP allows unauthenticated responses, namely the set of responses collectively dubbed non-authoritative. This includes conditions such as an internal error with the service, malformed request  and “try again,” suggesting that the server might be overwhelmed with demand at the moment. These replies do not require a signature– by design. It’s in the RFC. In these cases a single byte indicating the response status is a valid OCSP response.

Of course this defeats one important security guarantee: when a non-authoritative response is received, the client can never be sure if it came from the OCSP responder. An attacker pulling of a man-in-the-middle attack could always forge one of these respones. Granted such an attacker could also drop the traffic and make it appear that the OCSP responder has vanished from the surface of the Earth. The bottom line is that in the absence of a signed response, client can not make any conclusions about the status of the certificate.

Of course implementations of OCSP must deal with this condition. They need to report what went on, and the buck stops somewhere along the application stack, where one developer decides what to do with these non-authoritative error codes.

Moxie’s discovery is for both Windows CAPI and NSS, that decision is to treat the “Try Again” response with code 3 as a successful revocation check. That means IE and Chrome (built on top of CAPI) and Firefox (built on top of NSS) are trivially confused in OCSP checks… with a one-byte response containing “3.”  Neatly summed up by one of the money slides in the presentation: a giant three interposed over the OCSP RFC.

Granted this is not the entire story: starting with Vista there is a complex revocation checking logic in CAPI that will load-balance between OCSP and downloading CRLs. CRLs are more efficient at scale: If every user in the world started hammering Verisign’s OCSP responder for every SSL request, Verisign would fall over in a matter of seconds. But they are highly inefficient in the short-term: in order to check the status of a single certififcate, the client is tasked with downloading a massive document, in the middle of setting up a connection. Vista tries to solve this problem by looking for frequent revocation checks and scheduling CRL downloads for them. Once a non-expired CRL has been downloaded, in principle the OCSP check is not required because looking at the locally cached document is faster and will reveal the revoked status of the certificate. In other words there may be edge cases to the Moxie attack where it stops working, depending on the past history of revocation checks.

Still a remarkable way to cap off a  series of attacks against X509 parsing.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s