Analysis of SSL certificate reissues and revocations in the wake of heartbleed

Abstract

Central to the secure operation of a public key infrastructure (PKI) is the ability to revoke certificates. While much of users' security rests on this process taking place quickly, in practice, revocation typically requires a human to decide to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems administrators reissue and revoke certificates is crucial to understanding the integrity of a PKI. Unfortunately, this is typically difficult to measure: while it is relatively easy to determine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked.In this paper, we use a recent widespread security vulnerability as a natural experiment. Publicly announced in April 2014, the Heartbleed OpenSSL bug, potentially (and undetectably) revealed servers' private keys. Administrators of servers that were susceptible to Heartbleed should have revoked their certificates and reissued new ones, ideally as soon as the vulnerability was publicly announced.Using a set of all certificates advertised by the Alexa Top 1 Million domains over a period of six months, we explore the patterns of reissuing and revoking certificates in the wake of Heartbleed. We find that over 73% of vulnerable certificates had yet to be reissued and over 87% had yet to be revoked three weeks after Heartbleed was disclosed. Moreover, our results show a drastic decline in revocations on the weekends, even immediately following the Heartbleed announcement. These results are an important step in understanding the manual processes on which users rely for secure, authenticated communication.

RevCast

“…Our results show that: (1) 96% of the time RevCast can transmit all revocations within 10 seconds, (2) the nothing-since attestations are remarkably effective at eliminating CRL checks, and (3) when there were extreme revocation rates as a result of the widespread Heartbleed vulnerability [30], 70% of the time RevCast could transmit all revocations within 10 seconds. Further, we reinforce the validity of the tracedriven simulation by studying the CA revocation behavior our dataset.…”

“…The dataset of certificate revocations that we analyze were collected by Zhang et al [30] from the CRLs for public-facing SSL servers on the Internet. Rapid7 2 collected SSL certificates from the entire IPv4 address space from October 2013 to April 2014.…”

“…The number of revocations in each hour also exhibits a diurnal pattern, confirming that many certificate revocations are issued during business hours. This could be explained by the fact that most revocations are likely benign (e.g., a CA issuing a certificate to supersede one that is nearing expiry), though Zhang et al also find that even compromised certificates are typically only revoked during traditional business hours [30].…”

RITM: Revocation in the Middle

“…Consequently, thousands of certificates were revoked over a few days. The detailed analysis of this event is presented by Durumeric et al [19] and Zhang et al [46]. Fig.…”

PKI Safety Net (PKISN): Addressing the Too-Big-to-Be-Revoked Problem of the TLS Ecosystem

“…As a consequence, in mid-April 2014 we observed the highest frequency of certificate re-issuance and revocation ever. This unique event and its impact on the TLS ecosystem has been thoroughly analyzed [16], [44]. We evaluated the bandwidth required by PKISN during normal operations (i.e., a few months before Heartbleed) and during what we will refer to as the peak time (i.e., right after Heartbleed was announced).…”