[cabfpub] Changes to improve OCSP interoperability, security, and usability

Brian Smith bsmith at mozilla.com
Wed Oct 23 12:08:13 MST 2013


Rob Stradling wrote:
> On 23/10/13 04:45, Brian Smith wrote:
> > 2. RE: "OCSP responses from this service MUST have a maximum
> > expiration time of ten days." This requirement is too lax for OCSP
> > stapling. A successful attacker is guaranteed to control the network
> > between the client and the web server, and he can choose to staple
> > whichever valid (non-expired) OCSP response he wants.
> 
> By "control the network", I think you're suggesting that the attacker
> can intercept and change bits on-the-wire, without detection by the
> client.  I don't think that's true here.  Wouldn't substituting a
> different Stapled OCSP Response cause the client to terminate the
> handshake with a bad_record_mac error?

I think you are assuming the attacker does not have the private key for the revoked certificate. But, that case is uninteresting because it doesn't matter to the browser whether the cert was revoked or not if the bad guy doesn't have the private key. (Oversimplified, but mostly accurate.) The interesting case is where the cert was revoked, the bad guy has the private key for the revoked certificate, the bad guy managed to get a valid "Good" OCSP response that hasn't expired yet, and the bad guy sends that "Good" OCSP response in the TLS handshake even though the client would get a "Revoked" OCSP response if the client were to query the OCSP responder directly.

> If the attacker has hacked into the webserver (or if the webserver
> operator is the attacker!), then the attacker can choose which OCSP
> Response to staple.  Or they can disable OCSP Stapling altogether.

Yes. This is why OCSP stapling is actually counter-productive for security without Must-Staple. However, with Must-Staple OCSP stapling becomes a security win.

> > However, a
> > successful attacker isn't necessarily guaranteed to control the
> > network between the client and the OCSP responder. In the case where
> > the attacker doesn't control the client <-> OCSP responder path, but
> > where he does control the client <-> web server path, OCSP stapling
> > makes the attacker more powerful.
> 
> In the client <-> OCSP responder path, HTTP tends to be used, so an
> active attacker _can_ substitute a different OCSP Response without
> detection.

They may be able to, or they may not. It depends on where the attacker is in the network topology:

     OCSP
  Responder  Web Server
        \      /
        a\    /b
          \  / 
           \/
           |
           |c
           |
        Client

We expect that most of the time that the attacker is at point C. In this case, he can tamper with all the traffic the client gets. But, it is possible, though far less likely, that he is at point B. In that case, he can tamper with the SSL connection but not with the OCSP response. Note that the attacker being at point A is not interesting for security, but it might be interesting for performance or DoS.

> > Returning
> > "Unknown" for an expired certificate is totally reasonable. However, I
> > think it seems reasonable to be a little bit more relaxed about that
> > so that browsers don't get forced into allowing "Unknown" to be
> > overridden all the time. I would like "Unknown" to be(come) equivalent
> > to "mis-issued" so avoiding user overrides of "Unknown" errors seems
> > like a good idea to me. Note that some of our academic friends have
> > showed us some evidence that the vast majority of expired certificates
> > get replaced within 14 days, so having OCSP responders return "Good"
> > for expired certificates for a day or a few days seems pretty
> > reasonable. Suggestions?
> 
> We use the unsigned "unauthorized" response for expired certs, as
> permitted by RFC5019:
>    'Requests from clients for
>     certificates whose record has been removed will result in an
>     OCSPResponseStatus of "unauthorized".'

Note that in the NSS implementation every GET that results in anything other than "Good" or "Revoked" will trigger us to do a POST to do cache-busting, IIRC.

> > 6. For must-staple in particular, it may be worthwhile to consider
> > adding a backup OCSP AIA URI to certificates, that is used in case the
> > normal OCSP responder is not working. Then we could change servers'
> > OCSP stapling implementations to try each of the URIs in order. This
> > would likely improve the availability of sites that use must-staple in
> > the event that a CA's CDN experiences downtime.
> 
> Are you suggesting that a backup OCSP AIA URI should be required or
> optional-but-recommended ?

The main change to the baseline requirements I want is to require that nextUpdate be included in every OCSP response and that it be no more than 48 hours later than thisUpdate. Although I agree that "expires immediately; do not cache" is one reasonable interpretation of a missing nextUpdate, our experience has shown that a missing nextUpdate is, for all practical purposes, incompatible with OCSP stapling. This is actually obvious once one realizes that the web server is acting like a proxy cache when it staples OCSP responses. "Expires immediately; do not cache" would mean that the web server would need to make many, many OCSP requests to do OCSP stapling, which is unreasonable.

The other points I made are advice about how to increase interoperability so that OCSP, OCSP stapling, and Must-Staple work as well as possible. My email focused on improvements CAs can make because this is the forum for that. We (Firefox, and web browsers in general) also need to make changes, as do web servers. I will be discussing that stuff in other forums: ietf-tls and the nginx development mailing list, in particular.

BTW, if people are interested in hacking on nginx and/or other web servers to improve OCSP stapling support, please let me know.

Cheers,
Brian


More information about the Public mailing list