Dans le passé, les certificats expiraient souvent car ils devaient être mis à jour manuellement. Les gens ont juste oublié de le faire. Avec l'avènement de Let's Encrypt et une procédure de mise à jour automatique, le problème semble être résolu. Mais une
histoire récente
avec Firefox montre qu'en fait c'est toujours d'actualité. Malheureusement, les certificats expirent toujours.
Si quelqu'un a raté cette histoire, presque toutes les extensions Firefox ont soudainement cessé de fonctionner à minuit le 4 mai 2019.
Il s'est avéré qu'un échec massif s'est produit car Mozilla avait
expiré le certificat utilisé pour signer les extensions. Par conséquent, ils ont été marqués comme "invalides" et n'ont pas réussi le test (
détails techniques ). Sur les forums, comme solution de contournement, nous avons recommandé de désactiver la vérification des signatures d'extension dans
about: config ou en traduisant l'horloge système.
Mozilla a rapidement publié le correctif Firefox 66.0.4, qui résout le problème avec un certificat non valide, et toutes les extensions sont retournées à leur forme normale. Les développeurs recommandent de l'installer et de
ne pas utiliser de solution de contournement pour contourner la vérification de signature, car ils peuvent entrer en conflit avec le correctif.
Cependant, cette histoire montre une fois de plus que l'expiration des certificats reste un problème urgent aujourd'hui.
À cet égard, il est intéressant de regarder d'une manière assez originale comment les développeurs du protocole
DNSCrypt ont fait face à cette tâche. Leur solution peut être divisée en deux parties. Premièrement, ce sont des certificats à court terme. Deuxièmement, avertir les utilisateurs de l'expiration de ceux à long terme.
DNSCrypt
DNSCrypt - Protocole de chiffrement du trafic DNS. Il protège les communications DNS contre les interceptions et MiTM, et vous permet également de contourner le blocage au niveau des requêtes DNS.
Le protocole enveloppe le trafic DNS entre le client et le serveur dans une conception cryptographique, travaillant 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, il était activé sur ses serveurs DNS et dans le navigateur Yandex. Le support a été annoncé par plusieurs autres fournisseurs, dont Google et Cloudflare. Malheureusement, ils sont peu nombreux (152 serveurs DNS publics sont répertoriés sur le site officiel). Mais le programme
dnscrypt-proxy peut être installé manuellement sur les clients sous Linux, Windows et MacOS. Il existe
des implémentations de serveur .
Comment fonctionne DNSCrypt? En bref, le client prend la clé publique du fournisseur sélectionné et avec son aide vérifie ses certificats. Il existe déjà des clés publiques à court terme pour la session et l'identifiant de la suite de chiffrement. Il est conseillé aux clients de générer une nouvelle clé pour chaque demande, et les serveurs sont encouragés à changer les clés
toutes les 24 heures . Lors de l'échange de clés, l'algorithme X25519 est utilisé, EdDSA pour la signature et XSalsa20-Poly1305 ou XChaCha20-Poly1305 pour le chiffrement de bloc.
Frank Denis, l'un des développeurs du protocole,
écrit que le remplacement automatique toutes les 24 heures a résolu le problème des certificats expirés. En principe, le client de référence dnscrypt-proxy accepte les certificats avec une période de validité quelconque, mais il affiche un avertissement «La période de clé dnscrypt-proxy pour ce serveur est trop longue» si elle est valide pendant plus de 24 heures. Dans le même temps, une image Docker a été publiée, dans laquelle ils ont implémenté un changement rapide de clés (et de certificats).
Premièrement, il est extrêmement utile pour la sécurité: si le serveur est compromis ou que la clé est divulguée, le trafic d'hier ne peut pas être décrypté. La clé a déjà changé. Ce sera probablement un problème pour la mise en œuvre de la «loi de printemps», qui oblige les fournisseurs à stocker tout le trafic, y compris le trafic chiffré. Il est entendu que plus tard il pourra être décrypté si nécessaire en demandant une clé au site. Mais dans ce cas, le site ne pourra tout simplement pas le fournir, car il utilise des clés à court terme, supprimant les anciennes.
Mais le plus important, é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é ne sont pas configurés ou ne fonctionnent pas, cela sera immédiatement détecté.
Lorsque l'automatisation change de clé toutes les quelques années, vous ne pouvez pas vous y fier et les utilisateurs peuvent oublier l'expiration du certificat. Avec un changement de clé quotidien, cela sera détecté instantanément.
Dans le même temps, si l'automatisation est configurée normalement, la fréquence de changement des clés n'a pas d'importance: chaque année, chaque trimestre ou trois fois par jour. Si tout fonctionne pendant plus de 24 heures, cela fonctionnera pour toujours, écrit Frank Denis. Selon lui, la recommandation d'un changement de clé quotidien dans la deuxième version du protocole, ainsi que l'image Docker prête à l'emploi qui le met en œuvre, ont effectivement réduit le nombre de serveurs avec des certificats expirés, tout en améliorant la sécurité.
Cependant, certains fournisseurs ont tout de même décidé, pour des raisons techniques, de fixer la période de validité du certificat à plus de 24 heures. Ce problème a été principalement résolu avec 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 avec un niveau de gravité plus élevé 7 jours avant l'expiration du certificat et un message critique si le certificat reste moins de 24 heures. Cela ne s'applique qu'aux certificats qui ont initialement une longue période de validité.
Ces messages permettent aux utilisateurs d'informer les opérateurs DNS de l'expiration prochaine du certificat avant qu'il ne soit trop tard.
Peut-être que si tous les utilisateurs de Firefox avaient reçu un tel message, alors quelqu'un aurait probablement informé les développeurs et n'aurait pas autorisé l'expiration du certificat. "Je ne me souviens pas d'un seul serveur DNSCrypt de la liste des serveurs DNS publics ayant expiré un certificat au cours des deux ou trois dernières années", écrit Frank Denis. Dans tous les cas, il est probablement préférable d'avertir d'abord les utilisateurs et de ne pas désactiver les extensions sans avertissement.
