10. Considérations de sécurité (Security Considerations)

Les considérations de sécurité d'HTTP/3 devraient être comparables à celles d'HTTP/2 avec TLS. Cependant, de nombreuses considérations de la section 10 de [HTTP/2] s'appliquent à [QUIC-TRANSPORT] et sont discutées dans ce document.

10.1. Autorité du serveur (Server Authority)

HTTP/3 s'appuie sur la définition HTTP de l'autorité. Les considérations de sécurité relatives à l'établissement de l'autorité sont discutées dans la section 17.1 de [HTTP].

10.2. Attaques inter-protocoles (Cross-Protocol Attacks)

L'utilisation d'ALPN dans les poignées de main TLS et QUIC établit le protocole d'application cible avant que les octets de la couche application ne soient traités. Cela garantit que les points de terminaison ont de fortes assurances que les pairs utilisent le même protocole.

Cela ne garantit pas la protection contre toutes les attaques inter-protocoles. La section 21.5 de [QUIC-TRANSPORT] décrit certaines façons dont le texte en clair des paquets QUIC peut être utilisé pour effectuer une falsification de requête contre des points de terminaison qui n'utilisent pas de transports authentifiés.

10.3. Attaques d'encapsulation intermédiaire (Intermediary-Encapsulation Attacks)

L'encodage de champ HTTP/3 permet l'expression de noms qui ne sont pas des noms de champ valides dans la syntaxe utilisée par HTTP (section 5.1 de [HTTP]). Les requêtes ou réponses contenant des noms de champ invalides DOIVENT (MUST) être traitées comme mal formées.

De même, HTTP/3 peut transporter des valeurs de champ qui ne sont pas valides. Bien que la plupart des valeurs qui peuvent être encodées ne modifieront pas l'analyse des champs, le retour chariot (ASCII 0x0d), le saut de ligne (ASCII 0x0a) et le caractère nul (ASCII 0x00) pourraient être exploités par un attaquant s'ils sont traduits textuellement.

10.4. Mise en cache des réponses poussées (Cacheability of Pushed Responses)

Les réponses poussées n'ont pas de requête explicite du client ; la requête est fournie par le serveur dans la trame PUSH_PROMISE.

Lorsque plusieurs locataires partagent de l'espace sur le même serveur, ce serveur DOIT (MUST) s'assurer que les locataires ne peuvent pas pousser des représentations de ressources sur lesquelles ils n'ont pas d'autorité.

10.5. Considérations de déni de service (Denial-of-Service Considerations)

Une connexion HTTP/3 peut exiger un engagement de ressources plus important pour fonctionner qu'une connexion HTTP/1.1 ou HTTP/2.

La capacité d'envoyer des éléments de protocole non définis que le pair doit ignorer peut être abusée pour amener un pair à dépenser du temps de traitement supplémentaire.

Un point de terminaison qui ne surveille pas un tel comportement s'expose à un risque d'attaque par déni de service. Les implémentations DEVRAIENT (SHOULD) suivre l'utilisation de ces fonctionnalités et définir des limites sur leur utilisation.

10.5.1. Limites de taille de section de champ (Limits on Field Section Size)

Une grande section de champ (section 4.1) peut amener une implémentation à s'engager sur une grande quantité d'état. Un point de terminaison peut utiliser le paramètre SETTINGS_MAX_FIELD_SECTION_SIZE (section 4.2.2) pour conseiller les pairs sur les limites qui pourraient s'appliquer à la taille des sections de champ.

10.5.2. Problèmes CONNECT (CONNECT Issues)

La méthode CONNECT peut être utilisée pour créer une charge disproportionnée sur un proxy, car la création de flux est relativement peu coûteuse par rapport à la création et à la maintenance d'une connexion TCP.

10.6. Utilisation de la compression (Use of Compression)

La compression peut permettre à un attaquant de récupérer des données secrètes lorsqu'elles sont compressées dans le même contexte que les données sous contrôle de l'attaquant. HTTP/3 active la compression des champs (section 4.2).

Les implémentations communiquant sur un canal sécurisé NE DOIVENT PAS (MUST NOT) compresser du contenu qui inclut à la fois des données confidentielles et des données contrôlées par l'attaquant, sauf si des contextes de compression séparés sont utilisés pour chaque source de données.

10.7. Remplissage et analyse du trafic (Padding and Traffic Analysis)

Le remplissage peut être utilisé pour obscurcir la taille exacte du contenu de la trame et est fourni pour atténuer des attaques spécifiques dans HTTP.

10.8. Analyse des trames (Frame Parsing)

Plusieurs éléments de protocole contiennent des éléments de longueur imbriqués. Une implémentation DOIT (MUST) s'assurer que la longueur d'une trame correspond exactement à la longueur des champs qu'elle contient.

10.9. Données précoces (Early Data)

L'utilisation de 0-RTT avec HTTP/3 crée une exposition à l'attaque par rejeu. Les atténuations anti-rejeu dans [HTTP-REPLAY] DOIVENT (MUST) être appliquées lors de l'utilisation d'HTTP/3 avec 0-RTT.

10.10. Migration

Certaines implémentations HTTP utilisent l'adresse client à des fins de journalisation ou de contrôle d'accès. Étant donné que l'adresse d'un client QUIC peut changer pendant une connexion, ces implémentations devront soit récupérer activement l'adresse actuelle du client, soit accepter explicitement que l'adresse d'origine puisse changer.

10.11. Considérations de confidentialité (Privacy Considerations)

Plusieurs caractéristiques d'HTTP/3 offrent à un observateur l'opportunité de corréler les actions d'un seul client ou serveur au fil du temps. Celles-ci incluent la valeur des paramètres, le timing des réactions aux stimuli et la gestion de toutes les fonctionnalités contrôlées par les paramètres.

La préférence d'HTTP/3 pour l'utilisation d'une seule connexion QUIC permet la corrélation de l'activité d'un utilisateur sur un site.