Skip to content
Une chaîne de confiance qui part de la racine signée, traverse un TLD signé et s'arrête à un domaine de second niveau non signé, avec les chiffres comptés à côté de chaque étape

DNSSEC : protéger votre trafic de la falsification

Le plus dur de DNSSEC était fini il y a des années. Compté sur la zone racine en direct le 27 septembre 2026, 1 351 domaines de premier niveau sur 1 438 portent un enregistrement DS, et les 1 038 gTLD sont signés sans exception. Puis ça s’arrête net. Un recensement de tous les domaines gov.uk du registre officiel du gouvernement en trouve 39 signés sur les 2 390 qui résolvent encore, dont neuf conseils de paroisse, tandis que le fisc, le NHS, le GCHQ et le Centre national de cybersécurité n’en font pas partie. Une autorité de certification sur neuf a signé. Une distribution Linux sur trois aussi. windowsupdate.com n’a aucun DS. Voici ce que coûte réellement une réponse falsifiée, ce que la signature y change, pourquoi les excuses habituelles ne survivent pas au contact des chiffres, et si, quarante-deux ans après Mockapetris, le vrai problème n’est pas que presque personne ne comprend ce que le DNS promet.

27 septembre 2026 Â· 53 min Â· 12020 mots Â· Damien Dye

Webex cherche vos certificats sur un serveur de build Cisco

Webex 46.8.0.35631 sur Fedora 44 reste derrière une bannière jaune affichant « Offline - No internet connection » alors que tous les autres programmes de la machine atteignent internet sans se plaindre. Ça a coupé la ligne VoIP net. Le réseau n’a jamais été le problème : Cisco livre son propre fork d’OpenSSL et l’a compilé avec OPENSSLDIR pointant sur /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, un répertoire qui existe sur un conteneur de build et nulle part ailleurs, donc il ne charge aucune ancre de confiance et toute poignée de main échoue. L’article se déroule dans l’ordre : ce qu’est vraiment l’état cassé, demander à la bibliothèque livrée où elle croit que vivent ses certificats, reproduire le code d’erreur exact hors de Webex, pourquoi rien ne vous prévient, les deux correctifs qui ne marchent pas et pourquoi, et celui qui marche. Puis le processus de build : ils ont utilisé $ORIGIN pour le code et laissé trois chemins de données absolus, l’en-tête du RPM nomme un identifiant de conteneur, donc le conteneur était déjà dans la chaîne et n’a jamais servi à exécuter le résultat, le paquet exige une glibc de 2018 parce qu’ils refusent de lier statiquement, 2,2 Go sont livrés deux fois, et il ne porte aucune documentation ni aucun fichier marqué comme configuration. Puis comment il aurait fallu le construire, les six correctifs et le contrôle d’une ligne qui l’attrape. Et enfin le recoupement : Cisco détient 98 entrées au catalogue des vulnérabilités activement exploitées de la CISA, derrière Microsoft seulement, et un chemin de confiance que personne n’a vérifié et un contournement que personne n’a vérifié sont la même faute à des enjeux différents.

15 septembre 2026 Â· 45 min Â· 9794 mots Â· Damien Dye