Autrefois, les certificats expiraient souvent car ils devaient être mis à jour manuellement. Les gens oubliaient simplement de le faire. Avec l'apparition de Let’s Encrypt et de procédures de mise à jour automatiques, ce problème semblait résolu. Cependant, l'histoire récente avec Firefox montre qu'elle est en réalité toujours d'actualité. Malheureusement, les certificats continuent d'expirer.

Si quelqu'un a raté cette histoire, à minuit le 4 mai 2019, presque toutes les extensions Firefox ont soudainement cessé de fonctionner.

Il s'est avéré qu'une panne massive était due au fait que Mozilla avait laissé expirer le certificat, utilisé pour signer les extensions. Par conséquent, elles étaient marquées comme « non valides » et ne réussissaient pas la vérification (détails techniques). Sur les forums, comme solution de contournement, il a été recommandé de désactiver la vérification des signatures des extensions dans about:config ou de modifier l'heure système.

Mozilla a rapidement publié un patch pour Firefox 66.0.4, qui résout le problème avec le certificat non valide, et toutes les extensions sont revenues à la normale. Les développeurs recommandent de l'installer et de ne pas utiliser de solutions de contournement pour éviter la vérification des signatures, car elles pourraient entrer en conflit avec le patch.

Néanmoins, cette histoire montre encore une fois que l'expiration des certificats reste un problème d'actualité aujourd'hui.

Dans ce contexte, il est intéressant de regarder la manière assez originale dont les développeurs du protocole DNSCryptont abordé cette tâche. Leur solution peut être divisée en deux parties. Premièrement, il s'agit de certificats à court terme. Deuxièmement, d'avertir les utilisateurs de l'expiration imminente des certificats à long terme.

DNSCrypt

DNSCrypt est un protocole de cryptage du trafic DNS. Il protège les communications DNS contre les interceptions et les attaques de type MiTM, et permet également de contourner les blocages au niveau des requêtes DNS.

Le protocole encapsule le trafic DNS entre le client et le serveur dans une structure cryptographique, opérant sur les protocoles de transport UDP et TCP. Pour l'utiliser, le client et le résolveur DNS doivent prendre en charge DNSCrypt. Par exemple, depuis mars 2016, Yandex a intégré ce protocole à ses serveurs DNS et à son navigateur. Certains autres fournisseurs, y compris Google et Cloudflare, ont également annoncé leur prise en charge. Malheureusement, ils ne sont pas très nombreux (152 serveurs DNS publics sont listés sur le site officiel). Mais le programme dnscrypt-proxy peut être installé manuellement sur des clients sous Linux, Windows et MacOS. Il existe aussi des implémentations serveurs.

Comment fonctionne DNSCrypt ? En bref, le client prend la clé publique du fournisseur choisi et l'utilise pour vérifier ses certificats. À ce niveau, il y a des clés publiques à court terme pour la session et un identifiant de suite de chiffrement. Il est recommandé aux clients de générer une nouvelle clé pour chaque requête, et aux serveurs de changer leurs clés toutes les 24 heures. Lors des échanges de clés, l'algorithme X25519 est utilisé, pour la signature — EdDSA, pour le chiffrement par blocs — XSalsa20-Poly1305 ou XChaCha20-Poly1305.

L'un des développeurs du protocole, Frank Denis écrit, a indiqué que le changement automatique toutes les 24 heures résolvait le problème des certificats expirés. En principe, le client de référence dnscrypt-proxy accepte des certificats de n'importe quelle durée de validité, mais émet un avertissement « La période des clés dnscrypt-proxy pour ce serveur est trop longue » si elle est valide depuis plus de 24 heures. En même temps, une image Docker a été publiée, dans laquelle un changement rapide de clés (et de certificats) a été implémenté.

Tout d'abord, c'est extrêmement utile pour la sécurité : si le serveur est compromis ou si la clé est divulguée, le trafic d'hier ne peut pas être déchiffré. La clé a déjà changé. Cela posera probablement un problème pour l'application de la « loi Yarovaya », qui oblige les fournisseurs à stocker tout le trafic, y compris le trafic chiffré. On suppose qu'il sera possible de le déchiffrer par la suite en demandant la clé au site. Mais dans ce cas, le site ne pourra tout simplement pas la fournir, car il utilise des clés temporaires, supprimant les anciennes.

Mais surtout, écrit Denis, les clés à court terme obligent les serveurs à configurer l'automatisation dès le premier jour. Si le serveur se connecte au réseau et que les scripts de changement de clés ne sont pas configurés ou ne fonctionnent pas, cela sera immédiatement détecté.

Lorsque l'automatisation change les clés tous les quelques années, on ne peut pas compter dessus, et les gens peuvent oublier l'expiration du certificat. Avec un changement quotidien des clés, cela sera détecté instantanément.

En revanche, si l'automatisation est bien configurée, peu importe la fréquence de changement des clés : chaque année, chaque trimestre ou trois fois par jour. Si ça fonctionne plus de 24 heures, cela continuera à fonctionner indéfiniment, écrit Frank Denis. Selon lui, la recommandation de changer les clés quotidiennement dans la deuxième version du protocole, accompagnée d'une image Docker qui le met en œuvre, a efficacement réduit le nombre de serveurs avec des certificats expirés tout en améliorant la sécurité.

Toutefois, certains fournisseurs ont décidé pour des raisons techniques d'établir une durée de vie du certificat supérieure à 24 heures. Ce problème a été essentiellement résolu par quelques lignes de code dans dnscrypt-proxy : les utilisateurs reçoivent un avertissement d'information 30 jours avant l'expiration du certificat, un autre message plus sérieux 7 jours avant l'expiration et un message critique si le certificat expire dans moins de 24 heures. Cela ne concerne que les certificats ayant à l'origine une longue durée de vie.

De tels messages donnent aux utilisateurs l'opportunité d'informer les opérateurs DNS de l'imminente expiration du certificat avant qu'il ne soit trop tard.

Peut-être que si tous les utilisateurs de Firefox avaient reçu un tel message, quelqu'un aurait probablement informé les développeurs et ceux-ci auraient évité l'expiration du certificat. « Je ne me souviens d'aucun serveur DNSCrypt de la liste des serveurs DNS publics dont le certificat a expiré au cours des deux ou trois dernières années », écrit Frank Denis. Dans tous les cas, il vaut probablement mieux d'abord avertir les utilisateurs plutôt que de désactiver les extensions sans avertissement.

Source : habr.com