CDN Tsunami : quand HTTP/3 amplifie un déni de service vers l'origine

Un CDN est généralement présenté comme un bouclier placé devant le serveur d’origine. Il absorbe du trafic, termine TLS, met les contenus en cache et empêche une pointe de requêtes d’atteindre directement l’infrastructure applicative. Une étude publiée le 29 juillet 2026 montre pourtant qu’une différence de protocole entre les deux côtés de ce bouclier peut produire l’effet inverse.

Les chercheurs ont nommé CDN Tsunami deux techniques de déni de service fondées sur la traduction de HTTP/3 côté client vers HTTP/1.1 côté origine. La première, HTTP/3 Bandwidth Amplification ou HBA, transforme des en-têtes compressés en requêtes beaucoup plus volumineuses. La seconde, HTTP/3 Connection Amplification ou HCA, transforme des flux multiplexés dans une connexion QUIC en nombreuses connexions TCP vers l’origine.

Les six fournisseurs évalués se sont révélés sensibles à HBA dans le protocole expérimental : Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly et Tencent. Cinq l’étaient à HCA. Cloudflare faisait exception pour HCA parce que son edge attendait la requête complète avant d’ouvrir une connexion vers l’origine. Dans la configuration de laboratoire, le facteur maximal publié approchait 350 fois pour les CDN utilisant la table dynamique QPACK.

Cette recherche ne décrit pas une compromission de confidentialité ni une exécution de code. Aucun CVE n’a été attribué et aucune exploitation dans la nature n’est rapportée au moment de la publication. Son intérêt est architectural : elle révèle qu’une passerelle de protocoles est aussi une passerelle de ressources, et que les limites appliquées côté client ne se transmettent pas automatiquement côté serveur.

En bref

• HTTP/3 fonctionne sur QUIC et peut multiplexer de nombreux flux dans une seule connexion.
• Les CDN testés parlaient HTTP/3 au client, puis reconstruisaient des requêtes HTTP/1.1 vers l’origine.
• HBA exploite l’asymétrie entre les références QPACK compactes et les en-têtes HTTP/1.1 décompressés.
• HCA exploite l’asymétrie entre un flux HTTP/3 multiplexé et une connexion TCP d’origine ouverte trop tôt.
• Les facteurs publiés viennent d’un banc d’essai contrôlé. Ils ne constituent pas une garantie de résultat sur tous les déploiements.
• Les corrections les plus efficaces se trouvent au niveau du CDN, mais l’origine peut réduire le rayon d’impact par ses limites, ses délais, sa segmentation et son observabilité.

Le coeur du problème : deux protocoles, deux modèles de coût

#

HTTP/3 n’est pas simplement HTTP/1.1 transporté autrement. Le protocole s’appuie sur QUIC, généralement au-dessus d’UDP, et possède des mécanismes différents pour la concurrence, la compression d’en-têtes et la gestion des erreurs. Le navigateur établit une connexion QUIC avec le CDN, puis ouvre plusieurs flux logiques indépendants à l’intérieur de cette connexion.

L’origine, elle, reste souvent servie en HTTP/1.1 sur TCP. Le CDN devient donc un traducteur : il reçoit des trames HTTP/3, reconstitue une requête, décompresse ses en-têtes, puis l’émet sous une forme textuelle HTTP/1.1.

Le client paie en octets compressés et en flux multiplexés. L’origine paie en octets décompressés, en sockets TCP, en mémoire, en descripteurs de fichiers et en workers applicatifs. Tant que le CDN ne lie pas explicitement ces deux budgets, une petite dépense du premier côté peut provoquer une grande dépense du second.

Cette situation appartient à une famille classique de vulnérabilités : l’amplification sémantique. Il ne s’agit pas forcément de réfléchir du trafic vers une victime avec une adresse usurpée, comme dans une amplification DNS. Ici, un intermédiaire légitime développe une représentation compacte en une opération coûteuse.

Rappel : HTTP/3, QUIC et QPACK

#

QUIC et le multiplexage

#

Avec HTTP/1.1, plusieurs requêtes concurrentes conduisent souvent à plusieurs connexions TCP, ou à une sérialisation limitée sur une connexion. HTTP/2 et HTTP/3 introduisent des flux multiplexés : plusieurs échanges progressent en parallèle dans une même connexion logique.

QUIC intègre le transport, le chiffrement TLS 1.3 et la gestion des flux. Une perte affectant un flux ne bloque pas nécessairement les autres au niveau applicatif. Cette propriété améliore les performances, mais elle augmente aussi le nombre d’unités de travail qu’une seule connexion peut demander à une passerelle.

Le standard RFC 9114 définit HTTP/3. Il laisse aux implémentations la responsabilité d’appliquer des limites de ressources cohérentes. Une conformité protocolaire ne signifie donc pas qu’une politique de capacité est sûre.

Pourquoi QPACK existe

#

Les requêtes HTTP répètent énormément de texte : noms d’en-têtes, types de contenu, préférences linguistiques, cookies et autres métadonnées. QPACK, défini par la RFC 9204, remplace certaines chaînes par des index compacts.

Il utilise deux idées :

• une table statique contenant des noms et valeurs très courants connus des deux côtés ;
• une table dynamique alimentée pendant la connexion pour réutiliser des champs propres à la session.

Un index peut représenter un en-tête beaucoup plus long que lui. Sur le lien HTTP/3, c’est une optimisation. Lors du passage à HTTP/1.1, le CDN doit toutefois réécrire le nom, la valeur, les séparateurs et la fin de ligne. La compression disparaît avant l’origine.

Côté client HTTP/3
  HEADERS = références QPACK compactes

              traduction du CDN
                       ↓

Côté origine HTTP/1.1
  Nom-En-Tete: valeur développée\r\n
  Nom-En-Tete: valeur développée\r\n
  ...

Cette expansion est normale. Le défaut étudié apparaît lorsque le système autorise trop de répétitions ou une taille décompressée trop élevée sans imputer le coût à la connexion cliente.

HBA : l’amplification de bande passante

#

La variante HBA vise le volume envoyé du CDN vers l’origine. Un client transmet une représentation QPACK compacte. Le CDN la transforme en en-têtes HTTP/1.1 complets, répétés sur la liaison d’origine.

La table statique suffit déjà à créer une asymétrie, car de petits index peuvent devenir des chaînes répétées. La table dynamique augmente le potentiel : une valeur longue introduite une fois peut ensuite être référencée de manière compacte dans plusieurs flux. L’étude indique que seuls Alibaba, Baidu et Tencent activaient ce mécanisme dynamique dans les conditions testées.

Résultats publiés

#

Les facteurs maximaux mesurés avec la table statique étaient les suivants :

Avec la table dynamique, les chercheurs ont observé un pic proche de 350x autour de 64 flux concurrents pour les trois fournisseurs concernés. Au-delà, le facteur diminuait. Ils attribuent ce recul à une saturation CPU de l’edge, tout en précisant qu’ils ne disposaient pas de mesures directes du CPU du fournisseur. Il s’agit donc d’une interprétation plausible, pas d’un fait instrumenté.

Dans leur laboratoire, l’origine dépassait 100 Mbit/s alors que le client restait sous 500 Kbit/s pour les CDN avec table dynamique et sous 5 Mbit/s pour les autres. Le serveur d’origine était volontairement plafonné à 100 Mbit/s, et le banc attaquant à 30 Mbit/s. Les auteurs n’ont pas testé au-delà de ces bornes.

Il serait incorrect de transformer ces valeurs en promesse universelle. Le résultat dépend de la configuration HTTP/3, des limites d’en-têtes, du comportement de cache, du type de requête, de l’implémentation du CDN et de la capacité de l’origine.

HCA : l’amplification de connexions

#

La variante HCA ne cherche pas d’abord à saturer le lien. Elle vise le nombre de connexions TCP ouvertes vers l’origine.

Dans cinq services testés, l’edge ouvrait une connexion HTTP/1.1 après réception des en-têtes HTTP/3, avant d’avoir reçu l’intégralité du corps. Une seule connexion QUIC pouvait transporter plusieurs flux. Chacun déclenchait alors un travail séparé côté origine. En maintenant les corps incomplets à très faible débit, le client prolongeait la durée de vie des connexions backend.

Ce mécanisme rappelle Slowloris par son occupation lente de ressources, mais ajoute un amplificateur architectural : le CDN convertit le multiplexage côté client en éventail de connexions côté origine.

Résultats publiés

#

Le banc d’essai utilisait un serveur Apache avec un délai de 300 secondes et une limite de 256 connexions. Quatre connexions HTTP/3 comportant chacune 96 flux ont conduit à 384 connexions backend dans plusieurs scénarios. Fastly appliquait une limite plus basse et le test a utilisé davantage de connexions clientes, avec moins de flux chacune.

Sous charge, les temps de réponse d’un client légitime ont atteint entre 60 et 90 secondes chez certains fournisseurs, avec des erreurs HTTP 504, et environ 15 secondes avec des erreurs 503 dans le scénario Fastly. Tencent fermait plus rapidement la connexion côté client dans l’observation publiée.

Cloudflare n’était pas vulnérable à HCA dans ce protocole de test. Son edge attendait la réception complète de la requête avant d’ouvrir la connexion d’origine. Cette stratégie « store then forward » casse le lien temporel nécessaire à l’attaque, au prix d’une mémoire tampon et d’une latence potentiellement plus importantes pour certaines requêtes.

Deux amplifications, une même erreur de comptabilité

#

Pour HBA, la métrique manquante est la taille après décompression. Pour HCA, c’est le nombre et la durée des connexions après traduction. Une limite de taille sur la trame cliente ou un quota de connexions QUIC n’est pas suffisant si l’unité coûteuse existe après la passerelle.

Une politique robuste doit maintenir une relation bornée :

Octets origine
  <= budget décompressé
     par client

Connexions origine
  <= budget de fan-out
     par connexion HTTP/3

Rétention origine
  <= délai sans progrès utile

Le mot important est « indépendant ». Si le délai de la connexion backend est réinitialisé par quelques octets côté client, une activité minuscule peut retenir une ressource coûteuse.

Quelle est l’exposition réelle ?

#

Les chercheurs ont commencé par 151 685 sous-domaines associés aux six CDN dans le classement Tranco Top 1M. Leur sonde a identifié 42 330 sous-domaines répondant en HTTP/3 et donc classés comme potentiellement vulnérables :

Le terme « potentiellement » doit rester visible. La sonde démontre que l’edge répond en HTTP/3 et qu’il appartient au fournisseur identifié. Elle ne démontre pas qu’un serveur d’origine tiers a été attaqué ni que sa configuration reproduit le laboratoire. Les auteurs indiquent avoir limité les essais offensifs à leurs propres sites.

Il ne faut pas non plus supposer que HTTP/3 est activé par défaut partout. La documentation Cloudflare le rend disponible sur tous les plans et explique comment l’activer. La documentation CloudFront doit être consultée pour chaque distribution. L’inventaire réel de la configuration reste la première étape.

Portée et limites scientifiques

#

Une bonne lecture de recherche sépare quatre niveaux de preuve.

1. Mécanisme protocolaire

#

L’asymétrie est démontrée et cohérente avec les standards : QPACK compresse des en-têtes, HTTP/1.1 les réexprime, et le multiplexage QUIC peut être traduit en plusieurs opérations backend.

2. Implémentations testées

#

Les comportements rapportés concernent six fournisseurs, à une période et dans des configurations précises. Un CDN peut changer son edge sans modifier la configuration du client. Les mesures vieillissent donc plus vite que le principe.

3. Impact expérimental

#

Les saturations et latences ont été obtenues sur une origine contrôlée et plafonnée. Elles prouvent la possibilité d’un impact, pas une valeur fixe de capacité nécessaire pour attaquer n’importe quel site.

4. Exploitation opérationnelle

#

Au 20 août 2026, aucune exploitation dans la nature n’est rapportée et aucun identifiant CVE n’est associé. Qualifier la technique de zero-day activement exploitée serait faux. Elle mérite l’attention parce qu’elle touche un composant structurel du Web, pas parce qu’une campagne criminelle est déjà documentée.

Mesures recommandées aux fournisseurs de CDN

#

Le papier propose plusieurs contrôles. Ils doivent être combinés, car chacun couvre un budget différent.

Les nombres de la dernière colonne sont des propositions de l’étude, pas des valeurs universelles. Un fournisseur doit les calibrer avec ses protocoles, ses clients et ses charges légitimes. Par exemple, une limite d’en-têtes trop basse peut casser des applications utilisant de grands cookies ou des systèmes d’authentification fédérée.

Selon la section de divulgation responsable, Baidu et Tencent ont accusé réception et déployé des mitigations. Les quatre autres fournisseurs avaient reconnu le signalement et poursuivaient leurs discussions internes au moment de la publication. L’étude ne présente pas de nouveau test complet après déploiement de ces changements.

Ce que peut faire l’opérateur du site d’origine

#

Les corrections fondamentales sont au CDN, car le propriétaire de l’origine ne contrôle ni le décodeur QPACK ni le mapping des flux QUIC. Il peut néanmoins empêcher l’amplification de consommer toutes ses ressources.

1. Vérifier le protocole réellement servi

#

• Inventorier les zones, distributions et domaines où HTTP/3 est activé.
• Confirmer le protocole utilisé entre le CDN et l’origine.
• Identifier les services acceptant de gros en-têtes ou de longs corps de requête.
• Documenter les limites annoncées par le fournisseur et demander si des protections HBA/HCA sont actives.

Désactiver HTTP/3 peut être une mesure temporaire si le risque est confirmé et si le fournisseur ne propose aucune protection, mais ce choix entraîne une régression de performance. Il ne devrait pas être appliqué automatiquement à tous les domaines.

2. Réserver l’origine au CDN

#

Le pare-feu de l’origine ne devrait accepter que les plages ou mécanismes d’authentification du CDN. Cela n’arrête pas un flux amplifié par le CDN, mais empêche l’attaquant de contourner simultanément la couche de protection et simplifie l’attribution du trafic.

L’idéal est d’ajouter une authentification entre edge et origine : mTLS, tunnel privé ou en-tête signé vérifié avant le traitement applicatif. Un en-tête secret statique transmis en clair sur un réseau non maîtrisé n’offre pas la même garantie.

3. Limiter les ressources en plusieurs couches

#

• Taille maximale des en-têtes et du corps au reverse proxy.
• Délais de lecture sur les en-têtes et le corps.
• Nombre maximal de connexions par identité de edge, pool ou service.
• Files d’attente bornées et mécanismes de backpressure.
• Isolation des pools entre endpoints coûteux et contenus statiques.
• Réponses précoces avant allocation d’un worker applicatif.

Les timeouts doivent mesurer le progrès utile, pas seulement l’arrivée de n’importe quel octet. Une connexion qui reçoit un octet périodique mais n’achève jamais sa requête ne doit pas vivre aussi longtemps qu’un téléversement légitime qui progresse normalement.

4. Protéger les endpoints non cachables

#

HBA doit atteindre l’origine pour produire son impact. Les ressources mises en cache réduisent donc naturellement l’effet. Les routes POST, les API dynamiques, les recherches et les téléchargements sont plus intéressants à surveiller.

On peut appliquer des quotas par route, imposer une authentification précoce, séparer les uploads sur une infrastructure dédiée et limiter les en-têtes inutiles. Il faut éviter de considérer le cache comme une défense complète : les attaquants peuvent viser des requêtes légitimement non cachables, et HCA repose surtout sur le moment où le backend est ouvert.

5. Préserver une voie de contrôle

#

Les endpoints de santé, d’administration et de déploiement ne devraient pas partager exactement les mêmes pools que le trafic public. Une saturation du frontend ne doit pas empêcher l’équipe de réduire le trafic, changer une configuration ou collecter les preuves.

Détection : observer les deux côtés du CDN

#

HBA et HCA peuvent être invisibles si l’organisation ne regarde que le nombre de requêtes. Le volume de requêtes clientes peut rester modeste tandis que la consommation backend explose.

Signaux HBA

#

• Rapport élevé entre octets reçus au CDN et octets reçus à l’origine.
• Taille d’en-têtes HTTP/1.1 proche de la limite sur de nombreuses requêtes.
• Volume origine inhabituel sans augmentation proportionnelle des réponses.
• Concentration sur des routes dynamiques ou non cachables.
• Temps CPU du proxy consacré au parsing ou à la normalisation des en-têtes.

Signaux HCA

#

• Hausse des connexions ESTABLISHED ou en attente à l’origine sans hausse équivalente des clients.
• Requêtes dont les en-têtes sont complets mais dont le corps progresse extrêmement lentement.
• Épuisement des workers, du pool de sockets ou des descripteurs de fichiers.
• Augmentation simultanée des latences et des erreurs 503/504.
• Longue durée de connexion avec très peu d’octets applicatifs utiles.

Ratios utiles

#

Ratio bande passante =
  octets reçus origine
  / octets reçus edge

Fan-out connexions =
  connexions origine
  / connexions HTTP/3 client

Efficacité utile =
  octets de corps transmis
  / durée de connexion

Les valeurs normales dépendent de l’application. L’objectif est d’établir une ligne de base, puis d’alerter sur une rupture persistante, notamment lorsque plusieurs ratios se dégradent ensemble.

Plan de validation défensive et responsable

#

Il n’est pas nécessaire de reproduire l’attaque sur un service tiers. Une organisation peut évaluer son architecture dans un environnement isolé ou avec l’autorisation écrite de son fournisseur.

1. Créer une origine de test séparée, avec des plafonds de bande passante et de connexions.
2. Utiliser une distribution CDN dédiée, sans données ni utilisateurs réels.
3. Instrumenter les deux côtés : octets, tailles décompressées, connexions, mémoire, CPU et délais.
4. Envoyer des requêtes HTTP/3 légitimes aux limites documentées, sans chercher à contourner les quotas du fournisseur.
5. Vérifier qu’un budget côté client produit un budget backend borné.
6. Tester les protections contre les corps incomplets et confirmer que le service de contrôle reste disponible.
7. Partager les anomalies avec le fournisseur par son canal de sécurité avant toute publication.

Le but d’un tel test est de mesurer ses propres garanties de capacité, pas de produire un outil de saturation.

Une leçon plus large sur les passerelles modernes

#

CDN Tsunami n’est pas uniquement une histoire de HTTP/3. Les infrastructures traduisent constamment des représentations : API Gateway vers microservices, JSON vers objets, WebSocket vers files de messages, protocoles compressés vers textes, serverless vers bases de données. Chaque traduction peut amplifier quatre dimensions :

• la taille des données ;
• le nombre d’opérations ;
• la durée de rétention ;
• le niveau de privilège.

Une revue de sécurité examine souvent la validité syntaxique et l’authentification. Elle devrait aussi examiner la conservation du coût : « quelle ressource interne maximale une unité externe peut-elle provoquer ? »

Ce raisonnement permet de détecter des risques que les scanners de vulnérabilités trouvent mal. Aucun paramètre n’est nécessairement invalide. C’est la combinaison de comportements autorisés et de budgets indépendants qui devient dangereuse.

Ce qu’il faut retenir

#

CDN Tsunami montre comment un mécanisme de performance peut devenir un mécanisme d’amplification lorsqu’il traverse une frontière de protocole. QPACK réduit le coût visible côté HTTP/3, puis le CDN restitue les en-têtes complets vers HTTP/1.1. QUIC concentre plusieurs flux, puis le CDN peut les développer en nombreuses connexions TCP. Dans les deux cas, l’origine assume un coût qui n’est pas proportionnel à celui du client.

La recherche est importante, mais il faut en conserver les limites : six fournisseurs ont été évalués, les tests destructifs ont été menés sur des origines contrôlées, le maximum de 350x appartient à certaines configurations avec table dynamique, et aucune exploitation réelle n’est publiée.

Pour les fournisseurs, la réponse consiste à borner les ressources après traduction. Pour les exploitants, elle consiste à connaître leurs protocoles, limiter le coût par requête, protéger l’origine, séparer les pools critiques et comparer la télémétrie de l’edge avec celle du backend. Le CDN reste un bouclier seulement si son budget de ressources et celui de l’origine parlent la même langue.

Sources

#

• X. Wang et al., « CDN Tsunami: Exploiting HTTP/3-to-HTTP/1.1 Conversion for DoS Amplification », arXiv, 29 juillet 2026
• Version HTML complète de l’étude
• IETF, RFC 9114, « HTTP/3 »
• IETF, RFC 9204, « QPACK: Field Compression for HTTP/3 »
• The Hacker News, « CDN Tsunami Attack Abuses HTTP/3 Translation for Up to 350x DoS Amplification », 20 août 2026
• Cloudflare, documentation HTTP/3
• AWS, documentation des versions HTTP prises en charge par CloudFront