Towards Short-Lived Certificates Emin Topalovic∗, Brennan Saeta∗, Lin-Shung Huangy, Collin Jacksony and Dan Boneh∗ ∗Stanford University, femint, saeta, [email protected] yCarnegie Mellon University, flinshung.huang, [email protected] Abstract—The Online Certificate Status Protocol (OCSP) is as on its clients. For space considerations, their global CRL is good as dead. It imposes a massive performance penalty on not exhaustive, and can exclude the revocations that happen web traffic and has failed to mitigate the recent high-profile for purely administrative reasons. Network filtering attacks certificate security breaches of certificate authorities. Citing these fundamental protocol flaws, Google Chrome, one of the world’s that block updates are still possible, but would require con- most popular browsers, is permanently disabling OCSP and stant blocking from the time of revocation. Google’s decision taking direct ownership over certificate revocation. We will soon is mainly due to the ineffectiveness of soft-fail revocation be living in a post-OCSP world where Google has become a checks, and also the obvious costs in performance and user single point of failure for certificate validation. We argue that privacy [6]. certificate authorities should reassert control over the certificate revocation process by issuing certificates with a very short While revocation by software updates may work well for lifetime. These certificates complement browser-based revocation Chrome, it can be quite difficult on a number of platforms by allowing certificate authorities to revoke certificates without the cooperation of browser vendors, and without imposing a such as smartphones, where issuing a software update in- performance penalty on web traffic. volves multiple entities and can take many months until wide deployment. Even now several smartphone vendors have not We have implemented a prototype certificate authority and certificate update plugin for Apache that demonstrates feasibility yet issued software updates to block DigiNotar certificates. of short-lived certificates. We have also implemented client-side Revocation by software update takes control of revocation out pinning to short-lived certificates in the Chromium browser. Fi- of the hands of the CAs where it naturally belongs and puts it nally, we show that short-lived certificates complement browser- in the hands of software and hardware vendors who may have based revocation and address its major limitations; the two less of an incentive to issue a software update every time a mechanisms can be combined to achieve secure, performant, and backwards-compatible browsing experience on the web. certificate is revoked. An Old Proposal Revisited I. INTRODUCTION In this paper we propose to abandon the existing revocation X.509 certificates are widely used by web browsers to authen- mechanisms in favor of an old idea [7], [8] — short-lived ticate destination servers [1]. It is current standard practice certificates — that puts revocation control back in the hands for certificate authorities (CAs) to issue certificates with a of the CAs. Short-lived certificates are far more efficient relatively long validity period such as a year or longer. Ideally, than CRLs and OCSP, and require no client-side changes, certificates are expected to be used for their entire validity although a minor client change can strengthen the proposal period, but unfortunately, a certificate can go bad prior to its significantly. expiration date for many reasons. Private keys corresponding to the certificate can be stolen, the certificate could have been A short-lived certificate is identical to a regular certificate, issued fraudulently, or the certificate could have simply been except that the validity period is a short span of time such reissued (e.g. due to a change of name or association). For as a few days. Such certificates expire shortly, and most these reasons, X.509 defines mechanisms, including certificate importantly, fail closed after expiration on clients without the revocation lists (CRLs) [1] and the Online Certificate Status need for a revocation mechanism. We suggest a certificate Protocol (OCSP) [2], for revoking a certificate prior to its lifetime as short as four days, matching the average length expiration date. of time that an OCSP response is cached [9]. Notably, recent security breaches of certificate authorities (i.e. In our proposal, when a web site purchases a year-long Comodo [3] and DigiNotar [4]) have resulted in fraudulently certificate, the CA’s response is a URL that can be used issued certificates exposed in the wild. However, current to download on-demand short-lived certs. The URL remains revocation mechanisms have been ineffective, as discussed in active for the year, but issues certs that are valid for only the next section, and browser vendors were forced to issue a few days. Every day a server-side element fetches a new software updates to block bad certificates instead of relying certificate that is active for the next few days. If this fetch on revocation checks. In fact, Google has announced plans to fails, the web site is not harmed since the certificate obtained disable altogether OCSP in Chrome — one of the world’s most the previous day is active for a few more days giving the popular browsers [5] — and instead reuse its existing software administrator and the CA ample time to fix the problem. In update mechanism to maintain a list of revoked certificates this way the burden of validating certificates is taken off the critical path of HTTPS connection establishment, and instead intervals, there is a risk of not blocking recently revoked is handled offline by the web site. We emphasize that short- certificates in time. lived certificates do not change the communication pattern • Since CRLs themselves can grow to be megabytes in between clients and web servers. Moreover, since clients size, clients often employ caching strategies, otherwise typically fail closed when faced with an expired certificate, large transfers will be incurred every time a CRL is this approach is far more robust that the existing OCSP and downloaded. This introduces cache consistency issues CRL based approaches. where a client uses an out-of-date CRL to determine revocation status. Although it is conceptually simple, many issues need to be • Browsers have historically been forgiving to revocation addressed for this approach to work. First, we hope to use failures (a.k.a “fail open”) so as not to prevent access to short-lived intermediate certificates, but this requires some popular web sites in case their CAs are unreachable [11]. additional steps at the CA. Second, we need to ensure that In practice, they either ignore CRL by default, or do not installing a new certificate on a web server does not force a show clear indications when revocation fails [12]. Unfor- web server restart. Third, for web sites with many servers, we tunately, this lets a network attacker defeat revocation by need an architecture to ensure that only one request from the simply corrupting revocation requests between the user site is issued to the CA per day (as opposed to one request and the CA. per server). Finally, a small optional change to the client can • It should also be noted that the location of the CRL (indi- provide additional defense-in-depth against attacks on the CA. cated by the CRL distribution point extension) is a non- We discuss these issues in the following sections. critical component of a certificate description, according We analyze the security of this proposal in Section V, but to RFC5280. This means that for certificates without this briefly mention here that when a web site key is compromised extension, it is up to to the verifier to determine the by a server-side breach, the certificate can be used for a few CRL distribution point itself. If it cannot CRLs may be days, but becomes worthless once it expires. In real-life this ignored [13]. is equivalent or better than the security guarantees offered by OCSP — OCSP responses are usually valid for a few days [9] B. Online Certificate Status Protocol and therefore revocation via OCSP also need a few days to take affect. The Online Certificate Status Protocol (OCSP), an alternative to CRLs proposed in RFC 2560 [2], allows client software to obtain current information about a certificate’s validity on a II. BACKGROUND certificate-by-certificate basis. When verifying a certificate, a client sends an OCSP request to an OCSP responder, which We begin by surveying the existing standards for removing responds whether the certificate is valid or not. Typically, trust from a valid certificate before its expiration date, and clients are instructed to cache the OCSP response for a few discuss the deficiencies that have caused Chrome to abandon days [9]. OCSP responders themselves are updated by CAs as them. to the status of certificates they handle. In theory, it is possible for CAs to issue OCSP responses with A. Certificate Revocation Lists short validity periods (since the response size is smaller than One solution to dealing with certificates that go bad is the a CRL), however there are many real-world constrains that certificate revocation list (CRL) [1]. When a certificate goes make this approach infeasible: bad, its identifying serial number is published to a list, signed • OCSP validation increases client side latency because and timestamped by a certificate authority (CA). In order to verifying a certificate is a blocking operation, requiring trust a certificate, a user must not only verify the signature a round trip to the OCSP responder to retrieve the and expiration date, but also ensure that the certificate is not revocation status (if no valid response found in cache). A listed in CRLs. previous study [9] indicates that 91.7% of OCSP lookups For CRLs to be effective, one assumes that (1) up-to-date are costly, taking more than 100ms to complete, thereby lists are published frequently by the CA, (2) the most recent delaying HTTPS session setup.