Résumé

  • Rapid Reset créait une requête HTTP/2 puis l’annulait aussitôt : le compteur de concurrence libérait la place alors que le proxy ou le service aval pouvait encore travailler.
  • La réponse durable consiste à juger l’utilité et le coût sur toute la connexion, à interrompre tôt les connexions abusives et à préserver l’annulation légitime des clients ordinaires.

Fermé dans le protocole, vivant dans la machine

HTTP/2 multiplexe plusieurs échanges sur une même connexion. Cette organisation évite de répéter TCP et TLS pour chaque ressource d’une page. Le serveur peut annoncer SETTINGS_MAX_CONCURRENT_STREAMS, c’est-à-dire le nombre de flux que son pair peut maintenir ouverts simultanément.

Le compteur ne retient que les états ouverts ou semi-fermés. Dès qu’un RST_STREAM ferme le flux, celui-ci sort du quota. Ce comportement répond à un besoin normal : l’utilisateur change de page, une application atteint son délai ou une ressource n’est plus utile. L’annulation doit rester locale au flux.

Rapid Reset a exploité le décalage entre cette fermeture logique et l’effacement du coût. L’attaquant envoyait les HEADERS d’une requête, puis son reset immédiat. Le flux disparaissait de la comptabilité et la même connexion obtenait sans attendre une nouvelle place.

Le serveur, lui, avait parfois déjà créé une structure, décompressé les en-têtes, chargé la politique d’un client, choisi une route ou transmis la demande à un service. Le proxy pouvait recevoir l’annulation alors qu’un travail aval demeurait en file ou en cours. Le client dépensait quelques octets ; l’autre côté payait l’ouverture, l’aiguillage, la notification et la destruction.

L’attaque n’a ni cassé TLS, ni fabriqué de réponse, ni dépassé en permanence le nombre de flux simultanés annoncé. Elle réutilisait très vite une place formellement libérée. Google a ainsi expliqué que le débit n’était plus principalement limité par l’aller-retour réseau, mais par la bande passante disponible.

Trois observations, pas un chiffre universel

Google, Cloudflare et AWS ont détecté la campagne à la fin d’août 2023, puis coordonné l’information des implémentations HTTP/2. La divulgation publique du 10 octobre a donné à la vulnérabilité l’identifiant CVE-2023-44487.

Google a publié un pic supérieur à 398 millions de requêtes par seconde. Cloudflare a décrit un autre pic, légèrement supérieur à 201 millions, produit par environ 20 000 machines. AWS a mesuré sur CloudFront plus de 155 millions de requêtes par seconde les 28 et 29 août.

Ces nombres ne se cumulent pas. Ils proviennent de réseaux, de clients et d’instruments différents. Ils prouvent la puissance du mécanisme, non la capacité minimale que devrait posséder tout serveur.

Google a indiqué que son plus grand épisode avait été bloqué à la périphérie sans panne. Cloudflare a reconnu un impact initial proche de 1 % des requêtes, avec de brefs sommets autour de 12 % dans les centres les plus touchés. L’écart renseigne sur les architectures et sur l’emplacement du contrôle ; il ne crée pas une contradiction factuelle.

Le compteur mesurait le mauvais objet

La concurrence protège un stock instantané. Rapid Reset produisait un flux de travail séquentiel extrêmement rapide. Une requête pouvait entrer, être débitée du quota, être annulée puis disparaître de ce compte, tandis que ses effets persistaient ailleurs.

Abaisser le seul nombre de flux simultanés ne suffisait donc pas. Cloudflare l’a ramené à 64, avant de constater que de nombreux clients légitimes lançaient jusqu’à 100 flux sans attendre les SETTINGS du serveur. Les 36 flux supplémentaires étaient refusés. Une ancienne protection comptait ces resets émis par le serveur comme un indice d’abus et fermait la connexion, provoquant l’échec complet de certaines pages. Cloudflare est revenu à 100.

Cette correction de la correction est une preuve importante. Une limite peut être défendable sur le papier et dangereuse face aux logiciels déjà déployés. La bonne valeur n’est pas la plus basse ; c’est une valeur testée qui arrête l’amplification avant la saturation tout en conservant le comportement normal.

La connexion porte le jugement final

Google a recommandé de ne pas bloquer seulement des requêtes isolées. Le serveur doit lire l’histoire de la connexion : rythme d’ouverture, part des annulations, travail utile obtenu, dépassements répétés. Face à un schéma abusif, il peut envoyer un GOAWAY immédiatement contraignant ou fermer le transport.

Le client garde ainsi son droit de renoncer à une réponse. Il ne garde pas un droit inconditionnel à la relation lorsqu’il transforme l’annulation en travail sans plafond. L’admission de la connexion et le budget de la machine appartiennent au récepteur.

Cloudflare a étendu ses protections aux resets envoyés par le client, amélioré le traitement des trames, la propagation de l’annulation, les files et l’ordonnancement, puis déplacé la détection vers le proxy TLS. Il a aussi renforcé la journalisation au niveau de la connexion : certaines erreurs 502 apparaissaient avant le proxy qui produisait les statistiques habituelles et restaient donc absentes des tableaux clients.

Les fournisseurs n’ont pas besoin du même seuil. Google a insisté sur les statistiques de connexion et sa fermeture. Cloudflare a combiné détection et réorganisation de la chaîne. AWS a mobilisé sa capacité de bord et ses protections automatiques. Le principe commun est un coût borné par le système qui le supporte.

La norme décrivait l’état, pas la dette

Le RFC 9113 définit le multiplexage, le quota concurrent, RST_STREAM et GOAWAY. Cette précision rend les implémentations compatibles. Elle établit aussi qu’un flux réinitialisé est fermé et ne compte plus.

Elle ne peut cependant effacer rétroactivement le travail déjà transmis. Un Internet-Draft individuel de 2023 a décrit cette lacune et proposé un crédit cumulatif de flux. Le document éclaire le problème, mais n’est ni une norme adoptée ni un consensus de l’IETF.

Le principe de spécification initiale minimale de Heng Lu aide à répartir les rôles. Le socle commun définit les trames et conserve une annulation utile. La décision de ressources appartient d’abord au point d’exécution qui paie. Plusieurs implémentations peuvent démontrer des budgets viables dans le code en service avant qu’une pratique éprouvée n’alimente éventuellement la norme.

Ce qu’un inventaire doit démontrer

« HTTP/2 actif » n’est pas une analyse d’exposition. « CVE corrigée » ne prouve pas que le service résistera. Il faut identifier chaque terminaison — CDN, répartiteur, ingress, maillage de services, proxy inverse, serveur applicatif — et le premier composant qui engage un coût important.

Le dossier de preuve mentionne versions, provenance des correctifs, propagation réelle de l’annulation, files partagées et propriétaire du budget. Un test crédible mélange pages ordinaires, annulations légitimes et séquences hostiles d’ouverture-reset. Les requêtes normales doivent avancer, la connexion abusive doit finir et la télémétrie doit expliquer pourquoi.

Désactiver HTTP/2 peut contenir provisoirement le risque si aucune mise à jour sûre n’existe. Cette exception exige un responsable, un périmètre, une date d’expiration et une preuve de retour. Sinon, l’urgence masque l’absence de réparation.

Limites des preuves

Les sources ne donnent ni tous les objectifs, ni toutes les implémentations, ni toutes les pertes. Les pics des fournisseurs ne sont pas des bancs d’essai comparables. L’absorption par un grand bord n’annonce pas le résultat d’un serveur isolé ; la publication d’un correctif ne prouve pas son déploiement chez chaque distributeur.

La conclusion établie est plus étroite : fermer un objet protocolaire ne restitue pas nécessairement les ressources qu’il a engagées. Celui qui accepte le travail doit pouvoir mettre fin à la relation lorsque la conformité formelle devient un abus de ressources.

Sources