OCSP stapling

Last updated

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. [1] It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

Contents

Motivation

The original OCSP implementation has a number of issues.

Firstly, it can introduce a significant cost for the certificate authorities (CA) because it requires them to provide responses to every client of a given certificate in real time. For example, when a certificate is issued to a high traffic website, the servers of CAs are likely to be hit by enormous volumes of OCSP requests querying the validity of the certificate. [2]

Also, OCSP checking potentially impairs users' privacy and slows down browsing, since it requires the client to contact a third party (the CA) to confirm the validity of each certificate that it encounters. [2] [3]

Moreover, if the client fails to connect to the CA for an OCSP response, then it is forced to decide between: (a) continuing the connection anyway; defeating the purpose of OCSP or (b) terminating the connection based on the assumption that there is an attack; but which could result in excessive false warnings and blocks. [4]

OCSP stapling is aimed at addressing these issues with the original OCSP implementation. [5] [6]

Solution

OCSP stapling resolves both problems in a fashion reminiscent of the Kerberos ticket. In a stapling scenario, the certificate holder itself queries the OCSP server at regular intervals, obtaining a signed time-stamped OCSP response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL handshake via the Certificate Status Request extension response (note: the TLS client must explicitly include a Certificate Status Request extension in its ClientHello TLS/SSL handshake message). [7]

While it may appear that allowing the site operator to control verification responses would allow a fraudulent site to issue false verification for a revoked certificate, the stapled responses can't be forged as they need to be directly signed by the certificate authority, not the server. [6] If the client does not receive a stapled response, it will just contact the OCSP server by itself. [4] However, if the client receives an invalid stapled response, it will abort the connection. [1] The only increased risk of OCSP stapling is that the notification of revocation for a certificate may be delayed until the last-signed OCSP response expires.

As a result, clients continue to have verifiable assurance from the certificate authority that the certificate is presently valid (or was quite recently), but no longer need to individually contact the OCSP server. This means that the brunt of the resource burden is now placed back on the certificate holder. It also means that the client software no longer needs to disclose users' browsing habits to any third party. [2]

Overall performance is also improved: When the client fetches the OCSP response directly from the CA, it usually involves the lookup of the domain name of the CA's OCSP server in the DNS as well as establishing a connection to the OCSP server. When OCSP stapling is used, the certificate status information is delivered to the client through an already established channel, reducing overhead and improving performance. [5]

Specification

The TLS Certificate Status Request extension is specified in RFC   6066, Section 8.

RFC   6961 defines a Multiple Certificate Status Request extension, which allows a server to send multiple OCSP responses in the TLS handshake.

A draft proposal for an X509v3 extension field, which expired in April 2013, specified that a compliant server presenting a certificate carrying the extension must return a valid OCSP token in its response if the status_request extension is specified in the TLS client hello. [8] The current version of the proposal has been extended to support additional TLS extensions. [9] TLS developer Adam Langley discussed the extension in an April 2014 article following the repair of the Heartbleed OpenSSL bug. [10]

Deployment

OCSP stapling support is being progressively implemented. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3, [11] the nginx web server since version 1.3.7, [12] LiteSpeed Web Server since version 4.2.4, [13] Microsoft's IIS since Windows Server 2008, [14] HAProxy since version 1.5.0, [15] F5 Networks BIG-IP since version 11.6.0, [16] KEMP LoadMasters since Version 7.2.37.1, and lighttpd since version 1.4.56. [17]

While many web servers advertise support for OCSP stapling, implementations are not always reliable. [18] For example, when Apache queries the OCSP server, in the event of a temporary failure, it will discard the cached good response from the previous request, and start serving bad response. [19] Nginx performs lazy loading of OCSP responses, which means that for the first few web requests it is unable to add the OCSP response. [20]

On the browser side, OCSP stapling was implemented in Firefox 26, [4] [21] in Internet Explorer since Windows Vista, [22] and Google Chrome in Linux, ChromeOS, and Windows since Vista. [23]

For SMTP the Exim message transfer agent supports OCSP stapling in both client [24] and server [25] modes.

Limitations

OCSP stapling is designed to reduce the cost of an OCSP validation, both for the client and the OCSP responder, especially for large sites serving many simultaneous users. However, OCSP stapling supports only one OCSP response at a time, which is insufficient for certificate chains with intermediate CA certs. [26] [27]

This limitation has been addressed by Multiple Certificate Status Request Extension, specified in RFC   6961. It adds the support for sending multiple OCSP responses. [28]

TLSv1.3 automatically removes this limitation, making browser support for RFC   6961 moot, as more and more web servers drop support for TLS 1.2. Under TLS 1.2 only one stapled response can be sent by a server, the OCSP response associated with the end-certificate. Under TLS 1.3 a server can send multiple OCSP responses, typically one for each certificate in the certificate chain. [29]

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes information about the key, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

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 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<span class="mw-page-title-main">HTTP compression</span> Capability that can be built into web servers and web clients

HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.

SPDY is an obsolete open-specification communication protocol developed for transporting web content. SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

The Transport Layer Security (TLS) protocol provides the ability to secure communications across networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 on May 14, 2015.

Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension that allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application-layer protocols. It is used to establish HTTP/2 connections without additional round trips.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

The Caddy web server is an extensible, cross-platform, open-source web server written in Go.

In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker would be able to exploit such a compromised or misissued certificate until expiry. Hence, revocation is an important part of a public key infrastructure. Revocation is performed by the issuing certificate authority, which produces a cryptographically authenticated statement of revocation.

References

  1. 1 2 Eastlake, D. (January 2011). "Transport Layer Security (TLS) Extensions: Extension Definitions: Certificate Status Request". Internet Engineering Task Force (IETF). Retrieved March 2, 2015.
  2. 1 2 3 A., Jesin (June 12, 2014). "How To Configure OCSP Stapling on Apache and Nginx". Community Tutorials. Digital Ocean, Inc. Retrieved March 2, 2015.
  3. ↑ Note: With Microsoft CA and OCSP service (for example the type used as part of a typical Active Directory Domain) the OCSP service does not have to check back with the CA each time it wants to check the status of a certificate (thereby reducing the load in the CA). The OCSP service (generally running on a separate server to the CA) references the CRL (certificate revocation list) which is published typically once per week by the CA (schedule can be changed) and uses this as its source of information for checking the status of certificates.
  4. 1 2 3 Keeler, David (July 29, 2013). "OCSP Stapling in Firefox". Mozilla Security Blog. Mozilla Foundation. Retrieved March 2, 2015.
  5. 1 2 Prince, Matthew (October 29, 2012). "OCSP Stapling: How CloudFlare Just Made SSL 30% Faster". CloudFlare, Inc. Retrieved March 2, 2015.
  6. 1 2 Gibson, Steve. "Security Certificate Revocation Awareness: The case for "OCSP Must-Staple"". Gibson Research Corporation. Retrieved March 2, 2015.
  7. ↑ "OCSP Stapling". GlobalSign Support. GMO GlobalSign Inc. August 1, 2014. Retrieved March 2, 2015.
  8. ↑ P. Hallam-Baker, X.509v3 Extension: OCSP Stapling Required
  9. ↑ P. Hallam-Baker X.509v3 TLS Feature Extension draft-hallambaker-tlsfeature-05
  10. ↑ A. Langley, No, don't enable revocation checking, April 19, 2014.
  11. ↑ Apache HTTP Server mod_ssl documentation - SSLUseStapling directive
  12. ↑ nginx-announce mailing list - nginx-1.3.7
  13. ↑ Release Log - Litespeed Tech. Retrieved 2014-02-07,
  14. ↑ Duncan, Robert. "Microsoft Achieves World Domination (in OCSP Stapling)". Netcraft Ltd. Retrieved 28 April 2014.
  15. ↑ HAProxy website
  16. ↑ Release Note: BIG-IP LTM and TMOS 11.6.0
  17. ↑ "lighttpd 1.4.56 release info". redmine.lighttpd.net.
  18. ↑ The Problem with OCSP Stapling
  19. ↑ Apache OCSP bug
  20. ↑ Nginx OCSP bug
  21. ↑ Improving Revocation - MozillaWiki, retrieved 2014-04-28
  22. ↑ "How Certificate Revocation Works". TechNet. Microsoft. 16 March 2012. Retrieved 28 April 2014.
  23. ↑ "Issue 361820: Check For Server Certificate Revocation checkbox is confusing". Google Code. 10 April 2014.
  24. ↑ The smtp transport, retrieved 2015-01-24
  25. ↑ Main configuration, retrieved 2015-01-24
  26. ↑ Mozilla NSS Bug 360420, Comment by Adam Langley
  27. ↑ Mozilla NSS Bug 611836 - Implement multiple OCSP stapling extension
  28. ↑ Pettersen, Yngve N. (June 2013). "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension". Internet Engineering Task Force . Retrieved 31 October 2014.
  29. ↑ "OCSP stapling (GnuTLS 3.7.4)".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.