Web Security Part 1: OCSP
Web applications have become an integral part of our everyday lives and are replacing native applications in all areas of business as well as in private use. Today, no app or social network can function without these technologies. The attack surface that web applications offer attackers is also very extensive and sometimes very easy to exploit.
Nevertheless, many companies still find it difficult to correctly assess the impact and risks posed by vulnerabilities and a lack of defensive measures in web applications.
For this reason, over the next few months we will be addressing a number of topics relating to web application security in our blog series: Web Security.
OCSP & OCSP Stapling
OCSP stands for “Online Certificate Status Protocol” and is used by Certificate Authorities (CA) to monitor the revocation of issued x509 certificates. Clients such as operating systems, applications or browsers can use the OCSP protocol to query the status of a certificate from a validation service. OCSP replaces the outdated CRL (Certificate Revocation Lists) and offers several advantages.
How does OCSP work?
When an SSL/TLS protected connection to a web server is established, the web server first delivers the web server x509 certificate to the client or browser. This certificate contains a CRL or an OCSP responder (or both) in the certificate properties. If the client is configured for this, it prefers to validate the certificate using the OCSP protocol. The client then contacts the OCSP responder with the serial number of the certificate and requests its verification. The OCSP responder checks the certificate either directly in the CA database or in a CRL list and gives the client either the status Good (not revoked) or Revoked (revoked).
Advantages and disadvantages of OCSP and CRLs
Certificate revocation lists are only created and published at longer intervals and are therefore not always up-to-date. OCSP queries are usually issued per certificate and can therefore provide answers to the second. OCSP can also distinguish and recognize forged certificates from valid certificates, provided the OCSP responder has been configured for this by the CA.
When certificate revocation lists (CRL) are used, all revoked certificates are included in this list based on the serial number. This results in relatively large CRL files, which are downloaded on each client. This makes the application inefficient and slow, especially for IoT devices and other devices with limited memory, as the entire file has to be checked for each query.
Another disadvantage of OCSP is that each time a page is requested from a web server, the client makes a request to a third party, the certificate issuer (CA). This not only slows down the access to the website but is also questionable in terms of data protection, as the issuer is informed which certificate and therefore which website is being requested.
To prevent this, OCSP stapling was introduced with RFC6066 (https://clue.ch//clue.ch//tools.ietf.org/html/rfc6066).
OCSP Request
In the following OCSP request, we see the request to the CA using the determined OCSP protocol. The request contains information about the requested certificate and the nonce extension, which we will explain later.
OCSP Response
In the following OCSP response, we see the response from the CA with the certificate status: good. This means that the certificate has not been revoked but there is no indication of the nonce.
What is OCSP stapling?
With OCSP, the client (browser agent) is responsible for requesting the certificate status from the CA. These queries can lead to a delay in accessing the website and also represent a privacy violation, as this query enables the CA provider to log the website accesses. The alternative variant of OCSP stapling was therefore introduced.
When initiating the TLS handshake with the web server, it can send the OCSP validation message with the certificate in the response. This allows the client to complete the request more quickly. The web server acts as a kind of proxy for the OCSP request.
The web server or reverse proxy sends the OCSP request to the OCSP responder and caches the response according to the settings, thereby speeding up the responses to the client.
How can I check the OCSP status?
Checking the OCSP status is relatively simple. A few further steps are necessary to query a correct OCSP stapling function. We use the Linux tool openssl in our examples, but the commands could also be executed with curl, for example.
OCSP Stapling Traffic Capture
In this traffic capture you can see that OCSP Stapling does not establish a separate OCSP connection to the OCSP responder, but that the certificate status response is implemented in the TLS confirmation of the web server.
OCSP response expired
When checking the OCSP configuration, you often see the status OCPS Stapling ok, but also error messages such as “OCSP Response Expired”. This indicates that OCSP stapling is configured, but the web server or reverse proxy cannot query the current status from the CA. The reasons for this could be limited network communication, a fault with the OCSP responder or a lack of trust in the CA based on the x509 certificate chain.
