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
Un identifiant de transaction discret ne suffit pas à protéger la transaction
Attribuer deux identifiants différents à une même opération évite un rapprochement trop facile entre services. Mais le jeton qui transporte ces identifiants contient d’autres indices. Une nouvelle proposition OAuth place cette limite au centre du débat sur la confidentialité et…
IETF
L’enveloppe était signée. Le texte chiffré détaché ne l’était pas.
Un entrepôt contient l’objet COSE, un autre conserve les octets chiffrés, et le tableau de bord n’affiche qu’un voyant « signature valide ». Cette simplification efface la question décisive: quels octets exacts sont entrés dans le calcul cryptographique, et lesquels ont seulement…
IETF
Le calendrier l’appelait propriétaire. Aucun pouvoir ne lui avait encore été accordé.
Un calendrier portable peut attribuer à une personne le rôle de propriétaire sans faire d’elle un éditeur autorisé. Le libellé décrit une place dans l’événement; le protocole d’échange doit encore décider qui peut déplacer la réunion, changer les entités ou diffuser une mise à…
IETF
La redirection a réussi. Le secret avait déjà circulé en clair.
Le journal se termine sur une URL HTTPS et l’appel produit le résultat attendu. Cette fin rassurante efface pourtant le début: avant de recevoir la redirection, le client avait déjà placé son jeton dans une requête HTTP lisible sur le réseau.
IETF
La chaîne a validé l’ancre qu’elle apportait. Le destinataire ne lui avait pas accordé sa confiance.
Avec did:x509, une résolution impeccable peut s’achever avant que la décision essentielle ne commence. La chaîne fournie se tient, l’empreinte de l’autorité correspond et les prédicats de la feuille sont vrais; rien de tout cela ne dit encore que le destinataire reconnaît cette…
Histoire d'Internet
Le KDC a porté la confiance que chaque pair IPsec ne pouvait assumer : RFC 3129
En juin 2001, la RFC 3129 ne demanda pas seulement comment produire des clés IPsec. Elle demanda où placer la confiance, le calcul et la politique lorsqu'un réseau devient trop vaste pour que chaque machine entretienne une relation particulière avec toutes les autres.
IETF
Le secours a déclaré la panne. Le trafic n’avait pas cessé.
Dans un domaine BIER, le routeur d’entrée de secours peut perdre le chemin qui lui sert à surveiller le routeur sélectionné alors que les chemins multicast vers les récepteurs restent intacts. Une mesure locale devient alors, à tort, l’autorisation de déplacer le trafic.
Histoire d'Internet
Le premier fragment est passé ; le chevauchement a changé le port : RFC 3128
La faille racontée par la RFC 3128 ne résidait pas dans un paquet évidemment malveillant. Elle naissait entre deux lectures légitimes: celle du filtre, qui autorisait un premier fragment cohérent, et celle de l’hôte, qui pouvait reconstruire un en-tête TCP différent après…
Histoire d'Internet
La preuve à long terme devait survivre à la clé : RFC 3126
La RFC 3126 aborda l’ancienne signature comme un problème de conservation des preuves. Un calcul valable en 2001 ne pouvait plus s’expliquer seul si certificats, données de révocation, octets signés ou algorithmes fiables avaient disparu. Sa réponse fut une chaîne renouvelable…
IETF
Le message s’est ouvert, mais la mémoire du groupe manquait encore
Un récepteur externe MLS peut déchiffrer exactement le même Commit ou Proposal que les membres sans disposer de l’état qui authentifie son auteur. La pièce manquante n’est pas une seconde couche de chiffrement: c’est le GroupContext qui relie époque, feuille d’envoi, credential…
IETF
Cinq octets sur le fil, aucun entier sûr dans le programme
Le message EDHOC était valide, l'entier CBOR aussi. Pourtant, au moment de quitter le décodeur, la valeur privée ne tenait plus dans le champ choisi par l'équipement. La panne n'était ni cryptographique ni syntaxique: elle venait du contrat invisible entre le protocole et le type…
Histoire d'Internet
Une signature valide avait encore besoin d’une politique : RFC 3125
La RFC 3125 voulut rendre les règles entourant une signature électronique identifiables et, si nécessaire, exécutables par une machine. Le calcul cryptographique ne fermait pourtant qu’une première porte: la validité dépendait encore de la politique exacte, du type d’engagement…
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…