Mozilla Company about the start of testing in Firefox nightly builds of a new mechanism for determining revoked certificates - . CRLite allows you to organize an effective certificate revocation check against a database hosted on the user's system. Mozilla's implementation of CRLite under the free license MPL 2.0. The code for generating the database and server components are written in and go. Added to Firefox client parts for reading data from the database in Rust.
The verification of certificates used so far with the involvement of external services based on the protocol (Online Certificate Status Protocol) requires guaranteed network access, causes a noticeable delay in processing the request (average 350ms), and has privacy problems (responding OCSP servers receive information about specific certificates, which can be used to judge whether what sites the user opens). There is also the possibility of local check against lists (Certificate Revocation List), but the disadvantage of this method is the very large size of the downloaded data - currently the database of revoked certificates takes about 300 MB and its growth continues.
Since 2015, Firefox has been using a centralized blacklist to block compromised and revoked certificates by CAs. combined with a call to service to identify possible malicious activity. OneCRL, like in Chrome, acts as an intermediate link that aggregates CRLs from CAs and provides a single centralized OCSP service for checking revoked certificates, which makes it possible not to send requests directly to CAs. Despite a lot of work to improve the reliability of the online certificate verification service, telemetry data shows that more than 7% of OCSP requests end in a timeout (a few years ago this figure was 15%).
By default, if it is not possible to check through OCSP, the browser considers the certificate to be correct. The service may be unavailable either due to network problems and restrictions on internal networks, or blocked by attackers - to bypass OCSP verification during a MITM attack, it is enough to simply block access to the verification service. Partially to prevent such attacks, a technique has been implemented , which allows to interpret an OCSP access error or OCSP unavailability as a problem with the certificate, but this feature is optional and requires a special design of the certificate.
CRLite allows you to consolidate complete information about all revoked certificates into an easily updated structure, only 1 MB in size, which makes it possible to store a complete CRL database on the client side.
The browser will be able to synchronize its copy of the revoked certificate data daily, and this database will be available 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 of certification authorities are collected and information about all known certificates is aggregated). The data is packed using cascading , a probabilistic structure that allows a false detection of a missing element, but excludes the omission of an existing element (i.e., with a certain probability, a false positive for a correct certificate is possible, but revoked certificates are guaranteed to be detected).
To eliminate false positives, CRLite introduced additional corrective filter levels. After the structure is generated, all source records are enumerated and false positives are identified. Based on the results of this check, an additional structure is created, which is cascaded onto the first one and corrects the resulting false positives. The operation is repeated until false positives during the control check are completely eliminated. Usually, it is enough to create 7-10 layers to completely cover all the data. Since the state of the database is slightly behind the current state of the CRL due to periodic synchronization, verification of new certificates issued after the last update of the CRLite database is carried out using the OCSP protocol, including using the technique (an OCSP response certified by a certification authority is transmitted by the server serving the site when negotiating a TLS connection).
With the help of Bloom filters, the December slice of information from WebPKI, covering 100 million active certificates and 750 thousand revoked certificates, was packed into a 1.3 MB structure. The process of generating the structure is quite resource-intensive, but it is performed on the Mozilla server and the user is given a ready-made update. For example, in binary form, the source data used during generation requires about 16 GB of memory when stored in the Redis DBMS, and in hexadecimal form, a dump of all certificate serial numbers takes about 6.7 GB. The process of aggregating all revoked and active certificates takes about 40 minutes, and the process of generating a packed structure based on the Bloom filter takes another 20 minutes.
Currently, Mozilla ensures that the CRLite database is updated four times a day (not all updates are delivered to customers). Generation of delta updates is not yet implemented - the use of bsdiff4, which is used to generate delta updates of releases, does not provide the proper efficiency for CRLite and the updates are unreasonably large. To eliminate this shortcoming, it is planned to rework the storage structure format to eliminate unnecessary rebuilding and deleting layers.
CRLite is still working in Firefox in passive mode and is used in parallel with OCSP to collect statistics on the correctness of the work. CRLite can be switched to the main check mode by setting the security.pki.crlite_mode = 2 parameter in about:config.
Source: opennet.ru