The Web PKI In Theory and Malpractice TLS Certificate Revocation is a problem. There have been many solutions proposed over the years. I’m here to present one more. But I promise this time it’s different. First, a quick TLS history lesson. Bruce Maggs Joint work with Frank Cangialosi, David Choffnes, Taejoong Chung, James Larisch, Dave Levin, Yabing Liu, Alan Mislove, Aaron Schulman, Will Tome, Christo Wilson, and Liang Zhang.

Authentication Vetting How can users truly know with whom they are communicating? Browser Browser Website public private Vetting Certificate Authority Certificate is indeed BoA The owner of Certificate

Authentication How can users truly know with whom they are communicating? Browser Website public Certificate private Certificate Authority

Authentication How can users truly know with whom they are communicating? ✓ Browser Website Certificate public Certificate private Certificate Authority

Verifying certificates ✓ “I’m because I say so!” Certificate Root key store Every device has one Must not contain malicious certificates ✓ Certificate “I’m because says so” Browser ✓ Certificate “I’m because says so”

Certificate Revocation What happens when a certificate must be declared invalid? ✓ Website Certificate ✗ Browser ✗ Certificate Certificate Periodically pull / query (CRL) (OCSP) Attacker Certificate Certificate Authority Please revoke Certificate ✗ Certificate ✗ Certificate Revocation

Certificate Revocation If private keys are compromised, administrators must revoke and reissue as quickly as possible 2014 Heartbleed bug in OpenSSL potentially compromised many private keys. 107,712 certificates for Alex top 1M web sites were hosted on vulnerable servers* *Zhang et al., IMC ‘14 Browsers/OSes should obtain revocations as quickly as possible

Revocation in the Wild Analyzed 74 full IPv4 scans of port 443 (October 2013 to March 2015) 5,067,476 distinct valid certificates discovered (90% of certificates discovered were invalid!) 8% of valid certificates were revoked at some point 1% of those still served in March 2015 had been revoked

But Checking Comes at a Cost Browser Website Certificate Certificate Revoked? Certificate Authority Browsers want pages to load quickly CAs and mobile devices want to reduce bandwidth costs

Certificate Authority OCSP Stapling Browser Website Certificate Certificate Certificate ✔ Certificate Authority Certificate ✗ But OCSP Stapling rarely activated by admins: Our scan: 3% of normal certs; 2% of EV certs

Testing Browser Behavior Revocation protocols Browsers should support all major protocols CRLs, OCSP, OCSP stapling Availability of revocation info Browsers should reject certs they cannot check E.g., because the OCSP server is down Chain lengths Browsers should reject a cert if any on the chain fail Leaf, intermediate(s), root Leaf Root Intermediate … signs

More thorough vetting process of CAs and clients EV Certificates More thorough vetting process of CAs and clients Normal Extended Validation

Test Harness Implemented 192 tests using fake root certificate + Javascript Unique DNS name, cert chain, CRL/OCSP responder, …

Results Across all Browsers Safari Checks CRLs and OCSP Allows if revocation info unavailable Except for first intermediate, for CRLs Does not support OCSP stapling Firefox Never checks CRLs Only checks intermediates for EV certs Allows if revocation info unavailable Supports OCSP stapling Internet Explorer Checks CRLs and OCSP Often rejects if revocation info unavailable Pops up alert for leaf in IE 10+ Supports OCSP stapling Chrome Generally, only checks for EV certs ~3% of all certs Allows if revocation info unavailable Supports OCSP stapling Mobile Browsers Uniformly never check Android browsers request Staple …and promptly ignore it ✔ Passes test ✗ Fails test EV Passes for EV certs I Ignores OCSP Staple A Pops up alert to user L/W Passes on Linux/Win.

Results Across all Browsers Browser developers are not doing what the PKI needs them to do ✔ Passes test ✗ Fails test EV Passes for EV certs I Ignores OCSP Staple A Pops up alert to user L/W Passes on Linux/Win.

Revocation System Goals Complete Fail-reject Efficient So what do we want out of a revocation system?We’d like to give clients access to the revocation status of all certificates without intensive CA participation. Currently, if an attacker blocks a CRL or OCSP response, browsers assume the best and permit access - the ideal solution would adopt a fail-closed posture, rather than fail-open. The solution shouldn’t force clients to incur unreasonable bandwidth or latency costs. Clients shouldn’t sacrifice their privacy for security. The solution should be auditable: independent third parties should have the ability to verify the revocation information being disseminated. Finally, the solution should be incrementally deployable - it shouldn’t require the simultaneous cooperation of all certificate authorities, for example. status of all certificates can be determined low latency low bandwidth don’t accept a certificate if checking isn’t possible Easily Deployable Private Auditable don’t expose browsing history to certificate authorities anyone can verify that the right certificates are marked as revoked shouldn’t require actions on the parts of millions

15K 400 CRL OCSP OCSP Stapling One CRL CRLSet Complete Fail-reject Transparency Complete Fail-reject Efficient Private Auditable Deployable 15K 400 In response, browsers have cooked up their own solutions to the revocation problem. Chrome maintains CRLSet, a collection of about 15k high priority revocations. Firefox maintains OneCRL, which contains around 400 revocations. These sets of certificate identifiers are shipped via browser updates. Unfortunately these solutions have small revocation coverage and they are not auditable.

15K 400 CRL OCSP OCSP Stapling One CRL CRLSet Complete Fail-reject Transparency Complete Fail-reject Efficient Private Auditable Deployable 15K 400 In response, browsers have cooked up their own solutions to the revocation problem. Chrome maintains CRLSet, a collection of about 15k high priority revocations. Firefox maintains OneCRL, which contains around 400 revocations. These sets of certificate identifiers are shipped via browser updates. Unfortunately these solutions have small revocation coverage and they are not auditable.

15K 400 CRL OCSP OCSP Stapling One CRL CRLSet Complete Fail-reject Transparency Complete Fail-reject Efficient Private Auditable Deployable 15K 400 In response, browsers have cooked up their own solutions to the revocation problem. Chrome maintains CRLSet, a collection of about 15k high priority revocations. Firefox maintains OneCRL, which contains around 400 revocations. These sets of certificate identifiers are shipped via browser updates. Unfortunately these solutions have small revocation coverage and they are not auditable.

CRLite Filter Cascade: 1.3MB initially 40KB per day local lookup Complete Fail-reject Efficient Private Auditable Deployable ALL REVOCATIONS CRLite Filter Cascade: 1.3MB initially 40KB per day We introduce CRLite, which ships all certificate revocations to all web browsers. Browsers store and perform revocation checks locally. As a result, as long as users have access to our updates, they can * fail closed. The checks are local, * so we get privacy for free. How about the hard stuff? * We ship all revocations using only 10MB initially and average updates of 580KB. Considering Apple needs 76MB for their certificates alone, how could we possibly ship 13 million revocations using only 10MB? * * I’ll also show that CRLite is auditable and deployable. local lookup

Bloom Filters insert(“hello”) check(“hello”) Back to efficiency. Bloom filters are a fantastic choice when space-efficiency is required. Perhaps if we inserted all revoked certificates into a bloom filter, clients could use this filter to check certificates in the wild. Set membership data structure Space efficient False Positives n

Bloom Filters Check: Check: Inserting: Insert: hash() hash() So, we tried constructing a bloom filter of revoked certificates. For example, let’s imagine DuckDuckGo’s certificate was revoked, and let’s say k, the number of hash functions, is 2. Inserting DuckDuckGo’s certificate means flipping 2 bits in the bit array to 1. hash() hash() Revoked Filter

Bloom Filters Check: Check: Inserted: Inserting: hash() hash() ProtonMail’s certificate was also revoked, so after insertion, 2 more bits have been flipped to 1. hash() hash() Revoked Filter

Bloom Filters Inserted: Inserted: Checking: Check: hash() hash() We ship this filter to the client, who encounters DuckDuckGo’s certificate. So the browser checks the bloom filter: is DDG’s certificate revoked? Since the certificate hashes to the same indices, which are set to one, our bloom filter correctly reports DDG’s certificate as revoked. hash() hash() Revoked Filter

Bloom Filters FALSE POSITIVE! Inserted: Inserted: Checked: Checking: Now the browser checks Yahoo’s certificate. Unfortunately, the bit array indices that result from hashing yahoo’s certificate collide with DuckDuckGo and ProtonMail’s indices. Since checking for an item’s existence means checking if the indices are set to 1, our bloom filter will report that Yahoo’s certificate is a member, and is thus revoked. So our browser will erroneously block access to Yahoo! * So bloom filters have false positives: this means our system will block some valid, non-revoked certificates. This is incredibly dangerous - our system might block vital websites, like your bank, whose certificate has not been revoked! So bloom filters are absolutely unacceptable. This is where those who’ve tried bloom filters before get stuck. hash() hash() Revoked Filter

Opportunity: new databases now include all valid certificates! Until recently, we would have been forced to give up. But thanks to the momentous efforts of Google’s certificate transparency, which currently has 90% of all certificates and is expected to have 100% by the end of the year, and with scans from Rapid7 and the University of Michigan, we access all TLS certificates. It’s been shown that with these 3 sources, we achieve complete coverage. Towards a complete view of the certificate ecosystem - Vandersloot et al. 2016

Filter Cascade All revocations Insert We now have access to every single revoked certificate a user could encounter, and we can insert them into our bloom filter.

Filter Cascade All revocations All non-revoked Insert Lookup 30 Here’s where we got stuck. Some non-revoked certificates come back as false positives. But with our full certificate coverage, we know every single non-revoked certificate a user can encounter: 30

Filter Cascade All revocations All non-revoked All false positives we can use this set to derive the complete list of false positives a user will encounter! This way we’ve eliminated the risk of bloom filters! Now we can ship this bloom filter, and this whitelist, to clients. But what’s a great data structure for sending compressed sets of data… All false positives

Filter Cascade All revocations All non-revoked Lookup How about a bloom filter? We insert the false positives into a new one. We run into the same problem, but we can apply the same solution. Derive the 2nd filter’s false positives, which again are all the false positives a user could encounter. Lookup

Filter Cascade All revocations All non-revoked Generate a list, and construct another bloom filter.

Filter Cascade All revocations All non-revoked Lookup Since size of a given level’s filter is always a fraction (the false positive rate) of the size of the previous level’s filter, eventually we will construct a filter with no false positives. Lookup

Filter Cascade: Checking NOT REVOKED Once a client obtains a CRLite filter cascade and they encounter a wild certificate, how do they check for revocation? First, is it in the first filter?If not, since bloom filters do not have false negatives, the cert is not revoked. If so, we check the second filter.If the cert does not appear, we know the cert appeared in the revoked filter and was not a false positive, so it is revoked. If it does appear in the second filter , we must continue to the third filter. This process continues until the last level. REVOKED NOT REVOKED REVOKED

Analysis of Filter Cascade Size (bits) for , where is number of certificates, and is number of revoked certificates     Lower Bound:     Hash to unique string:     CRLite: Transmission size may be reduced using compressed Bloom filter at first level.

CRLite Pipeline 200M 60M 850K VALIDATE CRAWL CRL & OCSPs ALL RAW CERTIFICATES 200M VALIDATE As of January 2017, we have 200 million raw certificates which encompasses the entire TLS certificate space. After validating these certificates, we're left with 30M certificates. The CRL & OCSP endpoints from these certificates yield 13M revoked certificates. 60M CRAWL CRL & OCSPs 850K

CRLite Pipeline 200M 60M 850K Day 1 Cascade VALIDATE CRAWL CRL & OCSPs ALL RAW CERTIFICATES 200M VALIDATE We use the 30 million unrevoked and 13 million revoked certificates to construct the 10MB filter cascade. This bloom filter cascade contains the revocation status of 43M certificates. Day 1 Cascade 60M CRAWL CRL & OCSPs 850K

7 hashes at first level, 1 per level thereafter Our Filter Cascade In practice, the January 2017 cascade has 10 levels, and looking up a certificate requires no more than 20 hash functions. Using the current cardinalities of the sets of revoked and non-revoked certificates, we can modulate the false positive rate of each bloom filter in the cascade to produce different size cascades overall. We have some interesting results in the paper about producing a filter cascade with a size competitive with the lower bound of total size. Again, the January 2017 cascade is 10MB in total. 43 levels 7 hashes at first level, 1 per level thereafter 10 hashes expected 1.3 MB size

Still Not Small Enough CRLite CRLSet OneCRL 1.3 MB / day 250KB 34KB 40 Downloading 10MB a day would be just as untenable as CRL downloads. CRLSet, in comparison, is 250KB. Fortunately, once a client has a CRLite filter cascade we can ship them smaller filter updates. 1.3 MB / day 250KB 34KB 40

CRLite Pipeline Day 0 Cascade Day 1 Day 1 Cascade Update VALIDATE ALL RAW CERTIFICATES VALIDATE Since new certificates can be revoked and revoked certificates can expire, from day to day the filter may need to flip bits from 0 to 1 or 1 to 0. There’s no way to delete items from a bloom filter, but we can construct a diff using yesterday’s filter cascade. We XOR each level of yesterday and today’s cascades. This diff is XORd with the client’s outdated cascade to produce today’s cascade. Day 0 Cascade Day 1 Update CRAWL CRL & OCSPs Day 1 Cascade

Bloom Filter XOR Yesterday’s Level 1 XOR Today’s Level 1 Using the filter cascade from yesterday, we can XOR each level of the filter cascade with the corresponding level in today’s cascade. This update, once XORd with yesterday’s filter that clients possess, produces today’s filter. After compression, the diffs are around 580KB, which we believe is a reasonable quantity to download each day. XOR Today’s Level 1 Today’s Level 1 Update

Small Enough CRLite w/ Updates CRLSet OneCRL 40 KB / day 250KB 34KB we believe 580kb is a reasonable quantity to download each day, especially since as of 2016 the average web page is around 2 MB. Considering CRLite provides complete revocation status, we are happy with the size comparisons to CRLSet and OneCRL. 40 KB / day 250KB 34KB 14K REVOCATIONS (1.6%) 400 REVOCATIONS (0.047%) 850K REVOCATIONS (100%)

Deployment Plans We implemented CRLite as a Firefox extension Initial discussion with Chrome developers was disappointing: they’ll wait for OCSP stapling Mozilla (Firefox) was much more enthusiastic, and after discussions requested a design document But let’s say you aren’t convinced - perhaps size is still an issue. Let’s compare the bandwidth costs of a browser which uses CRLite and one which performs perfect CRL & OCSP checking. X axis, Y axis. Using client browsing simulator, how much browsing activity does it take for the cost of one CRLite daily update to be less than the amortized cost of CRL & OCSP downloads? As we can see, CRLite is worth it after less than 20 unique website visits using CRLs only. The bandwidth cost of CRLite becomes competitive with OCSP after around 600 unique visits. This tradeoff isn’t great. However, OCSP introduces a constant latency penalty and makes privacy sacrifices. We think despite the slight bandwidth disadvantage over an ideal OCSP-first browser, CRLite’s properties are more compelling.