Online Certificate Status Protocol (OCSP)

When you go to a website that uses an SSL certificate, such as a bank or shopping site, the browser needs to verify that the website is using a valid (current) SSL certificate. The Online Certificate Status Protocol (OCSP) is used to verify whether an X509 SSL certificate is still valid.

When verifying the security of a new HTTPS connection, it is up to the connecting client (e.g., web browser) to verify that a certificate presented by an SSL server (i.e., EFT) has not been revoked by the CA that issued the certificate. To verify whether the certificate is valid, the browser queries an OCSP server, such as a certificate authority (CA).

Traditionally, the client (web browser) performs the SSL handshake to obtain the server certificate, then it performs queries against Certificate Revocation Lists (CRLs) and Online Certificate Status Request Protocol (OCSP) servers. This causes some extra traffic and cryptographic operations to take place during the initial connection to a remote HTTPS server, which causes a perceptible delay in that connection.

OCSP Stapling

"OCSP stapling" allows the web server to query the OCSP server and then save the response, which is then delivered to the browser, and is valid for a certain period of time. With OCSP stapling, the CA no longer receives the revocation requests directly from the browser, and there is no need for a separate network connection to the CA, preventing negotiation delays. A token is passed to the client in place of the client having to go ask for the full list/parse on each connect. OCSP Stapling is an optimization mechanism that allows all the verification of the server certificate to happen within the initial SSL handshake, rather than requiring additional round trips to other servers.

Without the stapled OCSP certificate being presented by the HTTPS server, it is the responsibility of the connecting client (e.g., web browser) to use traditional OCSP or CRL queries to CAs to obtain revocation information. Both mechanisms are still available, and initiated by the client, not the server.

Thus, the absence of OCSP stapling support is not a security vulnerability, but a lack of optimization. Browsers will still validate server identity via the SSL certificate and any revocation information from CA sources.

If you have F5 Big IP LTM devices (LTM 11.6 or later), you could configure them to terminate SSL connections at that device, which means that you could easily add OCSP Stapling to your certificates using the traffic manager. Traffic would then be forwarded along as HTTP to the server. (The F5 Big IP LTM needs to have an iRule to add an "X-ORIGINAL-PROTOCOL" header to all HTTP requests.)

Refer to https://lessonsintech.wordpress.com/2016/02/10/configure-ocsp-stapling-f5-ltm/ and https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-6-0/4.html for more information.

OCSP Stapling in EFT

  1. The web browser opens a connection to EFT over HTTPS. Part of the handshake includes an extension request that asks for the stapled OCSP response.

  2. EFT, if it already has that response, simply returns the response to the client.

  3. EFT periodically performs an OCSP query of its own SSL certificate, in case there have been any revocations or changes, and then saves the signed result into a cache. It is from there that EFT will offer the stapled OCSP response to the web browser. The round-trip between EFT and the OCSP server does *not* happen for every browser request, but only when the OCSP response is not found in the EFT cache, or if the cached response has expired.

The graphic below illustrates the process of OCSP stapling in EFT at a very high level.

How can I verify that OCSP stapling in EFT is working?

Because the SSL handshake itself is doing the OCSP Stapling request and response, you should be able to verify that stapling works for any protocol endpoint (FTPS and HTTPS and AS2) by using the OpenSSL command-line client, and passing in the "-status" flag, which indicates that the client hello needs to request the certificate status request (i.e., "ocsp stapling request"):

openssl s_client -status -no_ssl2 -no_ssl3 -no_tls1  -host eft.company.com -port 443

You can observe the output from OpenSSL (and/or look at Wireshark captures) to see if the OCSP request and response are as expected. (Once you get past the handshake and establish SSL tunnel, the rest of the protocol doesn't really matter.) OCSP Stapling in EFT does not support proxy configurations  

Refer to the Knowledgebase for OCSP-related advanced properties:

  • https://kb.globalscape.com/KnowledgebaseArticle11362.aspx - Adjust for time drift (skew) between the CA and EFT for OCSP requests

  • https://kb.globalscape.com/KnowledgebaseArticle11363.aspx - Specify a maximum allowable age for OCSP stapling responses

  • https://kb.globalscape.com/KnowledgebaseArticle11364.aspx - Override the OCSP responder URI specified in the certificate's AIA extension

  • https://kb.globalscape.com/KnowledgebaseArticle11365.aspx - Enable the OCSP response

  • https://kb.globalscape.com/KnowledgebaseArticle11366.aspx - OCSP Stapling cache timeout