Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are the de-facto standards for securing Internet transactions such as banking, e-mail and e-commerce. Along with a public key infrastructure (PKI), SSL provides trusted identities via certificate chains and private communication via encryption. Central to these guarantees is that private keys used in SSL are not compromised by third parties; if so, certificates based on those private keys must be reissued and revoked to ensure that malicious third parties cannot masquerade as a trusted entity.
Importantly, the PKI uses a default-valid model where potentially compromised certificates remain valid until their expiration date or until they are revoked. Revocation, how- ever, is a process that requires manual intervention from certificate owners and cooperation from clients that use these certificates. As a result, the practical security of the PKI is dependent on the speed with which certificate owners and SSL clients update their revocation lists, operations that occur at human timescales (hours or days) instead of computer ones (seconds or minutes). An important open question is: when private keys are compromised, how long are SSL clients exposed to potential attacks?
Summary of results (IMC'14)
In April, 2014, we conducted a study to tell how SSL certificates are reissued and revoked in response to a widespread vulnerability, Heartbleed, that enabled undetectable key compromise. We conducted large-scale measurements and developed new methodologies and heuristics to determine how the most popular 1 million web sites reacted to this vulnerability in terms of certificate management, and how this impacts security for clients that use them.
We found that the vast majority of vulnerable certificates have not been reissued; further, of those domains that reissued certificates in response to Heartbleed, 60% do not revoke their vulnerable certificates. If they do not eventually become revoked, 20% of those certificates will remain valid (not expire) for two or more years. The ramifications of this findings are alarming: modern Web browsers will remain potentially vulnerable to malicious third parties using stolen keys to masquerade as a compromised site for a long time to come. We analyzed these trends with vulnerable Extended Validation (EV) certificates, as well, and have found that, while they exhibit better security practices, they still remain largely not reissued (67%) and not revoked (88%) even weeks after the vulnerability was made public.
Summary of results (IMC'15)
While the overall SSL ecosystem is well-studied, the frequency with which certificates are revoked and the circumstances under which clients (e.g., browsers) check whether certificates are revoked are still not well-understood.
In our IMC'15 paper, we took a close look at certificate revocations in the Web's PKI. Using 74 full IPv4 HTTPS scans, we found that a surprisingly large fraction (8%) of the certificates served have been revoked, and that obtaining certificate revocation information can often be expensive in terms of latency and bandwidth for clients. We then studied the revocation checking behavior of 30 different combinations of web browsers and operating systems; we found that browsers often do not bother to check whether certificates are revoked (including mobile browsers, which uniformly never check). We also examined the CRLSet infrastructure built into Google Chrome for disseminating revocations; we found that CRLSet only covers 0.35% of all revocations. Overall, our results paint a bleak picture of the ability to effectively revoke certificates today.