Skip to content

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

Un VPN en pièces détachées : PPP, tap et Netcat

Un VPN, c’est deux tâches : quelque chose qui fabrique un lien virtuel, et quelque chose qui transporte les octets. PPP fait la première depuis 1994 et se moque de la seconde — c’est pourquoi PPTP, L2TP et chaque ligne commutée que vous avez utilisée sont le même protocole sur des transporteurs différents. Netcat est un transporteur. Ce billet le construit des deux façons. D’abord pppd : l’option pty et ce qu’elle fait d’un pseudo-terminal, la version TCP que tout le monde essaie d’abord, pourquoi faire tourner un protocole de flux dans TCP s’effondre sous la perte, la version UDP qu’il faut prendre, le tramage HDLC asynchrone et l’ACCM qui décide de la bande passante dépensée à échapper des caractères de contrôle, l’adressage et le routage et IPV6CP, et garder le lien en vie quand le transporteur meurt sans le dire. Puis le même tunnel sans PPP du tout — un tap, un datagramme par trame sur UDP, le préfixe de longueur qu’il faut inventer soi-même sur TCP, tun contre tap, et le bridging. Puis la partie pour laquelle netcat n’a pas de réponse : envelopper le transporteur dans TLS avec ncat, stunnel et openssl, et dans DTLS avec socat, qui est la forme qu’on veut vraiment. Ce n’est jamais vraiment le bon outil, et c’est là le propos : il montre comment se comporte l’egress dès qu’un attaquant a root dans votre réseau et que l’accès sortant n’était pas bloqué par défaut, et pourquoi le default-deny à la frontière est le seul contrôle qui ait jamais été réel.

14 septembre 2026 Â· 65 min Â· 14203 mots Â· Damien Dye
Une horloge invitée qui s'éloigne de l'horloge de l'hôte, et un hypercall qui la ramène

L'horloge d'une VM n'est pas fiable — et le correctif ptp_kvm pour QEMU/KVM

L’horloge d’une machine virtuelle repose sur une hypothèse que la virtualisation casse : que le CPU continue de compter. Pourquoi l’heure des invités dérive sur tous les hyperviseurs, ce que le décalage casse vraiment — Kerberos, TLS, Ceph, Windows — et comment ptp_kvm corrige ça proprement sur QEMU/KVM.

7 aoĂ»t 2026 Â· 17 min Â· 3444 mots Â· Damien Dye