Des chercheurs en cybersécurité ont mis en lumière deux attaques par déni de service (DoS) qui exploitent un détail d’architecture des réseaux de diffusion de contenu. Leur travail, connu sous le nom de CDN Tsunami HTTP/3, montre comment certains CDN peuvent amplifier un flux de requêtes initialement faible en bande passante, jusqu’à des facteurs pouvant atteindre 350x côté serveur d’origine.
Le principe repose sur un décalage : le navigateur échange bien du trafic HTTP/3 avec le point d’entrée du CDN, mais le CDN réémet ensuite les requêtes vers le site hébergé en HTTP/1.1. Cette conversion, associée à des mécanismes de compression de l’en-tête, ouvre la porte à des variantes d’amplification mesurées dans des conditions de laboratoire.
Pourquoi l’HTTP/3 côté navigateur peut peser sur le serveur d’origine
Les attaques décrites ciblent le comportement de plusieurs grands CDN lors de la traduction entre protocoles. Concrètement, même si l’utilisateur final envoie des requêtes en HTTP/3, le CDN doit reconstituer des éléments de la requête afin de les transférer à l’origine en HTTP/1.1. Ce passage de relais crée une surface d’attaque : ce qui coûte peu de données à l’attaquant peut coûter beaucoup plus à l’infrastructure du site visé.
Les chercheurs ont évalué l’impact sur Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly et Tencent. Ils concluent que tous ne sont pas touchés de la même manière par les deux variantes : la variante “bande passante” est vulnérable sur l’ensemble des six, alors que la variante “connexion” ne l’est que sur cinq cas.
Dans le cas de Cloudflare, la variante liée aux connexions ne fonctionnerait pas dans les conditions testées, car le CDN met en tampon la requête complète avant d’ouvrir une connexion vers l’origine. Autrement dit, le mécanisme de déclenchement trop précoce observé ailleurs n’est pas reproduit.
Deux techniques : amplification par bande passante et par connexions
Les chercheurs regroupent leurs résultats sous deux noms de techniques. La première s’appuie sur l’augmentation du volume d’informations envoyées à l’origine. La seconde vise plutôt la capacité de traitement des connexions backend.
HTTP/3 Bandwidth Amplification (HBA)
La variante HBA exploite QPACK, un format de compression d’en-têtes introduit avec HTTP/3. Le point clé est la différence de support : HTTP/1.1 ne dispose pas d’un mécanisme équivalent. Dès lors, le CDN doit décompresser les en-têtes avant de les transmettre à l’origine.
Résultat : un expéditeur peut envoyer de petits index d’en-têtes (côté HTTP/3), que le CDN transforme en en-têtes “bruts” de taille nettement plus importante (côté HTTP/1.1). Les chercheurs expliquent que ce décalage de taille peut faire basculer une requête “légère” en quelque chose de lourd pour le serveur d’origine.
Dans leurs mesures, la consommation côté origine dépasse 100 Mbps en continu, tandis que la bande passante utilisée par l’attaquant reste sous 500 Kbps contre les trois fournisseurs supportant la table dynamique, et sous 5 Mbps contre les autres.
HTTP/3 Connection Amplification (HCA)
La variante HCA joue sur la gestion des connexions plutôt que sur la taille d’en-tête. L’idée : déclencher des connexions backend tôt, même si la requête HTTP/3 n’a pas encore envoyé tout son contenu.
Dans cinq des six cas testés, le CDN ouvre une connexion HTTP/1.1 vers l’origine dès la réception du cadre HEADERS (dans HTTP/3), sans attendre la partie DATA. Comme HTTP/3 multiplexe plusieurs flux sur une même connexion client, chaque flux peut provoquer des connexions backend supplémentaires.
Ensuite, en envoyant très lentement les DATA frames, l’attaquant maintient les connexions ouvertes. Le CDN continue alors de traiter la requête comme incomplète, ce qui peut saturer les limites de concurrence côté serveur d’origine.
Les expériences ont été menées avec un serveur Apache configuré avec un délai d’attente de 300 secondes et une limite de 256 connexions. Les chercheurs indiquent que, selon le fournisseur, l’attaquant peut forcer un nombre important de connexions backend via des combinaisons de flux multiplexés.
Amplitudes observées : jusqu’à 350x selon le fournisseur
Les facteurs d’amplification varient selon les CDNs, notamment en fonction du support de la table dynamique QPACK. Les chercheurs indiquent que le facteur 350x observé dans leur approche s’applique seulement à Alibaba, Baidu et Tencent.
Leurs mesures montrent que ces trois fournisseurs supportent la table dynamique QPACK, avec une valeur maximale mesurée autour de 64 flux simultanés. À ce niveau, le maximum varie selon les CDNs : il est compris, d’après les résultats, entre environ 36,41x et 51,2x pour certaines configurations sans table dynamique.
Pour donner une idée de l’ordre de grandeur, les chercheurs rapportent les maximums obtenus avec la table statique QPACK, pour les fournisseurs testés :
- Baidu : 66,06x (table dynamique supportée)
- Alibaba : 65,8x (table dynamique supportée)
- Tencent : 54,08x (table dynamique supportée)
- Amazon CloudFront : 51,2x (table dynamique non supportée)
- Cloudflare : 48,27x (table dynamique non supportée)
- Fastly : 36,41x (table dynamique non supportée)
Ils notent aussi une dynamique temporelle : l’amplification se “cale” près de 64 flux simultanés puis redescend, attribuée à des surcoûts CPU côté bord (même si l’étude ne fournit pas de mesures détaillées du CPU au niveau edge).
Enfin, les tests précisent des limites imposées par les chercheurs eux-mêmes (cap à 100 Mbps côté origine, et 30 Mbps côté attaquant). Ils mentionnent que leurs attaques devraient s’étendre à des serveurs plus capables, sans toutefois en fournir la preuve expérimentale.
Conditions requises pour être exposé
Les attaques ne reposent pas sur un code “magique” universel. Elles nécessitent un scénario précis :
- un site hébergé chez l’un des six fournisseurs étudiés ;
- HTTP/3 servi au niveau du point de présence (edge) ;
- pas de changement de configuration requis du côté du site (les auteurs indiquent qu’aucune action particulière de l’hébergeur n’est nécessaire) ;
- une conversion CDN vers HTTP/1.1 vers l’origine, créant le décalage exploité.
Les chercheurs précisent que, dans leurs analyses, HTTP/3 est activé par défaut sur certains cas (ils citent notamment Cloudflare et CloudFront), même si les documents fournisseurs diffèrent dans leur formulation. Ils comparent aussi des indications de documentation : par exemple, AWS présente HTTP/2 comme version par défaut pour de nouvelles distributions, selon leur lecture.
Pas de CVE, pas d’exploitation observée en production
À la date de publication, les chercheurs indiquent que aucun identifiant CVE n’a été attribué et qu’aucune exploitation “dans la nature” n’a été rapportée. Ils ajoutent que les mesures et preuves proviennent d’un cadre de test contrôlé.
Leur étude inclut aussi une analyse d’exposition : ils ont listé des sous-domaines issus d’un top 1M (Tranco), récupéré leurs enregistrements CNAME/NS, puis comparé aux suffixes connus de CDNs. Ils ont ensuite testé via aioquic l’accessibilité HTTP/3 au niveau edge.
Dans cet exercice, ils rapportent que 151 685 sous-domaines étaient hébergés par les six fournisseurs, et que 42 330 répondaient à une requête HTTP/3, marqués comme potentiellement vulnérables. Cependant, ce type de sondage ne prouve pas un impact sur des serveurs tiers : il montre surtout que le bord du CDN répond en HTTP/3.
Quelles mesures ont été proposées et appliquées
Les auteurs indiquent que les atténuations proposées doivent être mises en œuvre au niveau du CDN, et non côté serveur d’origine. Autrement dit, le site hébergé ne se protège pas en “rentrant” la configuration HTTP/3 : le correctif concerne la manière dont le CDN traduit HTTP/3 vers HTTP/1.1.
Parmi les mitigations évoquées dans leurs recommandations :
- limiter la taille d’une entrée de champ d’en-tête insérée dans la table dynamique QPACK (proposition : 512 octets) ;
- limiter le nombre de fois qu’une entrée dynamique peut être référencée dans un même flux (proposition : 10 max) ;
- imposer une limite à la taille maximale d’une requête HTTP/1.1 décompressée, et rejeter au-delà (proposition : 64 Ko) ;
- mettre en tampon la requête HTTP/3 complète (HEADERS et DATA) avant d’ouvrir une connexion CDN→origine ;
- limiter le nombre de connexions CDN→origine déclenchées par une seule connexion cliente HTTP/3 ;
- appliquer un timeout indépendant côté CDN, suggéré à 30 secondes sans données significatives transmises.
Selon le rapport, Baidu et Tencent ont confirmé le problème et déployé les correctifs proposés. Pour les quatre autres fournisseurs, les auteurs signalent que la divulgation a été reconnue et que les équipes discutaient encore en interne.
Le papier ne précise pas si les chercheurs ont retesté après déploiement, ni si le code d’attaque ou le cadre de mesure seront publiés.
Une attention plus large aux risques d’amplification sur les protocoles
Les chercheurs replacent leurs conclusions dans un contexte plus large. Ils comparent leurs résultats à une étude antérieure sur la conversion HTTP/2 vers HTTP/1.1 par les CDN, mentionnant des facteurs d’amplification de l’ordre de 44x avec table statique et 166x avec table dynamique.
Ils soulignent également que QPACK a déjà fait l’objet d’autres travaux de sécurité : une divulgation liée à QPACK mentionne qu’un trafic conforme mais suffisamment particulier pourrait provoquer un crash dans des serveurs basés sur XQUIC/implémentations QUIC et HTTP/3 (dans l’écosystème de Tengine Alibaba). Par ailleurs, OpenSSL aurait publié une vulnérabilité QUIC distincte, avec une correction consistant à ajouter une limite pour des connexions en attente.
Conclusion : protéger le bord, pas seulement l’origine
CDN Tsunami HTTP/3 rappelle un point crucial en sécurité applicative : l’architecture “edge + traduction” peut créer des angles morts. En transformant HTTP/3 en HTTP/1.1, certains CDN peuvent involontairement convertir des requêtes légères en charges lourdes pour le serveur d’origine, entraînant des effets DoS amplifiés.
La bonne nouvelle est que les remèdes décrits portent sur des garde-fous côté CDN : limitations de taille, contrôle de l’usage des tables QPACK, mise en tampon avant ouverture de connexions et timeouts plus stricts. En pratique, cela signifie que pour réduire le risque, il faut agir sur la chaîne de traduction elle-même.
Source: https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
