Horizon temporel
Pluriannuel
Dans la facette Horizon temporel, les analyses à horizon temporel Pluriannuel sont organisées selon la période pendant laquelle un signal devrait rester pertinent. La page aide à distinguer les changements opérationnels immédiats des évolutions à plus long cycle — gouvernance, investissements, normes et infrastructures — qui peuvent s’étendre sur plusieurs trimestres ou années. Elle relie les hypothèses de calendrier aux preuves publiques, aux acteurs concernés, au contexte de marché, à l’exposition des clients, à la pression réglementaire et à la planification des infrastructures, afin que le lecteur puisse déterminer si un développement est urgent, stratégique ou encore en attente d’éléments de confirmation. Elle explique aussi comment l’horizon temporel modifie le sens d’un signal, quelles organisations peuvent être exposées et quelles décisions d’infrastructure appellent une action à court terme ou un suivi à long terme.
Dossier
La route a choisi trois fois, le voisin n’en a entendu qu’une : MRAI et l’autorité temporelle de BGP
Un routeur BGP peut changer plusieurs fois de meilleur chemin sans livrer chaque décision à son voisin. Ce silence n’est ni une panne ni une hésitation. MRAI sépare volontairement le rythme de la sélection locale de celui de l’annonce extérieure. Il économise des UPDATE et du…
Histoire d'Internet
L’en-tête disparu entre deux paquets
La RFC 1144 fit presque disparaître quarante octets d’en-têtes sur les liaisons lentes: deux voisins gardaient le même état et n’envoyaient que l’écart.
Histoire d'Internet
La ligne qui ressemblait à la fin dans SMTP
SMTP terminait un message de longueur inconnue par une ligne réduite à un point. Le doublage la rendit réversible, puis CHUNKING compta les octets.
Dossier
Le serveur qui ne gardait rien : SYN cookies et admission sans état
Un serveur exposé ressemble d’ordinaire à un vestiaire qui ouvrirait une fiche dès qu’une personne crie un numéro depuis la rue. Le SYN cookie inverse la dépense: le serveur remet d’abord un reçu compact, puis n’ouvre la fiche que lorsque ce reçu revient dans le troisième paquet.…
Histoire d'Internet
HTTP 100 Continue : autoriser sans accepter
HTTP 100 Continue permet au serveur de refuser sur les en-têtes avant un corps volumineux, sans confondre permission de transmettre et acceptation finale.
Dossier
La clé installée deux fois : KRACK et le pouvoir d’une retransmission
Une trame perdue doit pouvoir être renvoyée. Mais une retransmission authentique ne devrait pas remettre à zéro l’histoire d’une clé déjà active. KRACK a révélé cette confusion de pouvoirs dans le fonctionnement concret de WPA2, sans découvrir le mot de passe ni la clé négociée.
Dossier
L’échec qui choisissait le chiffrement : POODLE et l’autorité cachée du repli
Un échec de négociation TLS ne disait pas pourquoi la connexion avait échoué. Pourtant, certains clients en déduisaient que le serveur exigeait un protocole plus ancien. POODLE a rendu visible ce glissement: celui qui pouvait provoquer l’échec pouvait aussi orienter la tentative…
Dossier
L’en-tête devenu programme : Shellshock et le pouvoir caché dans l’environnement
Shellshock a révélé une délégation que personne n’avait formulée: une donnée fournie par un client pouvait traverser CGI, devenir variable d’environnement, puis être relue par Bash comme du code. L’incident oblige à examiner les droits créés par la composition des interfaces, pas…
Dossier
Slammer : le correctif publié n’avait pas révoqué le code vulnérable
Six mois séparaient le premier bulletin de Microsoft de l’épidémie. Dix minutes ont suffi au ver pour atteindre l’essentiel de sa population vulnérable accessible. Entre ces deux durées se trouve une erreur de gouvernance familière: confondre la mise à disposition d’un remède…
Histoire d'Internet
Le silence qui n’était pas une panne : pourquoi TCP keepalive resta facultatif
Une connexion TCP établie peut se taire pendant des heures sans être défaillante. Keepalive permit d’interroger ce silence sans prétendre le comprendre: provoquer un ACK, recueillir un indice borné, puis laisser à l’application le choix du moment où l’incertitude devient trop…
Dossier
Cinq minutes pour déplacer une route : memcached et l’autorité sur la bande passante
À 17 h 21, le déséquilibre entre trafic entrant et sortant déclenche une alerte chez GitHub. À 17 h 26, une commande retire des annonces BGP. Entre ces deux instants, l’incident révèle surtout une chose: le trafic d’autrui ne se gouverne pas depuis un seul point.
Histoire d'Internet
Qui ouvrait trop tôt la fenêtre TCP ? Le coût d’une permission immédiate
Un destinataire TCP pouvait publier chaque octet nouvellement libéré, et l’émetteur consommer aussitôt chaque offre. Cette ouverture paraissait exacte et coopérative. Répétée, elle faisait surtout travailler la connexion pour des paquets minuscules. La réparation historique donna…
Dossier
La réponse qui a gagné la course : Kaminsky, le DNS et l’entropie derrière la confiance
Le faux paquet n’avait pas à démontrer qu’il venait de l’autorité compétente. Il devait coïncider avec une question encore ouverte et franchir la ligne d’arrivée avant la vraie réponse. En 2008, cette règle minimale est devenue une course que l’attaquant pouvait relancer à…
Dossier
La règle arrivée partout avant que son coût soit connu : la panne WAF de Cloudflare en 2019
Le 2 juillet 2019, le réseau de distribution de Cloudflare a accompli sa mission en quelques secondes; le contrôle qui le précédait avait vérifié la décision de sécurité, mais pas la quantité de calcul que cette décision pouvait exiger du monde entier.
Histoire d'Internet
La mise à jour de fenêtre qui pouvait disparaître : pourquoi TCP apprit à persister à zéro
Une imprimante manque de papier, son application cesse de lire et TCP annonce une fenêtre nulle. Plus tard, la capacité revient, mais l’ACK qui l’annonce se perd. Le mécanisme de persistance fut conçu pour sauver cette permission fragile sans donner au transport le droit de…
Histoire d'Internet
Le verdict refusé par UDP : à qui appartenait le risque du zéro ?
Dans UDP, zéro n’était pas un bon résultat. Il annonçait que l’émetteur avait retenu le verdict. Le passage d’IPv4 à IPv6 pose donc une question de responsabilité: qui peut retirer une preuve commune, et quand celui qui économise le calcul doit-il posséder le risque créé ?
Dossier
La page qui empruntait la mémoire d’un autre client : la frontière révélée par Cloudbleed
Un document mal formé déclenchait l’erreur, mais les octets divulgués pouvaient appartenir à un client sans rapport avec lui: Cloudbleed a séparé brutalement l’arrêt de la fuite et la reprise de ce qui avait déjà franchi la frontière.
Histoire d'Internet
Quand les deux extrémités appelèrent ensemble : l’ouverture simultanée de TCP n’était pas une collision
Le récit scolaire de TCP distribue les rôles avant même le premier paquet: un client appelle, un serveur écoute. Le protocole de 1981 avait prévu une scène moins ordonnée. Deux programmes pouvaient prendre l’initiative au même instant, voir leurs SYN se croiser et n’établir…
Histoire d'Internet
Le prix de la tolérance : quand l’indulgence du récepteur transforma les bogues en règles
La règle la plus célèbre de l'Internet imparfait permit d'abord à des implémentations différentes de dialoguer. Le récepteur absorbait l'ambiguïté pour que le réseau démarre. Rendue permanente, cette concession dissimula les défauts, transforma les bizarreries en obligations et…
Dossier
Le certificat valable pour le mauvais usage : Flame et l’autorité cachée dans la finalité
Flame n’a pas volé la clé privée racine de Microsoft. Le logiciel a exploité une chaîne de licences dont les choix cryptographiques, les habitudes d’émission et la confiance héritée pouvaient être recomposés en pouvoir de signer du code.