The first three posts in this series are about the newly-added CRLite technology and provide background that will be useful for following along with this post:<\/p>\n
- \n
- Introducing CRLite: All of the Web PKI\u2019s revocations, compressed<\/a>,<\/li>\n
- CRLite: Speeding Up Secure Browsing<\/a>, and specifically useful is<\/li>\n
- The End-to-End Design of CRLite<\/a>.\u00a0<\/i><\/li>\n<\/ul>\n
This blog post discusses the back-end infrastructure that produces the data which Firefox uses for CRLite. To begin with, we\u2019ll trace that data in reverse, starting from what Firefox needs to use for CRLite\u2019s algorithms, back to the inputs derived from monitoring the whole Web PKI via Certificate Transparency.<\/p>\n
Tracing the Flow of Data<\/h2>\n
Individual copies of Firefox maintain in their profiles a CRLite database which is periodically updated via Firefox\u2019s Remote Settings<\/a>. Those updates come in the form of CRLite filters and \u201cstashes\u201d.<\/p>\n
Filters and Stashes<\/h3>\n
The general mechanism for how the filters work is explained in Figure 3 of The End-to-End Design of CRLite<\/a>.<\/i><\/p>\n
Introduced in this post is the concept of CRLite stashes<\/a>. These are lists of certificate issuers and the certificate serial numbers that those issuers revoked, which the CRLite infrastructure distributes to Firefox users in lieu of a whole new filter. If a certificate\u2019s identity is contained within any of the issued stashes, then that certificate is invalid.<\/p>\n
Combining stashes with the CRLite filters produces an algorithm which, in simplified terms, proceeds like this:<\/p>\n
![\"A](\"https:\/\/blog.mozilla.org\/security\/files\/2020\/12\/CRLite-Decision-Flow1-600x753.png\")
<\/a>Figure 1: Simplified CRLite Decision Tree<\/p><\/div>\n
Every time the CRLite infrastructure updates its dataset, it produces both a new filter and a stash containing all of the new revocations (compared with the previous run). Firefox\u2019s CRLite is up-to-date if it has a filter and all issued stashes for that filter<\/a>.<\/p>\n
Enrolled, Valid and Revoked<\/h3>\n
To produce the filters and stashes, CRLite needs as input:<\/p>\n
- \n
- The list of trusted certificate authority issuers which are enrolled in CRLite<\/a>,<\/li>\n
- The list of all currently-valid certificates issued by each of those enrolled certificate authorities, e.g. information from Certificate Transparency,<\/li>\n
- The list of all unexpired-but-revoked certificates issued by each of those enrolled certificate authorities, e.g. from Certificate Revocation Lists.<\/li>\n<\/ol>\n
These bits of data are the basis of the CRLite decision-making.<\/p>\n
The enrolled issuers are communicated to Firefox clients as updates within the existing Intermediate Preloading<\/a> feature, while the certificate sets are compressed into the CRLite filters and stashes. Whether a certificate issuer is enrolled or not is directly related to obtaining the list of their revoked certificates.<\/p>\n
Collecting Revocations<\/h3>\n
To obtain all the revoked certificates for a given issuer, the CRLite infrastructure reads the Certificate Revocation List (CRL) Distribution Point extension out of all that issuer\u2019s unexpired certificates and filters the list down to those CRLs which are available over HTTP\/HTTPS. Then, every URL in that list is downloaded and verified: Does it have a valid, trusted signature? Is it up-to-date? If any could not be downloaded, do we have a cached copy which is still both valid and up-to-date?<\/p>\n
For issuers which are considered enrolled, all of the entries in the CRLs are collected and saved as a complete list of all revoked certificates for that issuer.<\/p>\n
Lists of Unexpired Certificates<\/h3>\n
The lists of currently-valid certificates and unexpired-but-revoked certificates have to be calculated, as the data sources that CRLite uses consist of:<\/p>\n
- \n
- Certificate Transparency\u2019s list of all certificates in the WebPKI, and<\/li>\n
- All the published certificate revocations from the previous step.<\/li>\n<\/ol>\n
By policy now, Certificate Transparency (CT) Logs<\/a>, in aggregate, are assumed to provide a complete list of all certificates in the public Web PKI. CRLite then filters the complete CT dataset down to certificates which haven\u2019t yet reached their expiration date, but which have been issued by certificate authorities trusted by Firefox.<\/p>\n
Filtering CT data down to a list of unexpired certificates allows CRLite to derive the needed data sets using set math:<\/p>\n
- \n
- The currently-valid certificates are those which are unexpired and not included in any revocation list,<\/li>\n
- The unexpired-but-revoked certificates are those which are unexpired and are included in a revocation list.<\/li>\n<\/ul>\n
The CT data simply comes from a continual monitoring of the Certificate Transparency ecosystem. Every known CT log<\/a> is monitored by Mozilla\u2019s infrastructure, and every certificate added to the ecosystem is processed.<\/p>\n
The Kubernetes Pods<\/h2>\n
All these functions are orchestrated as four Kubernetes<\/a> pods with the descriptive names Fetch, Generate, Publish, and Sign-off.<\/p>\n
Fetch<\/h3>\n
Fetch is a Kubernetes deployment, or always-on task, which constantly monitors Certificate Transparency data from all Certificate Transparency logs. Certificates that aren\u2019t expired are inserted into a Redis database<\/a>, configured so that certificates are expunged automatically when they reach their expiration time. This way, whenever the CRLite infrastructure requires a list of all unexpired certificates known to Certificate Transparency, it can iterate through all of the certificates in the Redis database. The actual data stored in Redis is described in our FAQ<\/a>.<\/p>\n
![\"\"](\"https:\/\/blog.mozilla.org\/security\/files\/2020\/11\/Fetch-600x239.png\")
<\/a>Figure 2: The Fetch task reads from Certificate Transparency and stores data in a Redis database<\/p><\/div>\n
Generate<\/h3>\n
The Generate pod is a periodic task, which currently runs four times a day. This task reads all known unexpired certificates from the Redis database, downloads and validates all CRLs from the issuing certificate authorities, and synthesizes a filter and a stash from those data sources. The resulting filters and stashes are uploaded into a Google Cloud Storage bucket, along with all the source input data<\/a>, for both public audit and distribution.<\/p>\n
![\"\"](\"https:\/\/blog.mozilla.org\/security\/files\/2020\/11\/Generate-600x325.png\")
<\/a>Figure 3: The Generate task reads from a Redis database and the Internet, and writes its results to Google Cloud Storage<\/p><\/div>\n
Publish<\/h3>\n
The Publish task is also a periodic task, running often. It looks for new filters and stashes in the Google Cloud Storage bucket, and stages either a new filter or a stash<\/a> to Firefox\u2019s Remote Settings when the Generate task finishes producing one.<\/p>\n
![\"\"](\"https:\/\/blog.mozilla.org\/security\/files\/2020\/11\/Publish-600x175.png\")
<\/a>Figure 4: The Publish job reads from Google Cloud Storage and writes to Remote Settings<\/p><\/div>\n
Sign-Off<\/h3>\n
Finally, a separate Sign-Off task runs periodically, also often. When there is an updated filter or stash staged at Firefox\u2019s Remote Settings, the sign-off task downloads the staged data and tests it, looking for coherency and to make sure that CRLite does not accidentally include revocations that could break Firefox. If all the tests pass, the Sign-Off task approves the new CRLite data for distribution, which triggers Megaphone<\/a> to push the update to Firefox users that are online.<\/p>\n
![\"\"](\"https:\/\/blog.mozilla.org\/security\/files\/2020\/11\/Sign-Off-600x176.png\")
<\/a>Figure 5: The Sign-Off task interacts with both Remote Settings and the public Internet<\/p><\/div>\n
Using CRLite<\/h2>\n
We recently announced in the mozilla.dev.platform mailing list that Firefox Nightly users on Desktop are relying on CRLite<\/a>, after collecting encouraging performance measurements for most of 2020. We\u2019re working on plans to begin tests for Firefox Beta users soon. If you want to try using CRLite, you can use Firefox Nightly, or for the more adventurous reader, interact with the CRLite data directly<\/a>.<\/p>\n
Our final blog post in this series, Part 5, will reflect on the collaboration between Mozilla Security Engineering and the several research teams that designed and have analyzed CRLite to produce this impressive system.<\/p>\n","protected":false},"excerpt":{"rendered":"
- CRLite: Speeding Up Secure Browsing<\/a>, and specifically useful is<\/li>\n