Understanding of OCSP Stapling

Sun and Moon Pagodas
Sun and Moon Pagodas, Shanhu Lake, Guilin, China

What's OCSP Stapling?


OCSP stapling, also known as the TLS Certificate Status Request extension, is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses, instead of the issuing Certificate Authority (CA). [WIKI]

With OCSP stapling, it is the responsibility of the web site to get the OCSP response and send OCSP response to clients/browsers in SSL/TLS handshaking.

OCSP stapling is defined as TLS Certificate Status Request extension in section 8 of RFC 6066.

The Benefits of OCSP Stapling

  1. The performance bottleneck of OCSP server
    If client checks the certificate status directly from OCSP server, for each client with a given certificate, the OCSP server has to response with a particular certificate status. For high traffic web site, OCSP server is likely to be the performance bottleneck.  The client side also need more cycles (DNS, networking, CPU etc.) to communicate with OCSP server.

    OCSP stapling can save OCSP query cost of both OCSP server and clients.  The certificate holder (the server), rather than the client, queries the certificate status from OCSP server in a regular interval.  And the OCSP response can be used directly by client side in a "stapled" approach.  Note that the server performance impact is pretty limited as the OCSP response (valid from hours to days) can be cached and used repeatedly in the valid period.

    The performance impact has very bad side effect that browsers/clients may choose to disable certificate status checking or continue the TLS handshaking if the OCSP server is not accessible (for example, Firefox will continue the connection if it cannot connect to the CA, and the same for IE).

    According to a report from CloudFlare, OCSP stapling can make SSL 30% faster.

  2. The potential privacy impairment of OCSP request
    In normal OCSP scenarios, when client requests a OCSP service, it exposes both the server (via server certificate entry) and itself (via IP address at least) to OCSP server, and hence disclose the browser behaviors.  A way to verify validity without disclosing browsing behavior would be desirable for some groups of users.

    OCSP stapling solved this issue because client won't need to query OCSP server any more, while server queries of OCSP status won't disclose any client information at all.

  3. The limitation of the Captive Portal technique
    The captive portal technique forces an HTTP client on a network to see a special web page (usually for authentication purposes) before using the Internet normally.   In such environments,  clients are not able to check OCSP status of the SSL/TLS certificate since all Internet access is blocked until authentication is successful.

    There is no such limitation with OCSP stapling as OCSP status is stapled within the target SSL handing processes. 

The deployment of OCSP Stapling


In Server side,
In client side,
  • Beginning with Windows Server 2008, Kerberos clients will request OCSP stapling when using PKINIT by default. 
  • Firefox,  since version 25 (and this link).
  • IE (it is said OCSP stapling is supported since Vista, but I did not get the declare yet.  IE 10 does support OSCP stapling according to my test.)
  • Google Chrome browser (no data so far when it get supported.  Chrom version 30 does support it according to my test)
  • Opera browser (no date so far when it get supported. Opera 12.11 does support it according to my test)
TLS Vendors,

Why a SSL/TLS vendor need this feature

  1. Because of performance, we cannot enable OCSP checking on TLS client side by default.  Chrome had decide to disable OCSP checking because of performance.  However, if check certificate status cannot be checked, there is a security issue if certificate has been revoked.
  2. Support OCSP stapling in server side boost the performance and improve security of client sides who supports OCSP stapling.
  3. OCSP based certificate status checking of TLS cannot work in a certain environment, for example in Captive Porta environment.
  4. It's required to check certificate status for EV certificate.
  5. Generally, Java based SSL web server, for example Tomcat/Glassfish,  may also want to support OCSP stapling to better service its customers and compete with other platform, for example Apachs HTTP server, Nginx and Microsoft IIS.
  6. OCSP stapling has been widely supported in the industry in both client and server.

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more