10. Security Considerations (Considérations de Sécurité)
10.1. Server Authority (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é peuvent introduire une complexité supplémentaire considérable.
10.2. Cross-Protocol Attacks (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 indiquant 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, la préface de connexion client HTTP/2 (Section 3.4) pourrait être confondue avec d'autres protocoles. La préface de connexion HTTP/2 est conçue 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, la préface de connexion reçue par un point de terminaison côté serveur doit être valide pour que le protocole forme une attaque inter-protocoles.
La préface de connexion client (Section 3.4) n'est pas suffisante pour garantir que le protocole n'est pas confondu, mais elle fournit une certaine protection. Les implémentations de clients HTTP/2 peuvent également avoir besoin d'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 renvoyer en écho une requête envoyée à un autre serveur. Un attaquant peut intercepter et modifier la réponse que le client reçoit, amenant le client à associer des informations dans la réponse avec une réponse à une requête à laquelle elle n'appartient pas.
10.3. Intermediary Encapsulation Attacks (Attaques d'Encapsulation par Intermédiaire)
L'encodage de champ HTTP/2 permet l'expression de noms de champs et de valeurs qui ne sont pas des noms de champs et des valeurs 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 de champs ou des valeurs non valides rendent les implémentations qui effectuent une validation insuffisante sur les noms de champs et les valeurs vulnérables. 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 non valide apparaisse valide.
Un traducteur HTTP/2 vers HTTP/1.1 qui ne valide pas complètement les requêtes et les réponses pourrait permettre à un client malveillant de faire passer en contrebande des valeurs de champ ou de créer des champs avec des noms de champs trompeurs.
10.4. Cacheability of Pushed Responses (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 involontairement disponible à un nouveau client qui partage la connexion mais qui a demandé la ressource de manière non intentionnelle.
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é en utilisant la même connexion.
Les serveurs DOIVENT uniquement inclure 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 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 incorrectement mettre en cache 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é, sauf s'il y a un signal explicite indiquant que le client met en cache la réponse.
10.5. Denial-of-Service Considerations (Considérations de Déni de Service)
L'utilisation de HTTP/2 introduit plusieurs nouvelles opportunités de déni de service (DoS).
10.5.1. Limits on Field Section Size (Limites sur la Taille de la Section de Champ)
Une section de champ contenant un grand nombre de champs ou de longs noms de champs ou valeurs 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 champ 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 peuvent souhaiter maintenir une liste blanche de lignes de champ, et les clients peuvent vouloir rejeter des lignes de champ, mais les deux DEVRAIENT enregistrer et prendre en compte les limites qui pourraient entraver l'interopérabilité.
10.5.2. CONNECT Issues (Problèmes CONNECT)
La méthode CONNECT peut être utilisée pour créer une connexion pour 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 autorisées comme cibles CONNECT, et DEVRAIENT enregistrer ces limites.
10.5.3. Use of Compression (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. Commencer 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 afin de 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. Use of Flow Control (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 la gestion de la 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. Use of Settings (Utilisation des Paramètres)
Une trame SETTINGS peut être utilisée pour amener un pair à dépenser du temps de traitement supplémentaire. Cela pourrait ê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 valeur très petite 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. Use of Priorities (Utilisation des Priorités)
Les priorités peuvent être utilisées pour amener un pair à dépenser des ressources excessives. Des changements fréquents de l'arbre de priorité ou une complexité déraisonnable des arbres de priorité peuvent tous deux entraîner une consommation excessive de CPU.
10.5.7. Use of HTTP/2 Without TLS (Utilisation de HTTP/2 sans TLS)
HTTP/2 peut être déployé sans utiliser TLS. Ce mode a les mêmes vulnérabilités à certaines attaques que HTTP/1.1. Les implémentations qui utilisent ce mode de fonctionnement DEVRAIENT appliquer les protections applicables à HTTP/1.1.
Les implémentations doivent également être conscientes que de nombreuses fonctionnalités HTTP/2 peuvent être plus vulnérables aux attaques sans TLS. En particulier, l'absence de protection de la confidentialité et de protection de l'intégrité fournie par TLS signifie que le chiffrement ou l'intégrité des données est en danger.
10.6. Use of Compression (Utilisation de la Compression)
La compression peut permettre à un attaquant de récupérer le contenu secret de communications cryptées 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 la compression à plusieurs endroits : les blocs de champs utilisent HPACK [COMPRESSION], et le contenu des trames DATA peut utiliser le codage de contenu (voir Section 8.4.1 de [HTTP]).
HPACK est conçu pour rendre plus difficile l'exploitation de la divulgation de secrets ; cependant, le compromis entre les choix d'implémentation ou les protections d'application qui peuvent être réalisées dans certains cas est imparfait. Les attaques peuvent exploiter la réutilisation de l'état de compression de champ sur plusieurs requêtes. Les implémentations et les applications peuvent choisir de limiter la quantité d'état de compression utilisée sur les requêtes pour améliorer la protection, mais au détriment de l'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 sur plusieurs requêtes. Cependant, le codage 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 le codage de contenu est généralement considérée comme suffisante pour atténuer ces attaques, mais cela peut ne pas être adéquat pour prévenir toutes les attaques.
10.7. Use of Padding (Utilisation du Remplissage)
Le remplissage peut être utilisé pour obscurcir la taille exacte du contenu de trame et de message. Le remplissage peut être utilisé pour atténuer les attaques qui reposent sur l'utilisation de l'analyse de 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 peut révéler des informations sur le contenu qu'ils contiennent.
Un exemple d'utilisation du remplissage 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 remplissage peut réduire certaines attaques (par exemple, [BREACH]).
En général, l'existence d'attaques d'analyse de trafic signifie que le remplissage à 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 remplissage DEVRAIT être choisi aléatoirement.
Le remplissage 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. Privacy Considerations (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é !
References
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"