Visible to the public CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers

TitleCRLite: A Scalable System for Pushing All TLS Revocations to All Browsers
Publication TypeConference Paper
Year of Publication2017
AuthorsLarisch, J., Choffnes, D., Levin, D., Maggs, B. M., Mislove, A., Wilson, C.
Conference Name2017 IEEE Symposium on Security and Privacy (SP)
Date Publishedmay
KeywordsBloom filter, Browsers, certificate transparency, client-server systems, CRL, CRL checking, CRLite servers, CRLs, CRLSet, cryptography, data privacy, data structures, fail-closed security posture, Firefox, Google Certificate Transparency, Human Behavior, Internet, Metrics, OCSP, OCSP checking, OCSP Stapling, OneCRL, online front-ends, PKI, privacy, privacy concerns, Protocols, Prototypes, pubcrawl, Rapid7, resilience, Resiliency, revocation, Scalability, scalable system, security of data, Servers, space-efficient filter cascade data structure, SSL certificate revocations, SSL revocation checking, SSL Trust Models, TLS certificate revocations, TLS revocation checking, Transport Layer Security, University of Michigan
AbstractCurrently, no major browser fully checks for TLS/SSL certificate revocations. This is largely due to the fact that the deployed mechanisms for disseminating revocations (CRLs, OCSP, OCSP Stapling, CRLSet, and OneCRL) are each either incomplete, insecure, inefficient, slow to update, not private, or some combination thereof. In this paper, we present CRLite, an efficient and easily-deployable system for proactively pushing all TLS certificate revocations to browsers. CRLite servers aggregate revocation information for all known, valid TLS certificates on the web, and store them in a space-efficient filter cascade data structure. Browsers periodically download and use this data to check for revocations of observed certificates in real-time. CRLite does not require any additional trust beyond the existing PKI, and it allows clients to adopt a fail-closed security posture even in the face of network errors or attacks that make revocation information temporarily unavailable. We present a prototype of name that processes TLS certificates gathered by Rapid7, the University of Michigan, and Google's Certificate Transparency on the server-side, with a Firefox extension on the client-side. Comparing CRLite to an idealized browser that performs correct CRL/OCSP checking, we show that CRLite reduces latency and eliminates privacy concerns. Moreover, CRLite has low bandwidth costs: it can represent all certificates with an initial download of 10 MB (less than 1 byte per revocation) followed by daily updates of 580 KB on average. Taken together, our results demonstrate that complete TLS/SSL revocation checking is within reach for all clients.
DOI10.1109/SP.2017.17
Citation Keylarisch_crlite:_2017