Mozilla déploie CRLite pour vérifier les certificats TLS problématiques

Entreprise Mozilla a annoncé sur le début des tests dans les versions nocturnes de Firefox du nouveau mécanisme de détermination des certificats révoqués — CRLite. CRLite permet d'organiser une vérification efficace des révocations de certificats à partir d'une base de données hébergée sur le système de l'utilisateur. La mise en œuvre de CRLite développée par Mozilla a été publiée est sous licence libre MPL 2.0. Le code pour générer la base de données et les composants serveurs sont écrits en Python et Go. Les parties client ajoutées à Firefox pour lire les données de la base de données préparés sont écrites en Rust.

La vérification de certificats encore utilisée, faisant appel à des services externes basés sur le protocole OCSP (Online Certificate Status Protocol) nécessite un accès réseau garanti, engendrant un délai notable dans le traitement de la demande (en moyenne 350 ms) et présente des problèmes de confidentialité (les serveurs OCSP qui répondent aux requêtes reçoivent des informations concernant des certificats spécifiques, permettant de déduire quels sites l'utilisateur visite). Il existe également la possibilité d'une vérification locale via des listes CRL (Certificate Revocation List), mais l'inconvénient de cette méthode est la taille énorme des données à télécharger — actuellement, la base de données des certificats révoqués occupe environ 300 Mo et continue de croître.

Pour bloquer les certificats compromis et révoqués par les autorités de certification, Firefox utilise depuis 2015 une liste noire centralisée OneCRL en combinaison avec un service Google Safe Browsing pour détecter une éventuelle activité malveillante. OneCRL, tout comme CRLSets dans Chrome, agit comme un lien intermédiaire qui agrège les listes CRL des autorités de certification et fournit un service OCSP centralisé pour vérifier les certificats révoqués, permettant de ne pas envoyer de requêtes directement aux autorités de certification. Malgré un important travail effectué pour améliorer la fiabilité du service de vérification en ligne des certificats, les données de télémétrie montrent que plus de 7 % des requêtes OCSP se terminent par un timeout (il y a quelques années, ce chiffre était de 15 %).

Par défaut, en cas d'impossibilité de vérifier via OCSP, le navigateur considère le certificat comme valide. Le service peut être inopérant en raison de problèmes réseau ou de restrictions sur les réseaux internes, ou être bloqué par des attaquants — pour contourner la vérification OCSP lors d'une attaque MITM, il suffit de bloquer l'accès au service de vérification. En partie pour éviter de telles attaques, une technique a été mise en œuvre Must-Staple, qui permet d'interpréter l'erreur de requête OCSP ou l'indisponibilité d'OCSP comme un problème lié au certificat, mais cette option est facultative et nécessite une configuration spéciale du certificat.

CRLite permet de compacter toutes les informations sur tous les certificats révoqués dans une structure facilement actualisable, de seulement 1 Mo, ce qui permet de conserver l'intégralité de la base CRL 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 regroupe les informations provenant de la Transparence des Certificats, un registre public de tous les certificats émis et révoqués, et des résultats d'analyse des certificats sur Internet (différents listes CRL sont collectées auprès des autorités de certification et les informations sur tous les certificats connus sont agrégées). Les données sont empaquetées à l'aide de filtres Bloom, une structure probabiliste qui permet une fausse identification d'un élément manquant, mais exclut le non-reconnaissance d'un élément existant (c'est-à-dire qu'avec une certaine probabilité, il peut y avoir un faux positif pour un certificat valide, mais les certificats révoqués seront assurément détectés).

Pour éviter les faux positifs dans CRLite, des niveaux de filtrage correctifs supplémentaires ont été introduits. Après la génération de la structure, toutes les entrées d'origine sont parcourues pour identifier les faux positifs survenus. À partir des résultats de cette vérification, une structure supplémentaire est créée, qui est appliquée en cascade sur la première et corrige les faux positifs détectés. L'opération est répétée jusqu'à ce que les faux positifs soient entièrement éliminés lors de la vérification de contrôle. En général, la création de 7 à 10 couches suffit pour couvrir toutes les données. Étant donné que l'état de la base de données, en raison de la synchronisation périodique, est 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 se fait à l'aide du protocole OCSP, y compris en utilisant la technique OCSP Stapling (la réponse OCSP certifiée par l'autorité de certification est transmise par le serveur qui gère le site lors de l'établissement de la connexion TLS).

À l'aide des filtres de Bloom, l'échantillon de décembre des données de WebPKI, couvrant 100 millions de certificats actifs et 750 000 certificats révoqués, a pu être empaqueté dans une structure de 1,3 Mo. Le processus de génération de la structure est assez gourmand en ressources, mais il est effectué sur le serveur de Mozilla, et l'utilisateur reçoit une mise à jour déjà prête. Par exemple, sous forme binaire, les données sources utilisées pour la génération nécessitent environ 16 Go de mémoire lorsqu'elles sont stockées dans une base de données Redis, et sous forme hexadécimale, le dump de tous les numéros de série des certificats occupe environ 6,7 Go. Le processus d'agrégation de tous les certificats révoqués et actifs prend environ 40 minutes, et le processus de génération de la structure empaquetée basée sur le filtre de Bloom nécessite encore 20 minutes.

Actuellement, Mozilla assure la mise à jour de la base de données CRLite quatre fois par jour (toutes les mises à jour ne sont pas fournies aux clients). La génération de mises à jour delta n'est pas encore mise en œuvre — l'utilisation de bsdiff4, qui est utilisé pour créer des mises à jour delta des versions, ne fournit pas l'efficacité requise pour CRLite et les mises à jour deviennent injustement volumineuses. Pour remédier à ce problème, il est prévu de retravailler le format de stockage de la structure afin d'éliminer les reconstructions inutiles et la suppression des couches.

CRLite fonctionne actuellement dans Firefox en mode passif et est utilisé en parallèle avec OCSP pour accumuler des statistiques sur la précision de son fonctionnement. CRLite peut être activé en mode de vérification principale, pour cela, il faut définir le paramètre security.pki.crlite_mode = 2 dans about:config.

Source : opennet.ru