Sujet
Automatisation de la sécurité
Au sein de la facette Sujet, la veille thématique Automatisation de la sécurité rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.
IETF
La clé active a signé sa remplaçante. C’était précisément le risque.
Une rotation peut être parfaitement signée et pourtant constituer la persistance de l’attaquant. La question décisive n’est pas seulement « la signature est-elle valide ? », mais « cette clé avait-elle, seule, le mandat de choisir tout l’avenir de l’identifiant ? »
IETF
Le nœud était bien authentifié. La carte, elle, restait locale.
Au cours d’une revue d’incident, deux équipes présentent des captures valides du même nœud SAND. Les signatures passent, les identités concordent, mais les voisinages ne se recouvrent presque pas. La tentation est de désigner une vue « correcte » et l’autre « incomplète ». La…
IETF
Le préfixe était enregistré. L’interprète restait local.
Une adresse IP écrite sous une forme lisible paraît se suffire à elle-même. Pourtant, avant qu’elle devienne une valeur CBOR, un registre a résolu un nom, une extension précise a été chargée et une politique locale a autorisé son exécution. La lisibilité montre l’intention; elle…
Histoire d'Internet
Le mot de passe correspondait. L’utilisateur n’était pas encore authentifié : RFC 3112
RFC 3112 permettait à LDAP de comparer un secret à une valeur dérivée conservée dans l’annuaire. Mais la réponse vraie restait volontairement étroite: elle ne transformait pas la connexion en association authentifiée.
IETF
Une mise à jour atomique peut être entièrement mauvaise
Le mérite de DUJ est d’empêcher qu’une modification DNS composée s’arrête au milieu. Sa limite est tout aussi importante: l’atomicité protège la cohérence de l’opération, pas la légitimité de celui qui l’a demandée ni la justesse de son résultat.
IETF
Le certificat était valide, pas encore sa délégation AS2
Le moment dangereux d'une rotation n'est pas toujours celui où la cryptographie échoue. C'est parfois celui où tout fonctionne, alors que personne ne peut encore produire l'acte qui autorise cette clé à parler au nom de ce partenaire précis.
IETF
Le canal n’a pas rompu. La confiance, elle, avait vieilli
Une preuve d’attestation fraîche liée à une connexion TLS ferme la porte au relais lors de l’établissement. Elle ne transforme pas l’état logiciel, la politique ni les droits de la machine en propriétés permanentes du canal.
Dossier
Huit numéros dans le brouillon, aucun encore dans le registre
Un comité d’autorisation peut valider un programme cryptographique tout en restant incapable de répondre à une question élémentaire: à quelle autorité le nombre qu’il s’apprête à déployer appartient-il ? Le 1er octobre 2026, la révision 05 d’un Internet-Draft OpenPGP nommait huit…
IETF
Le site annonce zéro, mais ses routes peuvent rester dans BGP
La nouvelle révision du projet sur les métadonnées de périphérie transforme une seule valeur nulle en décision de transfert pour tout un site. Le message est bref; la preuve de son exécution, elle, traverse plusieurs systèmes.
Histoire d'Internet
Le pare-feu autorisait HTTP, pas le paquet caché dedans : RFC 3093
RFC 3093 proposait de placer un datagramme IP complet dans un message HTTP, de franchir l’ouverture réservée au Web puis de le réinjecter derrière le pare-feu. Publié le 1er avril 2001, ce dispositif comique révélait une limite sérieuse: autoriser l’enveloppe ne signifie pas…
IETF
La clé maîtresse a tourné. Les anciennes associations pouvaient encore parler
PSP conserve deux clés maîtresses côté réception. Quand l’une cesse d’être active, les nouvelles associations passent à l’autre, mais les anciennes peuvent continuer à produire des clés valides. Une rotation change donc le futur; elle n’efface pas encore le passé. Le projet qui…
IETF
La liste était exacte. Encore fallait-il que la configuration soit entière
IntraSAV propose de remplacer l’inférence par une autorisation explicite des préfixes sources. La promesse de zéro erreur dépend toutefois d’un fait que chaque interface doit encore prouver: la configuration reçue était-elle complète et actuelle ?
Histoire d'Internet
La même zone était sûre ici et non sécurisée ailleurs : RFC 3090
En 2001, demander si une zone DNS était « sûre » ne suffisait déjà plus. Il fallait savoir quel résolveur posait la question, quelle racine de confiance il connaissait et quel chemin il avait suivi. RFC 3090 a donné des mots à cette relativité: une zone signée pouvait former un…
Histoire d'Internet
L’URI choisissait le menu vocal, sans authentifier l’appelant : RFC 3087
En 2001, un appel SIP pouvait parvenir à une messagerie sans emporter tous les indices fiables qui guidaient les anciens commutateurs. RFC 3087 a confié au destinataire courant de la requête le choix du premier état de l’application. L’adresse donnait une consigne de service…
IETF
L’en-tête de débogage racontait chaque étape sans pouvoir en prouver aucune
Un nouveau brouillon DKIM2 propose aux testeurs une piste médico-légale commune à l’intérieur du message. Sa précision aide à enquêter, mais son autorité est volontairement nulle.
IETF
Dix minutes de maximum ne racontent pas dix minutes de Wi-Fi
Un serveur RADIUS reçoit une valeur de débit accompagnée de `MAX(10m)`. La chaîne est valide, la fenêtre est explicite et la donnée semble plus sérieuse qu’un simple instantané. Pourtant, le maximum ne dit ni combien de temps le débit a été tenu, ni quels paquets ont servi au…
Histoire d'Internet
Le serveur avait poussé les règles. La reconnexion devait encore réconcilier ce que l’équipement avait gardé : RFC 3084
RFC 3084 organisait le provisioning de politiques comme une conversation à états partagés: une décision groupée, un accusé d’exécution, un retour à l’état antérieur en cas d’échec. La coupure révélait pourtant la limite du modèle. Le serveur et l’équipement pouvaient tous deux…
IETF
Le rafraîchissement s’est terminé. Le collecteur ignorait encore si la RIB était entière
Une proposition BMP permet de réparer une seule vue de routage sans interrompre toutes les sessions surveillées. Son marqueur final ferme la retransmission, mais ne certifie pas à lui seul qu’aucune route n’a disparu en chemin.
Histoire d'Internet
Le câble chiffrait le trafic. Son plan de gestion pouvait encore désactiver la confidentialité : RFC 3083
RFC 3083 a rendu la confidentialité DOCSIS observable, réglable et réinitialisable par SNMP. Cette visibilité aidait le diagnostic, mais elle ouvrait une seconde frontière de sécurité: l’interface qui regardait les clés pouvait aussi relancer l’autorisation, modifier les délais…
IETF
Le tableau de bord disait SRv6. L’arbre multicast parlait encore PIM
Une route vers la source peut suivre Flex-Algo 128 dans un réseau SRv6 sans qu’aucune branche multicast soit décrite par une liste de SID. Entre le voyant vert de l’architecture et la vidéo reçue se trouvent un calcul IP, un contrôle RPF, un état `(S,G)`, des interfaces de…