Alors que l'industrie digérait encore la leçon de HTTP/2 Rapid Reset, la prochaine guerre au niveau protocole avait déjà commencé. HTTP/3 sur QUIC (RFC 9000, standardisé en 2021) est désormais dominant – chez Cloudflare, Google et Meta, QUIC dépasse la moitié du trafic. Mais QUIC remplace TCP par UDP et, en échange de gains de performance, rouvre une toute nouvelle surface d'attaque DDoS. Du point de vue du défenseur, voici pourquoi QUIC rend la défense L7 plus difficile.

1. Pourquoi QUIC change les règles

Les choix de conception de base de QUIC déterminent ses propriétés de sécurité :

  • Basé sur UDP : contourne les hypothèses pare-feu/NAT/IDS sur TCP et hérite de la nature sans connexion d'UDP (voir l'article sur la réflexion).
  • chiffré par défaut : le paquet de handshake (Initial) est chiffré ; les middleboxes ne peuvent plus inspecter les drapeaux comme avec TCP – le filtrage par caractéristiques en clair casse.
  • implémentation en espace utilisateur : QUIC tourne souvent en espace utilisateur (nginx/quiche, envoy) ; chaque paquet paie une cryptographie coûteuse au lieu de la pile TCP du noyau.

2. Asymétrie du coût cryptographique : un Rapid Reset version QUIC ?

L'essence de Rapid Reset était l'asymétrie de calcul « l'attaquant paie peu, le serveur paie énormément ». Le handshake de QUIC a un levier similaire :

Chaque paquet QUIC Initial force le serveur à dériver une clé, déchiffrer et allouer un état. Un attaquant qui envoie beaucoup de handshakes spoofés/vides épuise le CPU du serveur avant qu'une connexion significative ne soit établie.

C'est exactement pourquoi RFC 9000 exige que le serveur transporte un Token dans le paquet Retry – « prouve d'abord que tu es réel » pour bloquer les flots de handshake à source spoofée. Mais ce mécanisme de Token introduit lui-même un nouveau coût de bord que les défenseurs doivent implémenter correctement.

3. Amplification QUIC : petite requête, grande réponse

Des recherches de NCC Group et Cloudflare (2022–2023) ont montré que la première réponse d'un serveur QUIC (Retry ou Handshake) peut être plus grande que l'Initial du client, produisant un facteur d'amplification d'environ 3–5×. Très loin des 51k× de Memcached, mais combiné au spoofing de source, exerce tout de même une pression sur les serveurs et réflecteurs. RFC 9000 exige des tokens Retry pour supprimer l'amplification, mais les serveurs incomplets restent un risque.

4. Le rejeu 0-RTT : l'arme sous-estimée

Le 0-RTT de QUIC permet à un client d'envoyer des données avant la fin du handshake (latence plus basse). Mais les données 0-RTT peuvent être rejouées – un attaquant capture un paquet 0-RTT et le rejoue à répétition, lançant un DDoS d'amplification + rejeu contre l'origin/l'app sans établir de connexions. Les défenseurs doivent rendre 0-RTT idempotent/à usage unique et le restreindre aux méthodes sûres (GET).

5. Migration de connexion et abus de CID

La migration de connexion de QUIC (reprise via Connection ID entre réseaux) et le reset sans état sont des commodités et une surface d'attaque :

  • prédiction/compétition CID : une génération prévisible de CID permet aux attaquants de forger des paquets de reset pour abattre des masses de connexions.
  • abus de migration : déclencher à répétition la migration force le serveur à reconstruire l'état, brûlant des ressources.
  • inondation de négociation de version : envoyer beaucoup de paquets de version inconnue force le traitement de négociation de version côté serveur.

6. Checklist de survie QUIC pour les défenseurs

  • Protection de bord compatible QUIC : ne pas s'appuyer sur les fonctionnalités TCP ; limitation de débit au niveau UDP/QUIC – limites par connexion, plafonds de fréquence de handshake, validation stricte des tokens Retry.
  • Contenir l'asymétrie du coût crypto : abandon précoce des paquets Initial sans token valide ; la crypto du handshake à la périphérie, pas à l'origin.
  • Contraindre 0-RTT : n'autoriser que les méthodes idempotentes, activer la protection contre le rejeu (nonce/token à usage unique).
  • Surveiller les métriques de protocole : suivre « handshakes incomplets / connexions établies », fréquence Retry, ratio 0-RTT – ce sont les signaux précoces d'attaque QUIC.
  • Même leçon que Rapid Reset : une architecture qui repère les anomalies au niveau frame et mitige en quelques secondes est la vraie barrière à l'ère QUIC.

Conclusion

QUIC/HTTP3 n'est pas « plus sûr » – il déplace la frontière de sécurité du cœur du réseau vers la périphérie du protocole. Il supprime la visibilité en clair tout en amplifiant le coût cryptographique – un défi structurel pour le filtrage au niveau paquet. Leçon un de Rapid Reset : les attaquants traquent l'asymétrie de coût de chaque nouveau protocole. À l'ère QUIC, les défenseurs doivent posséder la détection au niveau frame et la mitigation automatique à la périphérie du protocole, sinon le prochain « 398 M rps » passera peut-être sur UDP.