CRLite ships compressed revocation information for the public Web to
Firefox users, four times a day. We have a blogpost series on CRLite at the
Security Blog <https://blog.mozilla.org/security/tag/crlite/
> (with another
post coming later this month), there’s additional information at Github
>, and for the Gecko-side, a meta-bug
We’ve been collecting telemetry on how much CRLite can speed up first TLS
all year. Since August, we’ve been publishing the datasets consistently
four times per day, with “stashes” (delta updates) averaging about 66 kB. (
If you’d like to poke around inside the filter data, see
Nightly is now preferring CRLite <https://github.com/mozilla/crlite
revocation information, meaning fresh TLS connections will skip OCSP when
CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
“Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
telemetry: it’s mostly expected to speed up the outliers in the graph,
since revocation checks get cached, and it is likely to have the largest
effects for Firefox users with slower network connections.
We don’t expect breakage from this change, as we’ve grown fairly confident
in the dataset, but this is going to remain in Nightly for now.
After this speed-up testing, our likely next step is to add telemetry to
compare live OCSP results against CRLite’s results for outlier-accuracy
(encountering revocations is rare, so care is needed). We’ll ultimately run
both the accuracy and the speedup tests in early Beta as well.
We’ll develop Release-path plans based on early Beta testing and telemetry.
For more information, come see us in #crlite in Slack or #crlite:mozilla.org
- J.C. on behalf of Mozilla Crypto Engineering