Le 10 octobre 2023, Cloudflare, Google et AWS ont dévoilé HTTP/2 Rapid Reset, identifié par CVE-2023-44487. Cette technique avait été utilisée dans d’importantes attaques par déni de service distribué. Elle a montré comment un comportement du protocole pouvait solliciter fortement un service avant le traitement normal d’une requête par l’application.
Un risque pour la disponibilité
HTTP/2 permet plusieurs échanges sur une connexion. Rapid Reset exploitait la gestion des flux et de leur annulation pour imposer une charge disproportionnée à certaines implémentations. Le risque concernait l’épuisement des ressources et l’interruption du service, plutôt qu’une faille propre à un gestionnaire de contenu.
Google et Cloudflare ont décrit des attaques observées sur leurs infrastructures. Ces rapports établissaient l’ampleur de l’incident dans le secteur, sans prouver que chaque service HTTP/2 était vulnérable ni que tous les hébergeurs avaient subi les mêmes attaques.
Examiner tout le parcours de connexion
Une connexion peut passer par un CDN, un mandataire inverse ou un répartiteur de charge avant d’atteindre le serveur d’origine. Chaque composant pertinent doit être examiné. La protection du point d’entrée public et l’état d’une origine accessible séparément sont deux questions liées, mais distinctes.
AWS recommandait aux responsables de serveurs HTTP/2 de consulter leur éditeur et d’installer les correctifs applicables. Une mise à jour d’extension de site ne met pas nécessairement à jour le serveur ou le mandataire qui traite le protocole.
Les vérifications utiles aux propriétaires de sites
Identifiez qui gère le point d’entrée public et l’origine. En hébergement géré, demandez au fournisseur quel correctif ou quelle mesure s’applique. Pour une infrastructure autogérée, incluez le serveur Web, le mandataire et les passerelles applicatives exposées dans l’examen de maintenance.
Prévoyez une récupération et vérifiez le comportement normal du site après toute modification. Les résultats de disponibilité, les erreurs et l’utilisation des ressources peuvent révéler une régression, mais doivent être interprétés ensemble. Une page lente ne prouve pas à elle seule une attaque Rapid Reset.
L’incident a également montré les limites des étiquettes de sécurité. HTTPS ne supprime pas tous les risques d’indisponibilité. Un CDN ne prouve pas que chaque accès à l’origine est protégé. Pour une intervention actuelle, suivez les indications récentes des produits concernés et confirmez les responsabilités pour chaque partie de la réponse.
Pour une entreprise qui dépend des demandes ou transactions en ligne, l’examen de disponibilité doit rendre les responsabilités plus faciles à mobiliser en cas d’interruption. Notre équipe de solutions infonuagiques peut examiner l’hébergement, identifier les services et fournisseurs concernés, puis préciser l’entretien et le suivi attribués à chacun. Le périmètre doit correspondre aux parcours essentiels et aux contraintes de l’entreprise.
Commencez par une liste simple : le site, le fournisseur du CDN ou du mandataire, s’il y en a un, et le responsable de l’origine. Les clients qui constatent un problème peuvent transmettre l’adresse, l’heure et l’erreur observée dans l’espace client. Ces faits facilitent l’examen et distinguent un incident concret d’une inquiétude suscitée par une actualité de sécurité.
