OCSP over SSL/TLS

Question

As far as I know, OCSP only provides explicit means for requests and responses to be signed ([RFC2560, page 7] for requests, and [RFC2560, page 8] for responses), but it does not make any mention about encryption. Is it typical (or even possible, which I suppose that of course it is) to run OCSP over SSL/TLS to also guarantee its confidentiality?

Thanks.

Ticktock

Why? Certificates are public documents. What's the risk? – Neuman

I'm just thinking of a [probably] atypical scenario. E.g. I own a company for which I run a private CA, and I don't want any rival company to know which users I am revoking: a revoked user means that he/she is a [probably] fired employee, and they would [probably] be able to bribe him/her in order to gain private information. Or the example that erickson gave below, which seems much more typical. – Ticktock

If you'd think more from a Integrity instead of confidentiality. I think it would be possible to perform MiTM attack, giving an incorrect status about a certificate revocation status, forcing a user to use it's old -compromised- certificate. – Southwesterly

This recent news helped me to surface this old question. The Apple OCSP check is a valid use case to use TLS. It would allow man in the middle or my ISP to spy on the apps I am using and when. blog.jacopo.io/en/post/apple-ocsp – Consultant

Answer 1

Yes, it is possible using SSL/TLS. But consider this:

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

Taken from RFC5280, Section 8. This section addresses the problem using https for CRL distribution points. But you will have the same issue using SSL/TLS for OCSP requests: you have to check the validity of the server certificate...

Glasgow

Answer 2

In the appendix of the RFC2560 is the following written:

A.1.1 Request [...] Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either TLS/SSL or some other lower layer protocol.

But the most OCSP-Responder only provide HTTP without TLS/SSL.

Vastah

Answer 3

It is definitely possible, but it's not typical. If you are requesting the status of a host certificate, the OCSP request is unlikely to reveal anything an eavesdropper doesn't already know—namely, the host that you are trying to authenticate.

For S/MIME email or other applications, OCSP requests could be a lot more sensitive, because they would support organizational analysis. Using HTTPS transport could be be a good idea there.

Stolon

Thanks for your response. But then, since it is quite possible to run OCSP over SSL/TLS, why is encryption not explicitly supported, but signing is? Wouldn't it have been easier to just move all that burden to SSL/TLS (or IPSEC or any other security protocol)? – Ticktock

@Ticktock I think the signatures are there so that responses can be created in advance, or cached by the client. In other words, the signatures protect integrity at rest. I know some commercial OCSP responders offer, for better performance, pre-computation of responses when they process a CRL. These server tend to respond with a chunk of responses, one of which corresponds to the request you made. – Stolon

Makes much sense. Thank you again. – Ticktock