Certificate revocation

Last updated

In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker could 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.

Contents

For distributing revocation information to clients, the timeliness of the discovery of revocation (and hence the window for an attacker to exploit a compromised certificate) trades off against resource usage in querying revocation statuses and privacy concerns. If revocation information is unavailable (either due to an accident or an attack), clients must decide whether to fail-hard and treat a certificate as if it is revoked (and so degrade availability) or to fail-soft and treat it as unrevoked (and allow attackers to sidestep revocation).

Due to the cost of revocation checks and the availability impact from potentially-unreliable remote services, Web browsers limit the revocation checks they will perform, and will fail soft where they do. Certificate revocation lists are too bandwidth-costly for routine use, and the Online Certificate Status Protocol presents connection latency and privacy issues. Other schemes have been proposed but have not yet been successfully deployed to enable fail-hard checking.

Glossary of acronyms

ACME
Automatic Certificate Management Environment
CA
certificate authority
CA/B
CA/Browser Forum
CRL
certificate revocation list
CRV
certificate revocation vector
OCSP
Online Certificate Status Protocol
PKI
public key infrastructure
TLS
Transport Layer Security

History

The Heartbleed vulnerability, which was disclosed in 2014, triggered a mass revocation of certificates, as their private keys may have been leaked. GlobalSign revoked over 50% of their issued certificates. StartCom was criticised for issuing free certificates but then charging for revocation. [1]

A 2015 study found an overall revocation rate of 8% for certificates used on the Web, [2] though this may have been elevated due to Heartbleed. [3]

Despite Web security being a priority for most browsers, due to the latency and bandwidth requirements associated with OCSP and CRLs, browsers place limits on checking certificate status. [4] In 2015, Google Chrome only actively checked Extended Validation certificates, no mobile browser performed any validity checks, and no browser fully checked all certificates. [5] Chrome and Firefox perform push-based checks for a small set of domains deemed critical. [6] Browsers show little agreement in corner cases around certificate validity, potentially confusing even experienced users. [7]

The number of certificates in the Web PKI increased massively during the last portion of the 2010s, from 30 million in January 2017 to 434 million in January 2020. A significant factor in this growth is Let's Encrypt providing free domain validated certificates. The size of the potentially-revocable set of certificates places requirements on the scalability of the revocation mechanism. [4]

Chuat et al. (2020) call revocation "notoriously challenging". [8] In 2022, RFC 9325 characterised certificate revocation as an important problem with "no complete and efficient solution". OCSP and OCSP stapling are recommended as the "foundation for a possible solution". [9]

Necessity

Certificate revocation is "an important tool" for dealing with attacks and accidental compromises. RFC 9325 places a normative requirement on TLS implementations to have some means of distrusting certificates. [9] Without revocation, an attacker can use a compromised certificate to impersonate its owner until expiry. [4]

Revocation may not be necessary for certificates of sufficiently short lifetime, roughly on the order of hours to days, which is comparable to the lifetime of an OCSP response. The associated frequent certificate issuance typically requires automation (e.g., the ACME protocol) and may stress other infrastructural elements (e.g., transparency logs). [10] Short-lived certificates also present complications with TLS connection resumption, though not necessarily insuperably. [11]

Procedure

Revocation may be initiated by a certificate holder (who, for example, may know that a private key has been compromised), who informs the CA. The CA then produces and distributes cryptographically authenticated attestations that the certificate has been revoked. [12] The CA/B requirements also allow a CA to autonomously revoke certificates if the CA is aware of a possibility of compromise. [13] Anyone may submit such evidence. [14]

Revocation statuses are not typically preserved and archived for long beyond the certificate's expiry, making research into and auditing of revocation behaviours difficult. [15] One proposal to solve this involves submitting 'postcertificates' to Certificate Transparency logs for each revocation, which would also allow revocation to be performed without action by a CA; [16] an alternative proposal, also based around Certificate Transparency, involves CRVs being sent to the CT logs by CAs. [17]

Informing clients

Considerations

Failure model

If revocation status is unavailable (which may be benign or due to an attack), a client is faced with a dilemma when evaluating a certificate: it may fail-soft and assume that the certificate is still valid; or it may fail-hard and assume that the certificate has been revoked. This is a trade-off between security and availability: failing-soft allows downgrade attacks, while failing-hard allows denial of service (from attacks) or causes unavailability. [18]

An attacker with the ability to present a compromised certificate likely also has the ability to prevent the client performing an online revocation status check; in this case, failing-soft effectively provides no protection at all. Browsers have chosen this arm of the dilemma and preferred availability over security. [19]

Failing-hard can introduce new denial-of-service attack vectors. For example, if clients expect OCSP stapling and fail-hard otherwise, a denial of service against OCSP responders is amplified to a denial of service against all services wishing to use those OCSP responses. [10]

Resource usage

There are two scenarios for the evaluation of resource usage: normal conditions, and mass revocation events. Revocation schemes should be efficient under normal conditions, and functional during mass revocation events. [4]

Retrieving revocation information incurs bandwidth and latency costs for clients. [20]

During the 2014 Heartbleed mass revocation event, where revocation rates rose from 1% to 11%, Cloudflare estimated that the bandwidth that GlobalSign used to distribute CRLs could have cost 400,000 USD (equivalent to 490,000 USD in 2022 [21] ). [22]

Timeliness

If revocation status is not freshly retrieved for every check (e.g., due to caching or periodic retrievals), there is a delay between a certificate being revoked and all clients being guaranteed to be aware of the revocation. This presents a trade-off between latency, efficiency, and security: longer cache times or less-frequent updates use fewer resources and reduce latency but mean that a compromised certificate can be abused for longer. [23]

Privacy

Clients that perform pull-based checks can leak the user's browsing information to third parties, namely the distributor of revocation information. [24]

Auditability

It is desirable to avoid creating a trusted third party in a PKI. If an actor within a scheme is auditable, then clients (or agents acting on behalf of clients) can provably verify that an actor is behaving correctly. [25]

Deployability

A revocation status distribution that places heavy burdens on CAs may not succeed, especially if the CA is unable to derive countervailing benefits from implementation. Reducing the number of parties that must make changes to adopt it also eases deployability: potentially involved are CAs, clients, server administrators, and server software producers. Forwards compatibility is a double-edged sword, in that old clients and servers will not be disrupted by a new scheme, but their users may not realise that they are missing the benefits of revocation. [26]

Architectures

There are three broad architectures for how clients access revocation status: pull-based, where clients retrieve revocation status at validation time; push-based, where clients retrieve revocation status ahead of validation and cache it; and network-assisted, where revocation checking is tightly integrated with the TLS protocol and separate checks may not be needed. [27]

Pull-based checking typically has latency and availability issues. Clients performing pull-based checking will typically cache responses for a short period. A purely pull-based check combined with failing-soft does not add security. [28]

Push-based checking is less bandwidth efficient than pull-based checking, but gains availability and privacy. Different methods may be used on a certificate-by-certificate basis, allowing for fine-tuning the trade-off: both Google Chrome and Mozilla Firefox perform push-based checks on a small set of critical certificates. [28]

Certificate revocation lists

A certificate revocation list (CRL) enumerates revoked certificates. They are cryptographically authenticated by the issuing CA. [29]

CRLs have scalability issues, and rely on the client having enough network access to download them prior to checking a certificate's status. [9]

A CRL contains information about all of the certificates revoked by a CA, which means distributors and clients must incur transfer costs for information that is likely irrelevant. [30] A 2015 study found that the median certificate had a CRL with size 51 kB, and the largest CRL was 76 MB. [2]

OCSP

The Online Certificate Status Protocol (OCSP) allows clients to interactively ask a server (an OCSP responder) about a certificate's status, receiving a response that is cryptographically authenticated by the issuing CA. [29] It was designed to address issues with CRLs. [30] A typical OCSP response is less than 1 kB. [31]

OCSP suffers from scalability issues. It relies on the client having network access at the time of checking the certificate's revocation status; further, the OCSP responder must be accessible and produce usable responses, or else the check will fail and the client must choose between failing-soft and failing-hard. Many certificate authorities do not publish useful OCSP responses for intermediate certificates. [9]

As requests to the responder are made in response to users' browsing, OCSP responders can learn about the users' browsing, which is a privacy issue. It also introduces latency to connections, as the responder must be queried before a new connection can be used. [18]

A 2018 study found that 1.7% of requests to responders were unavailable at the network level, and a further c. 2% produced unusable OCSP responses, with significant hetereogeneity across CAs and client vantage points. [32]

OCSP stapling

OCSP stapling is a TLS extension providing for OCSP responses being provided to the client, together with the certificate, at connection initiation. [30]

OCSP stapling can solve the operational challenges of OCSP, namely additional network requests causing latency and privacy degradation. [33] However, it can be susceptible to downgrade attacks by an on-path attacker. [9] RFC 7633 defines an extension that embeds a requirement into a certificate to be stapled to a valid OCSP response. [34] With this extension, stapling can be effective for the case where a certificate has been compromised after proper issuance; however, if a certificate can be misissued without the extension, stapling may not provide any security. [35]

Beyond clients and CAs enabling stapling and the must-staple extension, server administrators must also take action to support stapling by regularly retrieving responses and then providing them to clients during the handshake. In 2018, only Firefox supported must-staple, and neither of the two most-used Web servers (Apache httpd and Nginx) supported OCSP stapling at all. [36]

CRLite

CRLite provides revocation statuses by a cascade of Bloom filters. A single filter constructed from a list of revoked certificates produces false positives. With an open domain, this is an insuperable problem for revocation checking. However, by using Certificate Transparency to enumerate all unexpired certificates, an exhaustive list of false positives can be produced. This list is then used to construct a second filter, which is consulted if a certificate matches the first (and hence has a strictly smaller domain); if the second filter does not match, then it is a true positive and the certificate has been revoked; however, a match in the second filter may be a false negative, necessitating a third filter, and so on. As the universe is finite and the domain of each filter strictly decreases at each step, this procedure produces a finite filter cascade. [37]

CRLite allows clients to fail-hard. [23]

The revocation status of all certificates in the Web PKI in January was estimated to be 10 MB in size when using the Bloom filter cascade, with updates of 580 kB per day. In March 2018, this had grown to 18 MB. [28] In a simulation with 100 million certificates, a 1% daily expiration rate, and a 2% revocation rate, CRLite required an initial provision of 3.1 MB, and then 408 kB per day for updates. [38]

As all clients retrieve the same information, CRLite has no privacy concerns. [23]

CRLite has not yet been widely deployed. [9] It is, however, deployable, only requiring an aggregator to retrieve CRLs from CAs and then provide the filter cascade and updates to it, and for clients to use it; no action from CAs is needed, and nor is any needed from certificate holders. [23] The aggregator does not need to be a trusted third party: the filter cascade can be audited to prove that it accurately reflects the input CRLs. [39] Private CAs also require special handling within CRLite. [40]

Let's Revoke

Let's Revoke uses bit vectors of revocation statuses (called certificate revocation vectors, or CRVs) to allow large amounts of revocation statuses to be efficiently retrieved by clients. [4] CAs generate CRVs for their own certificates, with one CRV per expiration date. CRV maintenance for CAs is linear in the number of certificates issued. CAs must add a new field, a revocation number, to each issued certificate, allowing certificates from a single CA to be identified by a tuple of certificate expiration date and revocation number; this tuple allows a client to efficiently locate a bit giving the identified certificate's status within the CRV. CRVs may be compressed; they are expected to compress very well, as most bits will be unset most of the time. As each CRV is associated with a fixed expiration date, old CRVs can be efficiently discarded. Updates to CRVs are batched, with the update timestamped and signed for distribution to clients. [41] The updates may be in one of three forms, with the optimal choice depending on the revocation rate, allowing for both efficient normal operation and mass revocation events. [42]

CRVs are expected to be small enough to enable push-based checking, but more constrained clients may still perform pull-based checks, only accessing select CRVs, or deferring retrieval of CRVs until certificate validation. [43] A client using Let's Revoke with push-based checking is able to fail-hard for any certificate with a revocation number. [23] The privacy impact and availability of Let's Revoke depends on the architecture: if all checks are push-based, then there is no privacy leakage and a reduced vulnerability to denial-of-service or downtime; if pull-based checks are used, however, some information about the user's activities is leaked (in the form of which CRVs are accessed), and the CRVs may be inaccessible at validation time. [23]

In a simulation with 100 million certificates, 1% daily expiration rate, and a 2% revocation rate, Let's Revoke required an initial provision of 2.2 MB, and then 114 kB per day for updates. [44]

Let's Revoke has not yet been widely deployed. [9] Besides client implementations, it requires CAs to make operational changes, [45] and does not provide as much information as CRLs or OCSP (only a bit per certificate for validity); CRLs or OCSP may still be used to supplement Let's Revoke and provide that additional information. [46] Deployment can be performed CA by CA, with clients benefitting from fail-hard behaviour incrementally. Due to the efficiency of CRVs over CRLs and OCSP responses, CAs may be incentivised to deploy Let's Revoke. [45]

Other proposals

Private information retrieval techniques can allay the privacy concern with pull-based checks. [47] Rather than clients performing revocation checks, a middlebox could instead, centralising the cost of revocation checking and amortising it across many connections; the clients need to dedicate no storage to revocation information. [48] Another proposal involved broadcasting revocation information on FM radio. [37]

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.

<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 revocation list is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted". CRLs are no longer required by the CA/Browser forum, as alternate certificate revocation technologies are increasingly used instead. Nevertheless, CRLs are still widely used by the CAs.

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.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

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">Extended Validation Certificate</span> Certificate for HTTPS websites and software

An Extended Validation Certificate (EV) is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

cryptlib is an open-source cross-platform software security toolkit library. It is distributed under the Sleepycat License, a free software license compatible with the GNU General Public License. Alternatively, cryptlib is available under a proprietary license for those preferring to use it under proprietary terms.

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. 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.

An offline root certificate authority is a certificate authority which has been isolated from network access, and is often kept in a powered-down state.

StartCom was a certificate authority founded in Eilat, Israel, and later based in Beijing, China, that had three main activities: StartCom Enterprise Linux, StartSSL and MediaHost. StartCom set up branch offices in China, Hong Kong, the United Kingdom and Spain. Due to multiple faults on the company's end, all StartCom certificates were removed from Mozilla Firefox in October 2016 and Google Chrome in March 2017, including certificates previously issued, with similar removals from other browsers expected to follow.

A TLS termination proxy is a proxy server that acts as an intermediary point between client and server applications, and is used to terminate and/or establish TLS tunnels by decrypting and/or encrypting communications. This is different to TLS pass-through proxies that forward encrypted (D)TLS traffic between clients and servers without terminating the tunnel.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

<span class="mw-page-title-main">Certificate Authority Security Council</span>

The Certificate Authority Security Council (CASC) is a multi-vendor industry advocacy group created to conduct research, promote Internet security standards and educate the public on Internet security issues.

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.

In public key infrastructure, a validation authority (VA) is an entity that provides a service used to verify the validity or revocation status of a digital certificate per the mechanisms described in the X.509 standard and RFC 5280.

Delegated credential is a short-lived TLS certificate used to improve security by faster recovery from private key leakage, without increasing the latency of the TLS handshake. It is currently an IETF Internet Draft, and has been in use by Cloudflare and Facebook, with browser support by Firefox.

References

  1. ↑ Durumeric et al. 2014, p. 482.
  2. 1 2 Liu et al. 2015, p. 184.
  3. ↑ Liu et al. 2015, p. 187.
  4. 1 2 3 4 5 Smith, Dickinson & Seamons 2020, p. 1.
  5. ↑ Liu et al. 2015, p. 190.
  6. ↑ Bruhner et al. 2022, p. 2.
  7. ↑ Wazan et al. 2017, IV. Conclusion.
  8. ↑ Chuat et al. 2020, p. 3.
  9. 1 2 3 4 5 6 7 Sheffer, Saint-Andre & Fossati 2022, 7.5. Certificate Revocation.
  10. 1 2 Smith, Dickinson & Seamons 2020, p. 4.
  11. ↑ Chuat et al. 2020, p. 9-10.
  12. ↑ Chung et al. 2018, p. 3.
  13. ↑ CA/B 2022, p. 54-55.
  14. ↑ CA/B 2022, p. 56.
  15. ↑ Korzhitskii & Carlsson 2021, p. 1.
  16. ↑ Korzhitskii, Nemec & Carlsson 2022, p. 1.
  17. ↑ Leibowitz et al. 2021, p. 7-8.
  18. 1 2 Larisch et al. 2017, p. 542.
  19. ↑ Smith, Dickinson & Seamons 2020, p. 2.
  20. ↑ Liu et al. 2015, p. 183.
  21. ↑ 1634–1699: McCusker, J. J. (1997). How Much Is That in Real Money? A Historical Price Index for Use as a Deflator of Money Values in the Economy of the United States: Addenda et Corrigenda (PDF). American Antiquarian Society. 1700–1799: McCusker, J. J. (1992). How Much Is That in Real Money? A Historical Price Index for Use as a Deflator of Money Values in the Economy of the United States (PDF). American Antiquarian Society. 1800–present: Federal Reserve Bank of Minneapolis. "Consumer Price Index (estimate) 1800–" . Retrieved 28 May 2023.
  22. ↑ Prince 2014.
  23. 1 2 3 4 5 6 Smith, Dickinson & Seamons 2020, p. 10.
  24. ↑ Chuat et al. 2020, p. 11.
  25. ↑ Larisch et al. 2017, p. 540.
  26. ↑ Chuat et al. 2020, p. 11-12.
  27. ↑ Smith, Dickinson & Seamons 2020, p. 2-3.
  28. 1 2 3 Smith, Dickinson & Seamons 2020, p. 3.
  29. 1 2 Larisch et al. 2017, p. 541.
  30. 1 2 3 Liu et al. 2015, p. 185.
  31. ↑ Liu et al. 2015, p. 189.
  32. ↑ Chung et al. 2018, p. 6-7.
  33. ↑ Chung et al. 2018, p. 4.
  34. ↑ Hallam-Baker 2015, p. 1.
  35. ↑ Hallam-Baker 2015, p. 7.
  36. ↑ Chung et al. 2018, p. 2.
  37. 1 2 Larisch et al. 2017, p. 543.
  38. ↑ Smith, Dickinson & Seamons 2020, p. 8-10.
  39. ↑ Larisch et al. 2017, p. 548-9.
  40. ↑ Larisch et al. 2017, p. 548.
  41. ↑ Smith, Dickinson & Seamons 2020, p. 4-5.
  42. ↑ Smith, Dickinson & Seamons 2020, p. 6.
  43. ↑ Smith, Dickinson & Seamons 2020, p. 7-8.
  44. ↑ Smith, Dickinson & Seamons 2020, p. 8-9.
  45. 1 2 Smith, Dickinson & Seamons 2020, p. 10-11.
  46. ↑ Smith, Dickinson & Seamons 2020, p. 8.
  47. ↑ Kogan & Corrigan-Gibbs 2021, p. 875-876.
  48. ↑ Szalachowski et al. 2016.

Works cited

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.