9. HTTP/2 Connections (Connexions HTTP/2)
Les connexions HTTP/2 sont des protocoles de couche application fonctionnant au-dessus d'un transport fiable [TCP] qui utilise Transport Layer Security (TLS) [TLS13] pour protéger les données échangées sur le réseau.
HTTP/2 utilise les mêmes schémas URI "http" et "https" que HTTP/1.1. HTTP/2 partage les mêmes numéros de port par défaut : le port 80 pour les URI "http" et le port 443 pour les URI "https". En conséquence, les implémentations doivent gérer les requêtes vers les URI de ressources cibles telles que http://example.org/foo ou https://example.com/bar en découvrant d'abord si le serveur en amont (le pair immédiat auquel le client souhaite établir une connexion) prend en charge HTTP/2.
9.1. Connection Management (Gestion des Connexions)
Les connexions HTTP/2 sont persistantes. Pour obtenir les meilleures performances, il est attendu que les clients ne ferment pas les connexions tant qu'il n'est pas déterminé qu'aucune communication supplémentaire avec un serveur n'est nécessaire (par exemple, lorsqu'un utilisateur quitte une page Web particulière) ou jusqu'à ce que le serveur ferme la connexion.
Les clients NE DEVRAIENT PAS ouvrir plus d'une connexion HTTP/2 vers une paire hôte et port donnée, où l'hôte est dérivé d'un URI, d'un service alternatif sélectionné [ALT-SVC] ou d'un proxy configuré.
Un client peut créer des connexions supplémentaires en tant que remplacements, soit pour remplacer les connexions qui sont sur le point d'épuiser l'espace d'identificateur de flux disponible (Section 5.1.1), pour actualiser le matériel de clés pour une connexion TLS, ou pour remplacer les connexions qui ont rencontré des erreurs (Section 5.4.1).
Un client PEUT ouvrir plusieurs connexions vers la même cible dans le but de : créer de nouvelles connexions pour tenter des requêtes atomiques (voir Section 9.1.2), ou remplacer tout identificateur de flux supérieur à 0 qui a été reçu dans une trame GOAWAY et qui est dans l'état "actif" ou "inactif" (voir Section 6.8).
Les serveurs sont encouragés à maintenir les connexions ouvertes aussi longtemps que possible, mais sont autorisés à terminer les connexions inactives si nécessaire. Lorsque l'un ou l'autre point de terminaison choisit de fermer la connexion TCP de couche transport, le point de terminaison qui termine DEVRAIT d'abord envoyer une trame GOAWAY (Section 6.8) afin que les deux points de terminaison puissent déterminer de manière fiable si les trames précédemment envoyées ont été traitées et terminer ou achever gracieusement toutes les tâches restantes nécessaires.
9.1.1. Connection Reuse (Réutilisation des Connexions)
Les connexions établies vers un serveur d'origine, soit directement soit via un tunnel créé à l'aide de la méthode CONNECT (Section 8.5), PEUVENT être réutilisées pour des requêtes avec plusieurs composants d'autorité URI différents. Une connexion peut être réutilisée tant que le serveur d'origine est autoritaire (Section 10.1). Pour les connexions TCP sans TLS, cela dépend du fait que l'hôte ait été résolu à la même adresse IP.
Pour les ressources "https", la réutilisation des connexions dépend également de la possession d'un certificat valide pour l'hôte dans l'URI. Le certificat présenté par le serveur DOIT satisfaire tous les contrôles que le client effectuerait lors de la formation d'une nouvelle connexion TLS pour l'origine.
Un serveur d'origine peut offrir un certificat avec plusieurs origines, chacune étant autoritaire pour l'utilisation de la connexion. Par exemple, un certificat peut inclure plusieurs noms d'hôte dans le champ subjectAltName. Alternativement, un nom d'hôte contenant un caractère générique peut également être applicable à d'autres origines.
Dans certains cas, l'autorité URI peut différer de l'ensemble des origines identifiées dans le certificat (par exemple, certains déploiements utilisent des URI pour transporter des assertions d'identité établies ailleurs), et d'autres attributs de l'autorité ne correspondent pas non plus. Un client PEUT tenter d'utiliser une connexion existante mais DOIT envoyer la requête avec un URI que le client considère comme autoritaire. Si le serveur ne souhaite pas accepter la requête, il DEVRAIT produire un code d'état 421 (Misdirected Request), ce qui amènera le client à réessayer la requête.
Si le client découvre que la connexion qu'il tente de réutiliser n'est plus disponible, il PEUT réessayer une requête non sûre sur une nouvelle connexion.
Un proxy PEUT réutiliser les connexions vers le même serveur d'origine.
9.1.2. The 421 (Misdirected Request) Status Code (Le Code d'État 421 (Requête Mal Dirigée))
Le code d'état 421 (Misdirected Request) indique que la requête a été dirigée vers un serveur qui n'est pas en mesure de produire une réponse. Cela peut être envoyé par un serveur qui n'est pas configuré pour produire des réponses pour la combinaison de schéma et d'autorité incluse dans l'URI de requête.
Les clients recevant une réponse 421 (Misdirected Request) PEUVENT réessayer la requête, que la méthode de requête soit idempotente ou non, sur une connexion différente. Cela est possible car il est uniquement permis de générer un code de réponse 421 avant que le serveur ne choisisse de ne pas fournir une réponse autoritaire.
Ce code d'état NE DOIT PAS être généré par les proxies. Une réponse 421 est mise en cache ; elle est mise en cache heuristiquement par défaut sauf indication contraire dans la réponse (voir Section 4.2.2 de [HTTP-CACHING]).
9.2. Use of TLS Features (Utilisation des Fonctionnalités TLS)
Les implémentations de HTTP/2 DOIVENT utiliser TLS version 1.2 [TLS12] ou supérieure pour les URI "https". Des conseils généraux sur l'utilisation des implémentations TLS sont donnés dans [TLSBCP].
Les implémentations de TLS DOIVENT prendre en charge l'extension Server Name Indication (SNI) [TLS-EXT]. Les clients HTTP/2 DOIVENT indiquer le nom de domaine cible pendant la négociation TLS, sauf si un mécanisme alternatif pour indiquer l'hôte cible est fourni.
Les déploiements de HTTP/2 qui dépendent de TLS 1.3 [TLS13] ou supérieur DEVRAIENT prendre en charge et utiliser l'extension TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN] pour les clients et les serveurs. Cela permet d'identifier l'utilisation de HTTP/2 pendant la négociation TLS sans consommer un aller-retour.
Bien que les options au niveau de la connexion ne soient pas spécifiques à l'utilisation de HTTP, un serveur qui utilise HTTP/2 peut transmettre ses préférences pour les connexions. TLS fournit un chiffrement, ce qui peut minimiser la capacité des espions à apprendre des informations échangées entre un client et un serveur. TLS fournit également une protection d'intégrité, garantissant que les informations ne sont pas modifiées en transit, que ce soit par une corruption réseau involontaire ou par des attaquants actifs.
Les règles de la Section 7.4.1.4 de [TLS12] DOIVENT être suivies après la négociation de l'utilisation de HTTP/2. Ces règles utilisent le certificat du serveur pour établir l'identité ; les certificats clients ne peuvent pas être utilisés à cette fin. Les vérifications de la chaîne de certificats et de l'autorité de certification (CA) sont également requises.
Si HTTP/2 est négocié sur TLS 1.2, la liste noire de suites de chiffrement TLS 1.2 (Section 9.2.2) DOIT être proposée.
L'utilisation de certificats TLS compressés est déconseillée ; les certificats utilisés par les clients et les serveurs dans HTTP/2 NE DEVRAIENT PAS être compressés sauf demande explicite du client.
9.2.1. TLS 1.2 Features (Fonctionnalités TLS 1.2)
Cette section décrit les restrictions sur l'utilisation de TLS 1.2 qui sont spécifiques à HTTP/2. Étant donné que ces restrictions sont principalement abordées dans TLS 1.3, les implémentations sont encouragées à utiliser TLS 1.3 ou supérieur. Les implémentations qui utilisent uniquement TLS 1.2 DOIVENT se conformer aux exigences de cette section.
9.2.1.1. TLS 1.2 Features for HTTP/2 Clients (Fonctionnalités TLS 1.2 pour les Clients HTTP/2)
Les implémentations de clients HTTP/2 DOIVENT prendre en charge l'envoi de TLS Server Name Indication (SNI) [TLS-EXT] via le champ d'extension dans la négociation.
Les clients HTTP/2 DOIVENT prendre en charge TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN].
9.2.1.2. TLS 1.2 Features for HTTP/2 Servers (Fonctionnalités TLS 1.2 pour les Serveurs HTTP/2)
Si le serveur négocie HTTP/2 par un moyen autre qu'ALPN ou NPN, le serveur DOIT fournir au client une opportunité d'indiquer s'il est disposé à utiliser HTTP/2.
Les serveurs HTTP/2 DEVRAIENT envoyer l'extension extended master secret [RFC7627]. Si le client ne prend pas en charge cette extension, le serveur NE DOIT PAS reprendre une session précédemment établie. Si l'extended master secret est négocié, le serveur PEUT reprendre une session précédemment établie.
9.2.2. TLS 1.2 Cipher Suites (Suites de Chiffrement TLS 1.2)
Les déploiements de HTTP/2 sur TLS 1.2 DOIVENT prendre en charge TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] avec la courbe elliptique secp256r1 [RFC8422]. Notez que les clients indiquent leur prise en charge des courbes qu'ils prennent en charge via l'extension supported_groups [TLS13] dans le message TLS ClientHello, et les serveurs indiquent la prise en charge d'une courbe en sélectionnant l'une des courbes listées que l'extension offre.
Les clients PEUVENT annoncer la prise en charge de toute suite de chiffrement sur TLS 1.2 utilisée avec HTTP/2. Cependant, les suites de chiffrement listées ci-dessous ont des qualités connues de mauvaise qualité et sont donc interdites pour une utilisation dans HTTP/2 sur TLS 1.2. Ces suites ont une ou plusieurs des propriétés suivantes :
- Suites de chiffrement NULL, qui ne fournissent aucun chiffrement.
- Suites basées sur des chiffrements de flux, dont l'utilisation dans TLS est vulnérable aux attaques.
- Suites basées sur RC4, qui ont de graves problèmes de sécurité.
- Suites basées sur 3DES, qui fournissent moins de 112 bits de sécurité réelle.
- Suites de chiffrement par blocs en mode CBC, qui sont sensibles aux attaques dans TLS, en particulier dans TLS 1.2 et versions antérieures.
- Suites basées sur l'échange de clés RSA, qui ne fournissent pas de confidentialité persistante.
- Suites qui utilisent des paramètres Diffie-Hellman déconseillés pour une utilisation avec TLS.
- Suites qui utilisent des digests SHA-1 avec un support médiocre pour les algorithmes AEAD.
Une liste complète des suites de chiffrement interdites est fournie dans l'Annexe A.
9.3. Connection Preface (Préface de Connexion)
Dans HTTP/2, chaque point de terminaison est tenu d'envoyer une préface de connexion comme confirmation finale du protocole en cours d'utilisation et pour établir les paramètres initiaux de la connexion HTTP/2. Le client et le serveur envoient chacun une préface de connexion différente.
La préface de connexion client commence par une séquence de 24 octets, qui en notation hexadécimale est :
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
C'est-à-dire que la préface de connexion commence par la chaîne PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. Cette séquence DOIT être suivie d'une trame SETTINGS (Section 6.5), qui PEUT être vide. Le client envoie la préface de connexion client immédiatement à la réception de la préface de connexion serveur.
| Note : La préface de connexion client est sélectionnée de sorte que la possibilité qu'une | connexion HTTP/2 soit considérée comme une requête HTTP/1.1 valide par des serveurs qui | traitent d'autres protocoles HTTP soit minimisée. Notez qu'aucune requête HTTP/1.1 ne | peut raisonnablement inclure "PRI" comme jeton de méthode.
La préface de connexion serveur consiste en une trame SETTINGS potentiellement vide (Section 6.5) qui DOIT être la première trame que le serveur envoie dans la connexion HTTP/2.
Un client qui effectue une mise à niveau après avoir reçu une réponse 101 (Switching Protocols) qui nécessite HTTP/1.1 (ou antérieur) DOIT envoyer immédiatement la préface de connexion client.
Le serveur reçoit la préface de connexion client et le client reçoit la préface de connexion serveur. La trame SETTINGS dans la préface de connexion DOIT être acquittée (voir Section 6.5.3) dans le cadre de l'établissement ultérieur de la connexion (voir Section 3.4).
Pour éviter une latence inutile, les clients sont autorisés à envoyer des trames supplémentaires au serveur immédiatement après l'envoi de la préface de connexion client, sans attendre de recevoir la préface de connexion serveur. Il est important de noter, cependant, que la trame SETTINGS de la préface de connexion serveur peut inclure des paramètres qui doivent être respectés pour communiquer avec le serveur. À la réception de la trame SETTINGS, le client DEVRAIT respecter tous les paramètres établis. Dans certaines configurations, il est possible que le serveur transmette SETTINGS avant que le client n'envoie des trames supplémentaires, offrant une opportunité d'éviter ce problème.
Les clients et les serveurs DOIVENT traiter une préface de connexion invalide comme une erreur de connexion (Section 5.4.1) de type PROTOCOL_ERROR. Une trame GOAWAY (Section 6.8) PEUT être omise dans ce cas, car une préface invalide indique que le pair n'utilise pas HTTP/2.
Chapitre 9 terminé !
References
- [TCP] RFC 793
- [TLS13] RFC 8446
- [TLS12] RFC 5246
- [TLS-EXT] RFC 6066
- [TLS-ALPN] RFC 7301
- [TLSBCP] RFC 9325
- [TLS-ECDHE] RFC 5289
- [RFC8422] RFC 8422
- [RFC7627] RFC 7627
- [ALT-SVC] RFC 7838
- [HTTP-CACHING] RFC 9111