10. Considérations de Sécurité
10.1. Autorité du Serveur
HTTP/2 s'appuie sur la définition HTTP/1.1 de l'autorité pour déterminer si un serveur est autorisé à fournir une réponse donnée (voir Section 17.1 de [HTTP]). Cela repose sur la résolution de noms locale pour le schéma "https" et l'identité de serveur authentifiée pour le schéma "https" (tel que défini dans la Section 4.2.2 de [HTTP]). Les services alternatifs ([ALT-SVC]) utilisés pour établir l'autorité pourraient introduire une complexité supplémentaire considérable.
10.2. Attaques Inter-Protocoles
Dans TLS, HTTP/2 utilise l'extension Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN] pour négocier l'utilisation du protocole. Cela crée un signal positif que le serveur prend en charge HTTP/2 et réduit l'exposition de HTTP/2 aux attaques inter-protocoles.
Cependant, en texte clair ou lorsque ALPN n'est pas utilisé dans TLS, le préfixe de connexion client HTTP/2 (Section 3.4) pourrait être confondu avec d'autres protocoles. Le préfixe de connexion HTTP/2 est conçu pour minimiser cette possibilité en sélectionnant une séquence qui est peu susceptible d'être un début valide pour d'autres protocoles.
Tout protocole accessible à un point de terminaison HTTP/2 peut être utilisé pour établir ce qui semble être une connexion HTTP/2 valide. Pour cette raison, le préfixe de connexion reçu par un point de terminaison côté serveur doit être valide pour que le protocole forme une attaque inter-protocoles.
Le préfixe de connexion client (Section 3.4) n'est pas suffisant pour garantir que le protocole n'est pas confondu, mais il fournit une certaine protection. Les implémentations de clients HTTP/2 pourraient également devoir effectuer des vérifications supplémentaires avant d'appliquer la sémantique HTTP. En particulier, les clients doivent s'assurer que la réponse initiale est une réponse légitime à un message que le client a envoyé.
Un serveur pourrait attaquer un client en envoyant une requête à un serveur cible que le client voulait envoyer à un serveur différent. Si le serveur récepteur prend en charge un schéma HTTP autre que HTTP/2, le serveur peut lire et répéter une requête envoyée à un autre serveur. Un attaquant peut intercepter et modifier la réponse que le client reçoit, ce qui amène le client à associer des informations dans la réponse à une réponse à une requête à laquelle elle n'appartient pas.
10.3. Attaques d'Encapsulation d'Intermédiaire
L'encodage de champ HTTP/2 permet l'expression de noms et valeurs de champs qui ne sont pas des noms et valeurs de champs valides dans HTTP/1.1 ou qui ne peuvent pas être exprimés dans HTTP/1.1. Les requêtes ou réponses contenant des noms ou valeurs de champs invalides rendent vulnérables les implémentations qui effectuent une validation insuffisante des noms et valeurs de champs. Un attaquant pourrait être en mesure d'utiliser un intermédiaire pour encapsuler une requête ou une réponse de sorte qu'un message invalide apparaisse valide.
Un traducteur HTTP/2 vers HTTP/1.1 qui ne valide pas entièrement les requêtes et les réponses pourrait permettre à un client malveillant de faire passer des valeurs de champs en contrebande ou de créer des champs avec des noms de champs trompeurs.
10.4. Mise en Cache des Réponses Poussées
Les réponses poussées n'ont pas de requête explicite d'un client; la requête est fournie par le serveur dans une trame PUSH_PROMISE.
La mise en cache des réponses poussées peut être problématique. En fonction des informations utilisées pour établir la connexion, une réponse poussée pourrait être rendue disponible par inadvertance à un nouveau client qui partage la connexion mais a demandé la ressource de manière involontaire.
Par exemple, dans le cas de l'utilisation de TLS pour l'authentification, un client malveillant pourrait recevoir une réponse poussée concernant des informations sensibles d'un utilisateur authentifié utilisant la même connexion.
Les serveurs NE DOIVENT inclure que des valeurs qui sont mises en cache dans les requêtes qui sont poussées (voir Section 9.2.3 de [HTTP]); les requêtes poussées n'incluent pas de valeurs pour le contenu de la requête. Les réponses poussées sont marquées comme non mises en cache en incluant un champ d'en-tête Cache-Control contenant la directive de réponse de cache no-cache ou private (voir Section 5.2.2.4 de [HTTP-CACHING]).
Si la même réponse poussée peut être fournie pour des réponses qui sont à la fois mises en cache et non mises en cache, les clients pourraient mettre en cache incorrectement la réponse poussée en utilisant la réponse mise en cache.
Par conséquent, les serveurs DEVRAIENT inclure un champ d'en-tête Cache-Control avec une valeur de "no-cache" dans la trame HEADERS d'un flux poussé, à moins qu'il n'y ait un signal explicite indiquant que le client met en cache la réponse.
10.5. Considérations sur le Déni de Service
L'utilisation de HTTP/2 introduit plusieurs nouvelles opportunités de déni de service (DoS).
10.5.1. Limites sur la Taille de Section de Champ
Une section de champ contenant un grand nombre de champs ou de longs noms ou valeurs de champs peut amener une implémentation à consommer des quantités excessives de mémoire, de temps CPU, ou les deux.
Les implémentations DEVRAIENT imposer des limites sur le nombre total et la taille des lignes de champs qu'elles accepteront et le nombre total et la taille qu'elles enverront, limitant ainsi la taille totale des trames qui composent une section de champ. Les serveurs pourraient souhaiter maintenir une liste blanche de lignes de champs, et les clients pourraient vouloir rejeter des lignes de champs, mais les deux DEVRAIENT consigner et prendre en compte les limites qui pourraient entraver l'interopérabilité.
10.5.2. Problèmes CONNECT
La méthode CONNECT peut être utilisée pour créer une connexion vers des destinations non fiables. La connexion TCP pour CONNECT n'est pas soumise à contrôle, et elle pourrait tenter de se connecter à des points de terminaison ou à d'autres appareils, créant une inondation de connexions. Les implémentations DEVRAIENT définir des limites sur les destinations qui sont autorisées comme cibles CONNECT, et DEVRAIENT consigner ces limites.
10.5.3. Utilisation de la Compression
La compression des blocs de champs dans HTTP/2 repose sur des algorithmes et un état qui peuvent être utilisés par un attaquant pour provoquer un déni de service.
Un attaquant peut envoyer des requêtes avec des champs soigneusement élaborés pour créer une section de champ qui nécessite de grandes quantités de ressources de décodeur. Cela peut être fait en utilisant de grandes quantités de chaînes encodées Huffman ou en effectuant de nombreuses mises à jour de la table dynamique. Démarrer immédiatement une nouvelle section de champ après avoir terminé une (par exemple, des trames DATA vides suivies d'une trame HEADERS) pourrait également être utilisé pour limiter les ressources de décodeur disponibles.
Des attaques similaires peuvent être envoyées pour utiliser agressivement l'état de compression de section de champ pour créer des réponses qui nécessitent de grandes quantités de ressources d'encodeur.
Les implémentations DEVRAIENT définir des limites sur la taille des champs qu'elles décompressent.
10.5.4. Utilisation du Contrôle de Flux
Le contrôle de flux dans HTTP/2 permet à un adversaire de limiter la quantité de données qu'un pair peut envoyer. L'implémentation des mises à jour de fenêtre ou de la gestion de fenêtre de contrôle de flux pourrait empêcher les flux d'obtenir une fenêtre disponible, rendant le flux incapable de progresser.
10.5.5. Utilisation des Paramètres
Une trame SETTINGS peut être utilisée pour amener un pair à dépenser du temps de traitement supplémentaire. Cela peut être fait en changeant inutilement les paramètres, en envoyant des trames SETTINGS sans changer aucun paramètre, ou en changeant fréquemment les paramètres.
D'autres paramètres SETTINGS qui limitent les valeurs pourraient être utilisés pour consommer des ressources, comme désactiver la table dynamique HPACK en définissant une très petite valeur pour le paramètre SETTINGS_HEADER_TABLE_SIZE.
Les points de terminaison DEVRAIENT détecter ces comportements et les traiter comme une erreur de connexion (Section 5.4.1) de type ENHANCE_YOUR_CALM.
10.5.6. Utilisation des Priorités
Les priorités peuvent être utilisées pour amener un pair à dépenser des ressources excessives. Les changements fréquents de l'arbre de priorité ou une complexité déraisonnable dans les arbres de priorité peuvent tous deux entraîner une consommation excessive de CPU.
10.5.7. Utilisation de HTTP/2 sans TLS
HTTP/2 peut être déployé sans utiliser TLS. Ce mode présente les mêmes vulnérabilités à certaines attaques que HTTP/1.1. Les implémentations qui utilisent ce mode de fonctionnement DEVRAIENT appliquer des protections applicables à HTTP/1.1.
Les implémentations doivent également être conscientes que de nombreuses fonctionnalités HTTP/2 pourraient être plus vulnérables aux attaques sans TLS. En particulier, l'absence de protection de confidentialité et de protection d'intégrité fournie par TLS signifie que le chiffrement ou l'intégrité des données est à risque.
10.6. Utilisation de la Compression
La compression peut permettre à un attaquant de récupérer le contenu secret d'une communication chiffrée lorsque cette compression est combinée avec des données contrôlées par un attaquant et des données secrètes dont l'attaquant peut observer la taille de transmission.
HTTP/2 fournit une compression à plusieurs endroits: les blocs de champs utilisent HPACK [COMPRESSION], et le contenu des trames DATA peut utiliser l'encodage de contenu (voir Section 8.4.1 de [HTTP]).
HPACK est conçu pour rendre l'exploitation de la divulgation de secrets plus difficile; cependant, le compromis entre les choix d'implémentation ou les protections d'application qui peuvent être réalisés dans certains cas est imparfait. Les attaques peuvent exploiter la réutilisation de l'état de compression de champ à travers plusieurs requêtes. Les implémentations et les applications peuvent choisir de limiter la quantité d'état de compression utilisé à travers les requêtes pour améliorer la protection, mais au prix d'une augmentation de la taille des messages.
La compression du contenu des trames DATA est généralement considérée comme plus sûre car le contenu des trames DATA est moins susceptible d'être mélangé avec des données contrôlées par l'attaquant à travers plusieurs requêtes. Cependant, l'encodage de contenu de compression combine des informations de différentes origines. Bien que l'utilisation d'un identifiant d'origine différent distingue les informations de différentes sources (voir Section 11.5 de [HTTP]), la compression peut supprimer ces séparateurs, comme décrit dans [BREACH].
La désactivation ou la limitation de la compression pour l'encodage de contenu est généralement considérée comme suffisante pour atténuer ces attaques, mais cela pourrait ne pas être adéquat pour prévenir toutes les attaques.
10.7. Utilisation du Rembourrage
Le rembourrage peut être utilisé pour obscurcir la taille exacte du contenu des trames et des messages. Le rembourrage peut être utilisé pour atténuer les attaques qui reposent sur l'utilisation de l'analyse du trafic pour déduire des informations sur les messages, ce qui est d'une importance particulière pour HTTP, où la longueur des messages compressés pourrait révéler des informations sur le contenu qu'ils contiennent.
Un exemple d'utilisation du rembourrage serait d'envoyer un grand nombre de trames HEADERS et DATA avec des tailles de charge utile qui varient entre les trames pour obscurcir la taille exacte d'un message. L'utilisation du rembourrage peut réduire certaines attaques (par exemple, [BREACH]).
En général, l'existence d'attaques d'analyse du trafic signifie que le rembourrage à une taille fixe pour chaque champ ou trame est insuffisant pour fournir une protection. Pour être efficace et fournir un certain niveau de protection, le rembourrage DEVRAIT être choisi au hasard.
Le rembourrage n'est pas une protection parfaite pour obscurcir la taille des messages. Un attaquant pourrait être en mesure d'utiliser des propriétés statistiques sur la taille des messages, ce qui pourrait permettre à un attaquant d'utiliser la longueur des messages, qu'ils soient rembourrés ou non, pour déduire des informations sur le contenu avec une certaine probabilité.
10.8. Considérations de Confidentialité
Plusieurs caractéristiques de HTTP/2 offrent à un observateur l'opportunité de corréler un ensemble de requêtes. Celles-ci incluent la valeur des paramètres, le contexte de compression pour les blocs de champs, la gestion de la fenêtre de contrôle de flux, et le timing des messages arrivant.
En particulier, les champs HTTP contenant des informations sur l'identité de l'utilisateur peuvent être corrélés avec d'autres communications, même lors de l'utilisation de serveurs différents.
HTTP/2 ne fournit pas de mécanismes spécifiques pour protéger la confidentialité des utilisateurs.
Chapitre 10 terminé!
Références
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"