Mozilla about the beginning of testing in nightly builds of Firefox for a new mechanism to determine revoked certificates — . CRLite enables efficient verification of certificate revocation through a database hosted on the user's system. The implementation of CRLite being developed by Mozilla is under the MPL 2.0 open source license. The code for generating the database and server components is written in and Go. The client portions added to Firefox for reading data from the database are written in Rust.
The certificate verification still in use relying on external services based on the (Online Certificate Status Protocol) requires guaranteed network access, leads to noticeable latency in processing requests (averaging 350ms), and has privacy concerns (the OCSP servers responding to requests obtain information about specific certificates, which can indicate which sites the user visits). There is also the possibility of local verification using lists of (Certificate Revocation List), but the downside of this method is the very large size of the data being downloaded — currently, the database of revoked certificates occupies about 300 MB and continues to grow.
To block compromised and revoked certificates from certificate authorities, Firefox has been using a centralized blacklist since 2015 in conjunction with querying the service to identify potential malicious activity. OneCRL, like in Chrome, serves as an intermediary that aggregates CRL lists from certificate authorities and provides a unified centralized OCSP service for checking revoked certificates, allowing requests not to be sent directly to the certificate authorities. Despite significant efforts to improve the reliability of the online certificate verification service, telemetry data shows that over 7% of OCSP requests time out (a few years ago, this figure was at 15%).
By default, if the check via OCSP cannot be performed, the browser considers the certificate valid. The service may be unavailable due to network issues and internal restrictions, or it could be blocked by attackers—blocking access to the OCSP verification service is often enough to circumvent the check during a MITM attack. To partially prevent such attacks, a technique is implemented. , allowing an OCSP access error or unavailability to be interpreted as a problem with the certificate, but this feature is optional and requires special certificate configuration.
CRLite enables consolidating full information about all revoked certificates into an easily updatable structure, only 1 MB in size, which allows for maintaining a complete CRL database on the client side.
The browser will be able to synchronize its copy of the revoked certificates data daily, and this database will be accessible under any conditions.
CRLite combines information from , a public log of all issued and revoked certificates, and the results of scanning certificates on the internet (various CRL lists from certificate authorities are collected and information about all known certificates is aggregated). The data is packaged using cascading , a probabilistic structure that allows for false positives of absent elements but ensures that existing elements are not missed (i.e., with a certain probability, a valid certificate may trigger a false positive, but revoked certificates will be reliably identified).
To eliminate false positives in CRLite, additional corrective filtering levels have been introduced. After generating the structure, all original records are iterated through to identify any false positives. Based on the results of this check, an additional structure is created that cascades over the first one to correct the identified false positives. This operation is repeated until false positives are completely eliminated during control checks. Usually, creating 7-10 layers is sufficient to cover all data. Because the database state lags slightly behind the current state of the CRL due to periodic synchronization, checking new certificates issued after the last CRLite database update is carried out using the OCSP protocol, including the use of technique (a validated response from the certificate authority is passed by the server hosting the site during the TLS connection negotiation).
Using Bloom filters, the December snapshot of data from WebPKI, which covers 100 million active certificates and 750 thousand revoked certificates, has been packed into a structure sized at 1.3 MB. The structure generation process is quite resource-intensive, but it is performed on Mozilla's server, and users receive a ready update. For example, the raw data used in generation requires about 16 GB of memory when stored in the Redis DB, while the hexadecimal form of the dump of all certificate serial numbers occupies about 6.7 GB. The process of aggregating all revoked and active certificates takes about 40 minutes, and the process of generating the packed structure based on the Bloom filter takes an additional 20 minutes.
Currently, Mozilla updates the CRLite database four times a day (not all updates are delivered to clients). Delta updates have not yet been implemented — the use of bsdiff4, which is employed for creating delta updates of releases, does not provide the necessary efficiency for CRLite, resulting in unjustifiably large updates. To address this issue, a redesign of the storage structure format is planned to avoid unnecessary rebuilding and layer removal.
CRLite currently operates in passive mode in Firefox and is used concurrently with OCSP to accumulate statistics on operational correctness. CRLite can be switched to the primary checking mode; for this, you need to set the parameter security.pki.crlite_mode = 2 in about:config.
Source: opennet.ru
