1. 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.

2. 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

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

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

5. 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”

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

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

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

14. 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.

15. 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.

16. 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

17. 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.

18. 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.

19. 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.

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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.

28. 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

29. 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

30. 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

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

32. 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

33. 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

34. 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.

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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%)

42. 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.