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.
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…
IETF
Chiffrer avant d’envoyer : RFC 9787 et la frontière d’engagement du brouillon
Scène hypothétique: quelques phrases saisies sur un ordinateur sont sauvegardées automatiquement, puis réapparaissent sur un téléphone lorsque leur auteur reprend son travail. La continuité est réelle, mais l’envoi ne l’est pas. Les destinataires pressentis ne devraient toujours…
Tendances services cloud Amérique du Nord
PaperCut remplace ses correctifs d’urgence: échéance CISA passée
Les nouvelles versions de maintenance PaperCut clarifient le suivi des versions, mais les serveurs de site et secondaires restent à vérifier.
IETF
Le badge était unique, pas la portée cryptographique : lire le RFC 9787
Une interface de messagerie rassemble corps, pièces jointes, transferts et fragments imbriqués dans une même fenêtre. Le RFC 9787 refuse d'en déduire une sécurité commune: son résumé unique ne vaut que pour les couches contiguës qui entourent la charge utile cryptographique.
Dossier
Cinq écritures, un seul objet : quels octets RFC 9804 a-t-il fait signer ?
RFC 9804 organise le passage des S-expressions SPKI entre notation lisible, transport, octets canoniques et mémoire locale. Mais une ressemblance à l’écran n’est pas une chaîne de preuve. Pour savoir ce qui a été signé puis autorisé, il faut conserver chaque transformation au…
Récits
Le honeynet d’APNIC a journalisé 1,27 million d’événements. Ce ne sont pas 1,27 million d’attaques
Une présentation d’APNIC 62 transforme un serveur volontairement exposé en poste d’observation utile. Mais son chiffre vedette change de nature selon l’écran: attaques, événements d’attaque, puis simples événements.
IETF
TLS : la réparation de la renégociation ne prouve pas la fermeture du risque
La renégociation TLS a été corrigée au niveau du protocole. La question restante est plus difficile: quelles preuves montrent que ce correctif a réellement atteint les bibliothèques, les équipements, les services internes et les chemins applicatifs qui utilisent encore des…
IETF
Le transform a été accepté. Le rejeu n’avait pas encore été rejeté : RFC 9827
En élargissant le Transform Type 5 d’IKEv2, la RFC 9827 remplace une étiquette trop étroite par un contrat vérifiable sur les numéros de séquence à l’entrée du réseau. Ce contrat ne dit pas si le récepteur a activé l’anti-rejeu, ce qu’il a effectivement reçu, ni si un mécanisme…
IETF
La ligne de journal est lisible. L’autorité sur la connexion ne l’est pas : RFC 9850
RFC 9850 donne aux outils de diagnostic une grammaire commune pour les secrets TLS. Cette lisibilité technique ne dit ni qui pouvait ouvrir la connexion à l’observation, ni quand ce pouvoir a réellement pris fin.
IETF
Le Vérificateur s’est abonné, pas la décision
Un projet de l’IETF transforme l’attestation des équipements en flux d’événements. Il rapproche la mesure de l’observation, sans abolir les frontières entre preuve reçue, évaluation, autorisation et résultat.
IETF
Une entropie nouvelle entre dans la session ; la reprise reste à prouver dans les deux sens
Le KeyUpdate ordinaire de TLS 1.3 prolonge une chaîne de secrets déjà établie. Le projet Extended Key Update propose de refaire un échange de clés dans une session vivante et d'injecter un secret partagé neuf. Cette opération ouvre une possibilité de reprise après compromission…
Dossier
Le jeu de paramètres se vérifie. Pas l’état de signature : RFC 9858
RFC 9858 enrichit HSS/LMS de nouveaux choix de hachage et de niveau de sécurité. Il ne résout pas la difficulté propre aux signatures avec état: démontrer qu’une feuille à usage unique n’a été consommée qu’une seule fois, y compris après une panne, une restauration ou deux…
Tendances mondiales des services cloud
Certificats IP : les 99,21 % de Let’s Encrypt ne mesurent pas le parc déployé
Une étude publiée sur Pulse révèle une forte concentration des émissions. Son analyse détaillée distingue pourtant les certificats produits des services effectivement observés.
Tendances mondiales des services cloud
Chez Cloudflare, l'ancienne API post-quantique subsiste sans modifier le réglage
Le choix automatique et la liste des algorithmes autorisés relèvent désormais de commandes distinctes. Les procédures de retour arrière doivent suivre cette séparation.
Entreprises télécoms nationaux Asie-Pacifique
TESS et Docomo testent la sécurité du suivi de centrales solaires
Le pilote permet à TESS de bloquer à distance le trafic suspect d’une SIM et teste la continuité du suivi des centrales solaires lors d’une coupure de connexion.
Tendances institutionnels Europe et Moyen-Orient
ENISA confirme la déclaration manuelle de la CRA au lancement
ENISA lance sa plate-forme de la CRA le 11 septembre sans API, donc les fabricants devront encore soumettre via l’interface les signalements obligatoires.
IETF
Le client peut régler son CDN sans disposer du signal qui protège le suivant
Une transformation d’en-tête paraît locale tant que l’on ne regarde que l’interface où elle est configurée. CDN-Loop révèle une autre frontière: préserver une indication utile à un tiers ne revient pas à garantir la véracité de son contenu.
IETF
Déplacer le portail peut changer le terminal qu’il reconnaît
Une API hébergée plus loin dans le réseau ne voit pas nécessairement les mêmes identifiants que l’équipement qui autorise les paquets. La cohérence d’une session dépend de cette correspondance, mais aussi du moment où elle prend fin.