CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers By Kartik Patel

Motivation Browsers require certificate to be checked on each search. There are invalid certificates on the web which provide access to sites where they should not be granted Certificates need to be revoked if they are expired or private keys compromised Browsers are assuming certificate are valid There needs to be a system which will perform this efficiently without leaking or crashing user data, and will perform checks on all the certificates, not just a subset. And access is granted based on that But there are reasons why certificated need to be revoked,

Introduction TLS relies on certificates to be issued and cryptographically signed by Certificate Authorities (CAs) which provides: integrity, confidentiality, and authentication. When a client makes a search, the certificate needs to be validated each time through a TLS handshake. CA also erroneously issue certificates, and when a certificate’s private key is compromised, it needs to be revoked. Two common certificate revocation check methods: Certificate Revocation List (CRL): Contains all the certificates that have been revoked Open Certificate Status Protocol (OCSP): Query is sent and a response will be sent back describing whether the certificate is valid or not. What is a certificate (This is how a client determines the validity of the site and are valid for a certain time period which is determined by the start time and the expirable time) Once a certificate has reached its expiry date, it is to be revoked. The browser trusts the CA so it can trust the browser it is talking to The two common factors, is performed automatically by the web browsers Article showed many revocation methods, but the commonly discussed and also that are well known by people are CRL and OCSP

CRL Request CRL - certificates Signed Certificate TLS Handshake Once they have been revoked, how do browsers get access to this information. There are two common ways. Here the browser asks the certification authority for a list of all their revoked certificates, if this certificate is on the list, it blocks access. CRL is a list of serial numbers Downloads the list of certificates TLS Handshake

OCSP Is this cert. revoked Yes or No Signed Certificate TLS Handshake Here the website can ask whether a given certificate has been revoked rather than obtaining the entire list every time. The browser the responds and acts accordingly. TLS Handshake

Problem Chrome only make CRL or OCSP requests for extended validation certificates which is a very small subset of all the certificates. Firefox only supports revocation checks via OCSP Mobiles don’t perform browser checks for certificate revocations at all. Browsers that use a pull base method incur the following issues: Latency concerns (contacting third parties to perform revocation checks increases latency) Bandwidth considerations (Some CRLs over 70MB) Privacy risks (OCSP checks and leaks the users browser behavior) Ambiguity (Sometimes CRL and OCSP may not be available due to network errors or an active attack) Why browsers don’t perform checks due to the time it takes to pull the certificates, also this is the reason it is sceiptible to MITM attack and phishing attacks Firefox no longer supports CRL Mobile phones don’t perform due to the latency and the bandwidth performances

Aim Efficiency – Do not want browsers to sacrifice efficiency for security Timeliness – Ways to keep clients updated efficiently Fail-Closed – Way to stop non response certificates being treated as valid Privacy – Does not leak browser behavior Deployable – Goal is to release it today Auditability – Way to allow third parties to be able to audit it What we would like Didn’t want the browser to sacrifice Efficiency for security Wanted a fail closed system where if the certificate was unavailable it will treat it as revoked rather than valid Making personal data not being leaked Deployable today Making third parties to be able to audit it

Table compares CRLite to 6 other revocations and incorporates the best a parts of the existing systems like, user privacy, no centralizations of trust, a fail-closed security posture, instant deployability.

Solution CRLite CRLite is a proactive system which pushes all certificate revocations to browsers on a regular basis. Moving from pull method where browsers download certificates to a push method where CRLite pushes certificates to browsers. Personal web browser behavior is not leaked Server-side system aggregates revocation information for all known valid TLS certificates on the web and places them in a filter. Client-side component that downloads the filters and uses them to check for revocations of observed certificates. Uses a filter to provide browsers with a precise mapping of all certificates to their revocation status. solution presented in the article should be explained based on your understanding. The core idea should be clear, and you are expected to explain some details of the proposed technique in a way that can be easily followed by your classmates. Daily updates provide a fail-closed posture To make sure this is efficient, the first initial set of certificates that are sent are 10MB and the initial updates per day is 580KB This filter does not contain any false positives and false negatives

Server Side Obtain certificates - IPv4 search on port 443 and Google CT logs Validating Certificates – looking for non expired certificates, leaf and intermediate certificates (chain to trusted root). Revoked certificates – Extracts all CRL and OCSP certificates from the validating certificates. Filter Cascade – Compresses the certificates through bloom filter Delta Updates – Taking two sets of of bloom filters and XOR to get diff filter Audit log – Designed to address the issue of trust

Filter Cascading - Inserting All the revoked certificates are inserted into the bloom filter. Can contain false positives so you check with all the non-revoked certificates giving you a white list. Check revoked certificates with BF2 gives you another set of of false positives which is then checked with the non revoked certificates And the size of the bloom filter decreases each time, therefore eventually there will be no false positives left. Used to provide precise mapping of all certificates to their revocation status. All the revoked certificates are inserted into a bloom filter. Then you run into the false positive problem You then have access to all the non-revoked certificates that the user could encounter You then ship this bloom filter and false positives (white lists) When the client checks to see if a certificate is revoked, it checks in the bloom filter and if it is revoked, then it checks if it is in the whitelists and if it is in there then it is not revoked, if it is not in the white list it is revoked. You know all the revocations that a user can encounter, you then look this up in the white list

Filter Cascading – Inserting All the revoked certificates are put into a bloom filter which can contain false positives. This then checked with the non revoked certificates which can give you all the false positives. Therefore this is then checked in the revoked certificates again which will give us another bloom filter of all the false positives. This process is then repeated until there are no false positives.

Client Side Obtain the bloom filters Download regular delta updates Perform update – compare the difference between delta update and bloom filter Checking certificates on searches

Filter Cascading - Lookup Client checks to see if a certificate has been revoked by checking in the bloom filter and if it is not in there, then it has not been revoked. If it is in the first bloom filter, it then checks the false positives and if it is not in there, then it has been revoked. This process continues to the last bloom filter until there is no more… This bloom filter cascade is then shipped to clients where they will perform he search for the revoked certificates If an element is in BF1 and BF2 but not in BF3, then it is definitely not in R Odd levels showed white lists and even numbers showed black lists So if I is odd then u is definitely not in R If I is even then u is definitely in R

Delta Updates Provides up-to-date changes of certificates to the client of the new revoked certificates Delta updates are created on a daily basis Clients only need to download the complete bloom filter once The file is approximate ~580Kb

CRLite Address Six Challenges Efficiency: Compresses the revocation status of all certificates using a cascading filter. Timeliness: Uses delta-updates to keep clients up-to-date with recent revocations. Allows clients to download just the changes once, as they are created on a daily basis. Failure Model: Uses a fail-closed security posture. When revocation information about a certificate is unavailable, it assumes that the certificate is invalid. Privacy: Does not reveal their browsing history to third parties. Deployability: Deployable today and requires no support from CAs or changes to TLS, with easy integration into modern browsers. Auditability: Uses cryptographically-signed logs that allow any interested party to audit each filter to check for erroneous certificates Currently you have to pull the certificates on all browsers Current browsers user fail-open FireFox leaks information

Criticisms and Improvements There are changes made during the day, clients are not updated about the new revoked certificates as this is only conducted once per day and falls back on existing methods. Improvement: CRLite should push all new updates soon as a new change has been made to clients Users can opt in and use CRLite, not deployed automatically in browsers Has to go through browser extension. Solves man in the middle attack but attackers can replicate a fake extension which can track users information If the list of delta updates get compromised on the way (MITM), then the client will have an incorrect version Improvement: Implement a published copy online which performs an automatic check with the users copy. you should share your own comments on this article, such as what is the limitation of the proposed idea and how one can overcome it. Note that you should come up with your own limitations instead of explaining ones already listed in the article!

Summary CRLite solves the major issue of latency which is the deal breaker between downloading new certificates through previous certificate revocation methods. Mobile browsers are now non-constrained by latency and bandwidth of the file size of the revoked certificates. Personal information is no longer leaked as there is a cached set of certificates, rather than contacting the CA to obtain a certificate. Clients always have access to the revoked certificates even when there is a network error No more false positive responses or false negatives

Questions?