Online Certificate Status Protocol Stapling Intro
In this post, I will be talking about Online Certificate Status Protocol Stapling (or OCSP Stapling), and how OCSP functionalities can be extended utilizing the new TLS 1.0 Extensions defined in the RFC 3546.
For those who do not know, the Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960.
Online Certificate Status Protocol Stapling, was formally known as a TLS extension to OCSP, and it is a new approach to OCSP for checking the revocation status of digital certificates. The main goal of this new approach is to save resources on the CA by eliminating the need for certificate consumers to contact the CA.
To simplify things, we have John trying to reach www.contoso.com using TLS Sessions. RFC 3546 defines new extensions to the TLS Hello packets, where the TLS client and the Servers exchange.
This what will happen. John will connect to the www.contoso.com. John will say: “Hey Contoso portal, I need to communicate using TLS 1.0” .Contoso portal will reply: “Ok, I support TLS 1.0 also“. John will then say something like: “By the way, I also support the those specific new TLS 1.0 Extensions defined in the RFC 3546” .Contoso portal will then respond: “Me too , I support those specific extensions explicitly“.
This is how a client and a server would negotiate Online Certificate Status Protocol Stapling. It is a new way to do OCSP and digital certificate revocation check.
Online Certificate Status Protocol Problem
The question I always ask myself is, why to introduce new extension, or version to an existing functioning specification? I always like to identity the current problem and limitation, before jumping to solutions. This will eventually make me more aware of the new specification.
Let me start by saying that OCSP is very good specification, that allows an entity to verify the revocation status of a certificate, without the need to download the whole revocation list or CRL. But let us think of a big CA implementation, where it is exposed to the Internet using one OCSP responder .The server will become congested with high processing load. Think about VeriSign for example. Their OCSP server receives thousands of requests per minute trying to answer all those using certificates issued by Verisign.
Now let us think of the certificate consumer or client. There is a privacy concern for some parties to connect to external OCSP servers for certificate revocation. In extremely locked down environment, this might be a problem.
To illustrate the problem ,I will give the same example. John is trying to connect to www.contoso.com portal which happen to be protected using VeriSign Certificate0. John will connect to the portal and download the server certificate from Contoso portal. Then using the OCSP information on the Consol portal certificate, John will connect to the VeriSign OCSP Listener to validate the certificate status. In other words, John should connect to third party service (VeriSign OCSPlistener in this case), creating a privacy concern and additional traffic from his side. Add to this that the OCSP listener will receive a hit in this case from John’s Browser .
Why not to have a solution where Contoso portal can give all the information that John is requesting to set up the TLS session, and create mutual trust in one TCP Session without hitting VeriSign OCSP server?
Online Certificate Status Protocol Solution
The solution works by utilizing the TLS new Extensions. In this case, Contoso portal (the certificate holder) will periodically contact VeriSign OCSP Listener, and ask a signed time-stamped response. Think of this like Contoso portal asking VeriSign this: “Hey VeriSign, I am Contoso portal. Can you give me an official paper from you, saying that my certificate is valid until the next x days or so! .Contoso portal will then cache this signed response for later use.
Now back to poor John. John now will contact Contoso portal. Contoso Portal will send John the following:
- Its own certificate (server certificate for www.contoso.com)
- Chain of certificates above its own certificate (i.e those are the issuing VeriSign Certificates).
- The Signed Time Stamp response (This is signed by the VeriSign issuing CA).
John now has all the information he needs, without the need to contact any OCSP responders. One TCP TLS session to do all the job. Note that this will reduce the load on VeriSign OCSP Listener also.
The communication between John and the web portal will go like this. John will start by saying: “Hey, I want to open TLS 1.0 with you Contoso Portal, and by the way I support the new TLS extensions or the Online Certificate Status Protocol Stapling , do you? ” .Contoso Portal will reply: “Yes, I also support those specific extensions“. John will reply: “So hit me with your OCSP Signed Time Stamp Response“. Contoso Portal will send the Certificate Chain along with the Signed Time Stamp Response during the TLS handshake.
Online Certificate Status Protocol 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. 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.