I’m writing this paper to explain how OCSP functionality can be extended utilizing the new TLS 1.0 Extensions defined in the RFC 3546 http://www.ietf.org/rfc/rfc3546.txt.
To simplify things we have John trying to access www.contoso.com using TLS Sessions .RFC 3546 defines new extensions to the TLS Hello packets in which the TLS client and the Servers exchange.
This what will happen…John will connect to the www.contoso.com (we will name it Contoso portal) .John will say :Hey I need to communicate using TLS 1.0 .The Contoso portal will say : “Ok I support TLS 1.0 also”.John will say : “By the way I support the those specific new TLS 1.0 Extensions defined by the RFC 3546” .The Contoso portal will reply : “Me too , I support those specific extensions explicitly “.
So far so good , lets move on to the new things .Let us start talking about OCSP current problem .OCSP is good ,I like it ,but think of a big CA hierarchy in which it is exposed to the Internet using one OCSP responder .The server will become congested with high processing load on it.Think about VeriSign for example .Their online responder will receive thousand of request per minute.Additional problem is Privacy concern for some users because they are required to connect to third party for revocation validation.
To illustrate the problem ,I will give the same example ,John trying to connect to www.contoso.com portal that is using VeriSign Certificate .John will connect to the portal and download the server certificate from Contoso portal.Then using the OCSP info on the consol portal certificate ,John will connect to the VeriSign OCSP Listener to validate the certificate status,Thus John should connect to third part (VeriSign listener) in this case,creating privacy issue and additional traffic from his side.Add to this that the OCSP listener will receive a hit in this case from John’s Browser .
So ,why not to have a solution in which Contoso portal can provide all the information that John is requesting to establish the TLS session and create mutual trust in one TCP Session.Of course without the need to hit the VeriSign OCSP listener.
Solution is OCSP Stapling
The solution works by utilizing the TLS new Extensions . In this case , Contoso portal (Certificate Holder) will periodically contact VeriSign OCSP Listener and request a signed time-stamped response (this is something like the Contoso portal asking VeriSign “Hey,can you give me an official paper from you saying that my certificate is valid until the next x days” ) .The Contoso portal will cache this signed response each time.
Now back to John .John now will contact Contoso portal .Contoso Portal will send John the following:
1. its own certificate ( certificate of www.contoso.com)
2. Chain of Certificates above its own certificate (i.e those are the issuing VeriSign Certificates).
3. The Signed Time Stamp response (This is signed by the VeriSign issuing CA).
Now John has all the info he needs without the need to contact any OCSP responder.Thus one TCP TLS session to do all the job.Note that this will reduce the load on VeriSign OCSP Listener.
This all happen by injecting the previous certificates on the TLS 1.0 New extensions ,so John will say : “Hey , I want to open TLS 1.0 with you Contoso Portal , and by the way i support the new TLS extensions, do you? ” .Contoso Portal will reply “Yes i also support those specific extensions”.John will reply back ” so hit me with your OCSP Signed Time Stamp Response”.The Contoso Portal will send the Certificate Chain along with the Signed Time Stamp Response during the TLS handshake.
OCSP Stapling Attacks
One of the valid attacks can be Replay attacks in which an attacker can reply the “good” OCSP response for his site to an OCSP client even after his site certificate is revoked .This attack can be solved by adding a nonce to the OCSP response.In security engineering, a nonce stands for number used once.It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.