10. Considérations de sécurité (Security Considerations)
Les considérations de sécurité de HTTP/3 devraient être comparables à celles de HTTP/2 avec TLS. Toutefois, 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 d'autorité de HTTP. Les considérations de sécurité relatives à l'établissement de l'autorité sont discutées à 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 applicatif cible avant le traitement des octets de couche application. Cela donne aux points d'extrémité une forte garantie que le pair utilise le même protocole.
Cela ne garantit pas une protection contre toutes les attaques inter-protocoles. La section 21.5 de [QUIC-TRANSPORT] décrit certaines manières dont le texte clair des paquets QUIC peut être utilisé pour effectuer de la falsification de requêtes contre des points d'extrémité qui n'utilisent pas un transport authentifié.
10.3. Attaques d'encapsulation par intermédiaire (Intermediary-Encapsulation Attacks)
L'encodage des champs HTTP/3 permet d'exprimer des noms de champ qui ne sont pas valides dans la syntaxe utilisée par HTTP; voir la section 5.1 de [HTTP]. Une requête ou une réponse contenant un nom de champ invalide doit être traitée comme mal formée.
De même, HTTP/3 peut transporter des valeurs de champ invalides. Bien que la plupart des valeurs encodables ne changent pas l'analyse des champs, les retours chariot (ASCII 0x0d), les sauts de ligne (ASCII 0x0a) et les caractères nuls (ASCII 0x00) peuvent être exploités par un attaquant s'ils sont convertis littéralement.
10.4. Mise en cache des réponses poussées (Cacheability of Pushed Responses)
Les réponses poussées ne disposent pas d'une requête explicite du client; la requête est fournie par le serveur dans la trame PUSH_PROMISE.
Lorsque plusieurs locataires partagent le même serveur, celui-ci doit garantir qu'un locataire ne peut pas pousser la représentation d'une ressource pour laquelle il n'a pas d'autorisation.
10.5. Considérations de déni de service (Denial-of-Service Considerations)
Les connexions HTTP/3 peuvent nécessiter davantage de ressources que les connexions 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 détournée afin de lui imposer un temps de traitement supplémentaire.
Les points d'extrémité qui ne surveillent pas ce type de comportement s'exposent à un risque de déni de service. Les implémentations devraient suivre l'utilisation de ces fonctionnalités et imposer des limites à leur usage.
10.5.1. Limites de taille de section de champs (Limits on Field Section Size)
De grandes sections de champs (section 4.1) peuvent amener une implémentation à engager une quantité importante d'état. Un point d'extrémité peut utiliser le paramètre SETTINGS_MAX_FIELD_SECTION_SIZE (section 4.2.2) pour informer le pair de la limite susceptible d'être appliquée à la taille des sections de champs.
10.5.2. Problèmes liés à 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 de connexions TCP.
10.6. Utilisation de la compression (Use of Compression)
Lorsque des données secrètes sont compressées dans le même contexte que des données contrôlées par un attaquant, la compression peut permettre à l'attaquant de récupérer ces données secrètes. HTTP/3 active la compression des champs (section 4.2).
Les implémentations qui communiquent sur un canal sécurisé interdisent la compression de contenu contenant à la fois des données secrètes et des données contrôlées par un attaquant, sauf si des contextes de compression séparés sont utilisés pour chaque source de données.
10.7. Bourrage et analyse du trafic (Padding and Traffic Analysis)
Le bourrage peut être utilisé pour masquer la taille exacte du contenu des trames et pour atténuer certaines attaques dans HTTP.
10.8. Analyse des trames (Frame Parsing)
Plusieurs éléments de protocole contiennent des éléments de longueur imbriqués. Les implémentations doivent garantir 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 entraîne un risque d'attaque par rejeu. Les mesures d'atténuation contre le rejeu de [HTTP-REPLAY] doivent être appliquées lorsque HTTP/3 est utilisé avec 0-RTT.
10.10. Migration (Migration)
Certaines implémentations HTTP utilisent l'adresse du client pour la journalisation ou le contrôle d'accès. Comme l'adresse d'un client QUIC peut changer pendant une connexion, ces implémentations doivent récupérer activement l'adresse courante du client ou accepter explicitement que l'adresse d'origine puisse changer.
10.11. Considérations de confidentialité (Privacy Considerations)
Plusieurs caractéristiques de HTTP/3 donnent aux observateurs des occasions de corréler dans le temps les opérations d'un client ou d'un serveur donné. Ces caractéristiques incluent les valeurs des paramètres, le temps de réponse aux stimuli et le traitement de toute fonctionnalité contrôlée par des paramètres.
La préférence de HTTP/3 pour l'utilisation d'une seule connexion QUIC permet de corréler l'activité d'un utilisateur sur un site.