Domaine principal
Sécurité
Au sein de la facette Domaine principal, l'analyse Sécurité regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
Entreprises de services cloud en Amérique du Nord
L’offre de Proofpoint sur Varonis met à l’épreuve le lien entre menaces et accès aux données
Une alerte ne protège pas les données à elle seule. Il faut encore relier l’identité qui a agi, les informations qu’elle pouvait atteindre, la permission en cause et la mesure qui a réellement réduit l’exposition. Proofpoint veut rapprocher ces éléments en rachetant Varonis. Pour…
Récits
Au symposium FIRST lié à LACNIC 46, CEDIA réserve les décisions critiques aux humains
Le 21 octobre, une session présentera DALIA comme un outil d’aide au triage et à la corrélation des signaux des CSIRT, tout en laissant les décisions critiques et le confinement aux personnes. Le résumé ne précise pas comment cette limite est appliquée.
IETF
Le message n’avait pas un seul corps pour le filtre.
Le même courriel pouvait être un bloc d’octets, un arbre de parties MIME ou le texte qu’un extracteur réussissait à produire. Le RFC 5173 n’a pas choisi une version comme vérité. Il a donné au script trois surfaces distinctes et, avec elles, trois raisons différentes de trouver…
IETF
Le jeton enfant était valide. La chaîne devait encore l’autoriser.
Une signature correcte sur un jeton délégué ne suffit pas à produire un pouvoir exploitable. Le projet OAuth étudié exige de remonter jusqu’à une racine reconnue, de prouver chaque délégation et chaque réduction, puis de laisser au serveur de ressources sa décision locale.
IETF
Le fabricant a signé les nouvelles racines. Le serveur de livraison restait non authentifié.
Un équipement peut recevoir des certificats d’autorité par un canal dont il ne reconnaît pas encore le serveur. La sécurité ne tient alors qu’à une discipline stricte: vérifier l’objet, décider localement de modifier la confiance, puis ouvrir une nouvelle session où l’identité du…
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…
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.
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
La clé ACME a tourné. L’autorisation DNS d’hier tient toujours
La révision 02 du mécanisme DNS persistant d’ACME sépare une opération familière — changer de clé — du retrait réel d’une autorisation. La vieille clé ne signe plus rien, mais son empreinte publique peut encore soutenir une validation en cours de vie.
IETF
Quand la preuve est valide, à qui appartient encore l’étiquette ?
La transparence des clés sait rendre une réponse vérifiable. Elle ne décide pas, à elle seule, qui avait le droit d’agir ni qui devra surveiller l’étiquette demain. La dernière revue de l’IETF place précisément cette frontière au centre du dossier.
Histoire d'Internet
RFC 2350 face à son gardien disparu : que reste-t-il de la redevabilité sur le traitement des incidents de sécurité
L'Internet fonctionne toujours sur un document de 1998 rédigé par un groupe de travail qui a cessé d'exister en décembre 2001.
Dossier
La valeur était la même. Les octets reconstruits ne l’étaient pas
Deux services ont affiché le même objet CBOR, champ pour champ. Le premier l’a signé, le second a refusé la signature. Aucun attaquant n’avait modifié la valeur: chaque bibliothèque avait simplement choisi une représentation binaire différente parmi celles que CBOR autorise. Le…
Dossier
La preuve changeait à chaque fois. Son enveloppe reconnaissait toujours la même personne
Deux preuves BBS ne trahissaient aucun lien cryptographique entre elles. Pourtant, un en-tête rare, une liste de dix messages, les mêmes indices divulgués et une clé d’émetteur réservée à douze titulaires suffisaient à les réunir. La preuve avait tenu sa promesse. Le système…
Dossier
Le registre disait `co`. La poignée de main n’avait rien dit : RFC 9952
Un catalogue de services annonce `co`. L’équipe d’exploitation le lit comme une promesse de négociation. Le serveur accepte pourtant une session DTLS dont la trace ne contient aucune extension ALPN. Le registre, le DNS et le paquet ne se contredisent pas nécessairement: ils…
Dossier
Le nom du chiffrement n’a pas changé, sa règle de réutilisation si : RFC 10032
Une équipe d’optimisation remplace trois adaptateurs par une fonction commune baptisée « AEGIS ». Les tests cryptographiques restent verts. Pourtant, la fusion efface la différence la plus importante: chiffrer, produire un flot et calculer un MAC n’autorisent ni la même…
IETF
IDMEFv2 donne un vrai sens au 204, pas au second POST
Un capteur transmet une alerte, le gestionnaire l’enregistre, puis la réponse se perd. Le nouveau projet de transport IDMEFv2 rend le 2xx probant sur la réception durable. Il laisse cependant aux membres du consortium le sens de la nouvelle tentative.
Dossier
La signature était valide. Elle ne nommait pas les approbateurs : RFC 9591
Le contrôle a reçu deux objets: un message et une signature Schnorr valide sous la clé publique du groupe. Il en demandait un troisième, la liste des personnes ayant approuvé l’opération. Ce troisième objet n’est pas caché dans la signature. Le RFC 9591 permet à plusieurs parts…
Dossier
La liste annonçait EdDSA, mais pas encore la courbe : RFC 9864
Une plateforme peut publier une liste d’algorithmes parfaitement valide et ne pas avoir encore décrit une capacité négociable. Le nom `EdDSA` ne dit pas si elle comprend Ed25519, Ed448 ou une convention locale. Le RFC 9864 remet ce choix dans l’identifiant. Il clarifie le langage…
Dossier
La sauvegarde a restauré la clé — et l’état d’hier : RFC 9802
Deux équipements de signature repartent d’une même sauvegarde. Tous deux possèdent la bonne clé privée et produisent des signatures valides. S’ils réutilisent pourtant le même indice à usage unique, la reprise a détruit l’hypothèse de sécurité sans que le certificat le dise. Le…