La tortue est une lente. C’est ce que tout le monde sait d’elle, et c’est ce qu’on lui reproche. Le reste — sa longévité, sa carapace, sa mémoire des saisons, son indifférence aux modes qui passent au-dessus d’elle — reste dans l’ombre du cliché.
Sous cette signature, la lenteur est un choix. Le domaine dont ce site parle — la cybersécurité, comprise comme une condition d’existence dans un monde connecté plutôt que comme une discipline technique — est traversé de vitesses qui n’ont pas de sens. Les vulnérabilités du mois, les acronymes du trimestre, les paradigmes de l’année. La tortue les regarde passer, revient sur ce qui les précède, et prend le temps que le sujet mérite. C’est souvent plus long qu’on ne croit.
Elle explique. C’est son premier travail. Un article signé sous ce nom prend le temps de nommer ce dont il parle, de le poser dans son contexte, et de ne rien supposer d’acquis chez le lecteur — sauf ce qui a été construit par les articles précédents. On n’y trouvera pas de raccourci qui reposerait sur du vocabulaire non défini, ni de saut logique qui laisserait un débutant en arrière au deuxième paragraphe.
Elle revient. Un sujet vu il y a six mois peut être repris parce que le contexte a bougé, parce qu’un lecteur a posé une bonne question, ou parce que la première version, avec le recul, était incomplète. La cohérence longue passe avant la fraîcheur.
Elle protège. La carapace de la tortue n’est pas un ornement, c’est ce qui la fait vivre. Les articles qui paraissent ici sont écrits avec l’idée que la sécurité informatique n’est pas un supplément à la vie numérique mais sa condition — qu’un système sans défense n’est pas un système simple, c’est un système qui n’a pas encore rencontré son adversaire.
Des fondamentaux, expliqués comme s’ils étaient nouveaux, parce qu’ils le sont pour quelqu’un tous les jours. Le fonctionnement d’un protocole qu’on croit connaître, l’histoire d’un standard, la raison pour laquelle une décision d’architecture prise il y a deux décennies continue de peser. La cartographie d’un domaine où les cartes du dernier trimestre sont déjà périmées.
Des explications, plutôt que des annonces. Une CVE fraîche n’est pas un sujet en soi ; ce qu’elle révèle du modèle mental d’une génération d’ingénieurs, oui. Le fait qu’un service a été attaqué la semaine dernière n’apprend rien ; ce que l’attaque nous dit du couplage entre deux couches qu’on croyait indépendantes, si.
Concrètement, c’est la signature qui tient les grandes rubriques du site : la cryptographie prise depuis ses promesses plutôt que depuis ses algorithmes, les modules matériels et leurs interfaces normalisées, les infrastructures à clé publique et TLS, les réseaux, l’architecture de sécurité, et ce que l’IA exécutée localement change ou ne change pas. Elle tient aussi les fiches d’organismes — qui écrit les normes, avec quel mandat, et ce que cela vaut quand on lit une recommandation.
Une bonne part du travail de cette voix ne se lit pas comme un article : c’est le glossaire. Un terme y reçoit une définition unique, tenue à un seul endroit et réutilisée partout ailleurs — de sorte qu’un mot croisé dans trois pages différentes veuille dire exactement la même chose dans les trois.
C’est fastidieux et c’est le cœur du dispositif. Un domaine dans lequel les mêmes mots désignent des choses différentes selon l’auteur ne peut pas être appris ; il ne peut qu’être fréquenté assez longtemps pour qu’on finisse par deviner. La tortue refuse ce coût d’entrée, et elle le refuse par la maintenance plutôt que par la déclaration d’intention.
Ce n’est pas de la veille. Il y a d’autres endroits pour ça, et ils font ce travail mieux. Un article signé sous ce nom ne cherche pas à être en avance sur l’actualité, il cherche à durer plus longtemps qu’elle.
Ce n’est pas de la nostalgie non plus. Prendre le temps n’est pas la même chose que regretter le passé. Les protocoles anciens sont examinés pour ce qu’ils enseignent, pas pour ce qu’ils remplaçaient. La tortue avance ; elle n’est pas retournée dans son terrier.
Parce qu’un site sur la sécurité qui ne parlerait qu’aux gens qui savent déjà participerait au problème qu’il prétend traiter. Ce qui manque le plus dans ce domaine n’est pas l’information — elle sature — mais l’explication patiente qui permet à quelqu’un de comprendre ce qu’il lit ailleurs. Cette voix existe pour ça.
C’est aussi la voix qui donne son nom au site, ce qui n’est pas un accident. Les autres signatures écrivent leurs articles ; celle-ci écrit le sol sur lequel les autres marchent — le vocabulaire que le castor emploie sans avoir à le redéfinir à chaque démonstration, et la matière que la marmotte traduit pour ceux qui arrivent sans les mots.
🐢 Ce que cette voix a posé
7 pages sous cette signature — cliquez une carte pour en voir le détail.
Cryptographie
Comment deux parties qui n'ont jamais rien partagé se fabriquent un secret commun — et pourquoi ce secret ne vaut rien tant que personne n'a vérifié à qui il parle.
Le fil : Du secret partagé sans canal secret jusqu'à HPKE, en passant par Diffie-Hellman et ses variantes, les KEM et la dérivation. Chaque sous-section est marquée par niveau : on peut s'arrêter avant l'expert sans perdre le fil.
Le point qui coûte cher : Un échange non authentifié se fait intercepter en silence : l'homme du milieu établit deux secrets, un avec chaque partie, et lit tout. L'authentification des clés publiques n'est pas une option de confort.
Pièges traités : Utiliser le secret partagé brut sans passer par un KDF, réutiliser des clés éphémères, accepter des paramètres de groupe faibles, confondre DH statique et éphémère.
Une clé publique ne dit pas à qui elle appartient. Ce que le certificat ajoute, comment la chaîne de confiance se construit, et où les PKI cèdent en pratique.
Le fil : À quoi sert un certificat, puis lire un X.509 sans se noyer, puis la WebPKI telle qu'elle fonctionne vraiment, et enfin la PKI privée — ses règles ne sont pas celles du Web.
Le point qui coûte cher : La confiance ne se démontre pas, elle se configure : elle vaut exactement ce que vaut le magasin d'autorités racines de la machine qui vérifie. C'est un choix d'administration, pas une propriété cryptographique.
Pièges traités : Faire confiance à un certificat auto-signé sans distribution sûre, oublier les extensions d'usage, renouveler manuellement trop tard, pinner sans plan de rotation.
TLS pris comme cas d'intégration complet plutôt que comme une case à cocher : ce que le canal garantit, ce qu'il ne garantit pas, et ce qui casse en exploitation.
Le fil : Ce que garantit un canal, l'architecture TLS, puis TLS 1.3 en pratique et l'exploitation au quotidien — handshake, suites cryptographiques, record layer, reprise de session, forward secrecy.
Le point qui coûte cher : TLS protège le transport, pas l'application ni les extrémités. Un canal parfaitement chiffré vers un serveur compromis ne protège rien : la case « HTTPS » n'est pas une propriété de sécurité applicative.
Pièges traités : Activer trop de versions anciennes, confondre HTTPS et sécurité applicative, ignorer le 0-RTT et le rejeu, mettre des secrets dans les journaux TLS, ne pas surveiller l'expiration.
PKI et TLS
Ce que TLS garantit vraiment — confidentialité, intégrité, authentification — et la liste, plus courte qu'on ne croit, de ce qu'il ne protège pas.
Le fil : Les trois objectifs de TLS, le déroulement d'une négociation, le rôle des certificats, l'échange de clés et la forward secrecy — puis un exemple d'inspection d'une négociation réelle.
Le point qui coûte cher : TLS protège le canal, pas les extrémités. Si le serveur ou le client est compromis, le chiffrement en transit n'apporte rien sur les données au repos — et les métadonnées (tailles, horodatages, nom de serveur) fuient malgré tout.
Limites traitées : Fuite de métadonnées, confiance dans les autorités de certification, suites anonymes et versions obsolètes qui annulent les garanties, rejeu des données 0-RTT en TLS 1.3.
La résolution de noms précède presque toute autre communication — et voyage en clair. Ce que DoT chiffre, comment le configurer, et pourquoi le mode par défaut ne protège pas.
Le fil : Pourquoi chiffrer le DNS, comment DoT fonctionne, comment authentifier le résolveur, puis la configuration d'un stub resolver et la place de DoT dans l'écosystème DNS sécurisé.
Le point qui coûte cher : Le mode opportuniste, souvent actif par défaut, ne protège pas d'un attaquant actif : il donne une fausse impression de sécurité. Seul le profil strict avec vérification du nom offre une garantie robuste.
Ce qu'on gagne, ce qu'on déplace : Orienter toutes les requêtes vers un résolveur public chiffre le trajet mais concentre la visibilité chez un opérateur unique, qui voit alors l'intégralité des noms résolus. C'est un arbitrage de gouvernance, pas un réglage technique.
Le protocole qui automatise l'émission et le renouvellement de certificats X.509 sur un canal TLS, sans jamais faire transiter la clé privée du client en clair — la base des flux d'enrôlement zero-touch.
Le fil : Pourquoi l'enrôlement de certificats a besoin de son propre protocole, l'architecture client/serveur/AE d'EST, ses opérations (cacerts, simpleenroll, simplereenroll, serverkeygen), le problème du bootstrap de confiance, puis une comparaison avec SCEP.
Le point qui coûte cher : serverkeygen fait générer la clé privée par le serveur puis la transmet au client : pratique pour un équipement contraint, mais un instant où la clé n'est plus exclusivement entre les mains de son propriétaire. À réserver aux cas où le client ne peut vraiment pas générer sa propre paire de clés.
Limites traitées : Le bootstrap initial (comment faire confiance à un serveur EST inconnu), la dépendance à une PKI déjà en place, et ce qu'EST ne couvre pas (révocation, distribution de politique fine).
Réseaux
Les trois services qu'on ne regarde jamais tant qu'ils marchent — nommage, configuration automatique, temps — et la façon dont un réseau entier dépend d'eux sans le dire.
Le fil : Nommer et résoudre, configurer automatiquement, puis temps, sécurité et visibilité. Trois briques d'infrastructure traitées ensemble parce que les pannes qu'elles produisent se ressemblent : tout marche, sauf que non.
Le point qui coûte cher : Ce sont des dépendances invisibles : une horloge qui dérive casse l'authentification, un DHCP ouvert sur le mauvais segment reconfigure des machines qui ne demandaient rien. Le symptôme n'indique jamais la cause.
Pièges traités : Modifier le mauvais serveur DNS, croire que le TTL signifie propagation instantanée, laisser DHCP ouvert sur un segment non prévu, confondre DoH et anonymat.
