Mozilla implémente CRLite pour vérifier les certificats TLS problématiques

Société Mozilla annoncé le à propos du début des tests dans les versions nocturnes de Firefox d'un nouveau mécanisme de détection des certificats révoqués - CRLite. CRLite vous permet d'organiser une vérification efficace de la révocation des certificats par rapport à une base de données hébergée sur le système de l'utilisateur. Implémentation CRLite de Mozilla publié par sous licence gratuite MPL 2.0. Le code de génération de la base de données et des composants du serveur est écrit en Python et aller. Parties client ajoutées à Firefox pour lire les données de la base de données préparé en langage Rust.

Vérification du certificat à l'aide de services externes basés sur le protocole encore utilisé OCSP (Online Certificate Status Protocol) nécessite un accès réseau garanti, entraîne un retard important dans le traitement des requêtes (350 ms en moyenne) et a des problèmes pour assurer la confidentialité (les serveurs OCSP répondant aux requêtes reçoivent des informations sur des certificats spécifiques, qui peuvent être utilisées pour juger si ce sites ouverts par l’utilisateur). Il existe également la possibilité de vérifier localement par rapport aux listes CRL (Certificate Revocation List), mais l'inconvénient de cette méthode est la très grande taille des données téléchargées - actuellement la base de données des certificats révoqués occupe environ 300 Mo et sa croissance continue.

Pour bloquer les certificats compromis et révoqués par les autorités de certification, Firefox utilise depuis 2015 une liste noire centralisée. UneCRL en combinaison avec un appel au service Google Safe Browsing pour identifier une éventuelle activité malveillante. OneCRL, comme Ensembles CRL dans Chrome, fait office de lien intermédiaire qui regroupe les listes CRL des autorités de certification et fournit un service OCSP centralisé unique pour vérifier les certificats révoqués, permettant de ne pas envoyer de requêtes directement aux autorités de certification. Malgré de nombreux travaux visant à améliorer la fiabilité du service de vérification des certificats en ligne, les données de télémétrie montrent que plus de 7 % des requêtes OCSP expirent (il y a quelques années, ce chiffre était de 15 %).

Par défaut, s'il est impossible de vérifier via OCSP, le navigateur considère le certificat valide. Le service peut être indisponible en raison de problèmes de réseau et de restrictions sur les réseaux internes, ou bloqué par des attaquants - pour contourner le contrôle OCSP lors d'une attaque MITM, bloquez simplement l'accès au service de contrôle. En partie pour prévenir de telles attaques, une technique a été mise en œuvre Incontournable, qui permet de traiter une erreur d'accès OCSP ou une indisponibilité OCSP comme un problème avec le certificat, mais cette fonctionnalité est facultative et nécessite un enregistrement spécial du certificat.

CRLite vous permet de consolider les informations complètes sur tous les certificats révoqués dans une structure facilement mise à jour, d'une taille de seulement 1 Mo, ce qui permet de stocker une base de données CRL complète côté client.
Le navigateur pourra synchroniser quotidiennement sa copie des données sur les certificats révoqués, et cette base de données sera disponible dans toutes les conditions.

CRLite combine les informations de Transparence du certificat, un journal public de tous les certificats émis et révoqués et les résultats de l'analyse des certificats sur Internet (diverses listes CRL d'autorités de certification sont collectées et les informations sur tous les certificats connus sont regroupées). Les données sont regroupées en cascade Filtres de floraison, une structure probabiliste qui permet une fausse détection d'un élément manquant, mais exclut l'omission d'un élément existant (c'est-à-dire qu'avec une certaine probabilité, un faux positif pour un certificat correct est possible, mais les certificats révoqués sont garantis d'être identifiés).

Pour éliminer les faux positifs, CRLite a introduit des niveaux de filtre correctifs supplémentaires. Après avoir généré la structure, tous les enregistrements sources sont recherchés et tous les faux positifs sont identifiés. Sur la base des résultats de ce contrôle, une structure supplémentaire est créée, qui se répercute sur la première et corrige les faux positifs qui en résultent. L'opération est répétée jusqu'à ce que les faux positifs lors du contrôle soient complètement éliminés. En règle générale, la création de 7 à 10 couches suffit pour couvrir complètement toutes les données. L'état de la base de données, en raison de la synchronisation périodique, étant légèrement en retard par rapport à l'état actuel de la CRL, la vérification des nouveaux certificats émis après la dernière mise à jour de la base de données CRLite est effectuée à l'aide du protocole OCSP, notamment à l'aide du Agrafage OCSP (une réponse OCSP certifiée par une autorité de certification est transmise par le serveur desservant le site lors de la négociation d'une connexion TLS).

Mozilla implémente CRLite pour vérifier les certificats TLS problématiques

Grâce aux filtres Bloom, la tranche d'informations de décembre de WebPKI, couvrant 100 millions de certificats actifs et 750 1.3 certificats révoqués, a pu être regroupée dans une structure de 16 Mo. Le processus de génération de structure nécessite beaucoup de ressources, mais il est effectué sur le serveur Mozilla et l'utilisateur reçoit une mise à jour prête à l'emploi. Par exemple, sous forme binaire, les données source utilisées lors de la génération nécessitent environ 6.7 Go de mémoire lorsqu'elles sont stockées dans le SGBD Redis, et sous forme hexadécimale, un vidage de tous les numéros de série de certificat prend environ 40 Go. Le processus d'agrégation de tous les certificats révoqués et actifs prend environ 20 minutes, et le processus de génération d'une structure packagée basée sur le filtre Bloom prend encore XNUMX minutes.

Mozilla garantit actuellement que la base de données CRLite est mise à jour quatre fois par jour (toutes les mises à jour ne sont pas fournies aux clients). La génération de mises à jour delta n'a pas encore été implémentée - l'utilisation de bsdiff4, utilisé pour créer des mises à jour delta pour les versions, n'offre pas une efficacité adéquate pour CRLite et les mises à jour sont déraisonnablement volumineuses. Pour éliminer cet inconvénient, il est prévu de retravailler le format de la structure de stockage afin d'éliminer les reconstructions et suppressions inutiles de couches.

CRLite fonctionne actuellement dans Firefox en mode passif et est utilisé en parallèle avec OCSP pour accumuler des statistiques sur le bon fonctionnement. CRLite peut être basculé en mode d'analyse principale ; pour ce faire, vous devez définir le paramètre security.pki.crlite_mode = 2 dans about:config.

Mozilla implémente CRLite pour vérifier les certificats TLS problématiques

Source: opennet.ru

Ajouter un commentaire