Introduction au réseau QUIC et au chiffrement dans NGINX

Robert HaynesResponsable marketing technique

La première mention de QUIC et HTTP/3 sur le blog de NGINX remonte à quatre ans (!), et comme vous, nous attendons désormais avec impatience l’intégration imminente de notre implémentation de QUIC dans la branche principale de NGINX Open Source. Compte tenu de cette longue gestation, il est compréhensible que vous n’ayez pas beaucoup réfléchi à QUIC.

À ce stade, toutefois, en tant que développeur ou administrateur de site, vous devez savoir que QUIC transfère la responsabilité de certains aspects liés au réseau du système d’exploitation vers NGINX (et toutes les applications HTTP). Même si les réseaux ne sont pas votre domaine, adopter QUIC signifie que vous préoccuper du réseau fait désormais partie, au moins un peu, de votre travail.

Dans cet article, nous examinons les principaux concepts de réseau et de chiffrement utilisés dans QUIC, en simplifiant certains détails et en omettant les informations non essentielles dans un souci de clarté. Même si certaines nuances peuvent se perdre au passage, notre objectif est de vous fournir suffisamment d’informations pour adopter efficacement QUIC dans votre environnement, ou tout au moins de vous donner les bases nécessaires pour approfondir vos connaissances.

Si vous ne connaissez pas du tout QUIC, nous vous recommandons de commencer par lire l’un de nos précédents articles et de regarder notre vidéo de présentation.

 

Pour une explication plus détaillée et complète de QUIC, nous vous recommandons l’excellent document « Gérabilité du protocole de transport QUIC » du groupe de travail QUIC de l’IETC, ainsi que les ressources complémentaires accessibles via les liens figurant dans le présent document.

Pourquoi devriez-vous vous intéresser à la mise en réseau et au chiffrement dans QUIC ?

Jusqu’à présent, les détails peu reluisants de la connexion réseau entre les clients et NGINX n’avaient guère d’importance pour la plupart des utilisateurs. Après tout, avec HTTP/1.x et HTTP/2, le système d’exploitation se charge d’établir la connexion TCP (Transmission Control Protocol) entre les clients et NGINX. NGINX se contente ensuite d’utiliser la connexion une fois celle-ci établie.

Avec QUIC, en revanche, la responsabilité de la création, de la validation et de la gestion des connexions passe du système d’exploitation sous-jacent à NGINX. Au lieu de recevoir une connexion TCP établie, NGINX reçoit désormais un flux de datagrammes UDP (User Datagram Protocol), qu’il doit analyser pour les convertir en connexions clientes et en flux. NGINX doit également gérer désormais la perte de paquets, le rétablissement des connexions et le contrôle de la congestion.

En outre, QUIC regroupe l’initiation de la connexion, la négociation de version et l’échange de clés de chiffrement en une seule opération d’établissement de connexion. Et bien que le chiffrement TLS soit géré de manière globalement similaire pour QUIC+HTTP/3 et TCP+HTTP/1+2, certaines différences peuvent avoir une incidence sur les équipements en aval, tels que les répartiteurs de charge de couche 4, les pare-feu et les appliances de sécurité.

En définitive, ces changements se traduisent globalement par une expérience plus sûre, plus rapide et plus fiable pour les utilisateurs, sans nécessiter de modifications majeures de la configuration ou de l’exploitation de NGINX. Les administrateurs NGINX doivent toutefois comprendre, au moins dans les grandes lignes, ce qui se passe avec QUIC et NGINX, ne serait-ce que pour réduire autant que possible leur délai moyen de mise hors de cause en cas de problème.

(Il convient de noter que, même si cet article se concentre sur les opérations HTTP, car HTTP/3 nécessite QUIC, QUIC peut également être utilisé pour d’autres protocoles. Le DNS sur QUIC, tel que défini dans la RFC 9250, « DNS sur des connexions QUIC dédiées », en est un bon exemple.)

Maintenant que cette introduction est faite, entrons dans les détails du fonctionnement réseau de QUIC.

TCP contre UDP

QUIC apporte un changement majeur au protocole réseau sous-jacent utilisé pour transmettre les données applicatives HTTP entre un client et un serveur.

Comme indiqué précédemment, TCP a toujours été le protocole utilisé pour transmettre les données des applications web HTTP. TCP est conçu pour acheminer les données de manière fiable sur un réseau IP. Il dispose d’un mécanisme bien défini et éprouvé pour établir les connexions et accuser réception des données, ainsi que de divers algorithmes et techniques permettant de gérer les pertes de paquets et les délais courants sur les réseaux peu fiables et encombrés.

Bien que TCP assure un transport fiable, cela implique des compromis en matière de performances et de latence. En outre, le chiffrement des données n’est pas intégré à TCP et doit être mis en œuvre séparément. Il s’est également avéré difficile d’améliorer ou d’étendre TCP face à l’évolution des modèles de trafic HTTP : le traitement de TCP étant effectué dans le noyau Linux, toute modification doit être conçue et testée avec soin afin d’éviter des effets imprévus sur les performances et la stabilité globales du système.

Un autre problème tient au fait que, dans de nombreux cas, le trafic HTTP entre le client et le serveur transite par plusieurs dispositifs traitant les connexions TCP, tels que des pare-feu ou des répartiteurs de charge (collectivement appelés « boîtiers intermédiaires »), qui peuvent tarder à mettre en œuvre les évolutions des normes TCP.

QUIC utilise quant à lui UDP comme protocole de transport. UDP est conçu pour transmettre des données sur un réseau IP comme TCP, mais il fait délibérément l’impasse sur l’établissement d’une connexion et la fiabilité de la transmission. Cette absence de surcharge rend UDP adapté à de nombreuses applications où l’efficacité et la rapidité priment sur la fiabilité.

Cependant, pour la plupart des applications web, la fiabilité de la transmission des données est essentielle. Comme la couche de transport UDP sous-jacente ne garantit pas cette fiabilité, ces fonctions doivent être assurées par QUIC (ou par l’application elle-même). Heureusement, QUIC présente quelques avantages par rapport à TCP à cet égard :

• Le traitement de QUIC s’effectue dans l’espace utilisateur de Linux, où les problèmes liés à une opération particulière présentent moins de risques pour l’ensemble du système. Cela facilite le développement rapide de nouvelles fonctionnalités.
• Les « middleboxes » mentionnées ci-dessus n’effectuent généralement qu’un traitement minimal du trafic UDP et ne limitent donc pas les améliorations apportées au protocole QUIC.

Anatomie simplifiée d’un réseau QUIC

Les flux QUIC sont les objets logiques qui contiennent les requêtes ou les réponses HTTP/3 (ou toute autre donnée applicative). Pour être transmis entre les points de terminaison du réseau, ils sont encapsulés dans plusieurs couches logiques, comme illustré dans le schéma.

En partant de l’extérieur vers l’intérieur, les couches et objets logiques sont les suivants :

• Datagramme UDP – Contient un en-tête indiquant les ports source et de destination (ainsi que les données de longueur et de somme de contrôle), suivi d’un ou de plusieurs paquets QUIC. Le datagramme est l’unité d’information transmise du client au serveur sur le réseau.
• Paquet QUIC – Contient un en-tête QUIC et une ou plusieurs trames QUIC.
• En-tête QUIC – Contient des métadonnées sur le paquet. Il existe deux types d’en-têtes :
  • L’en-tête long, utilisé lors de l’établissement de la connexion.
  • L’en-tête court, utilisé une fois la connexion établie. Il contient, entre autres données, l’identifiant de connexion, le numéro de paquet et la phase de clé (qui permet de déterminer quelles clés ont été utilisées pour chiffrer le paquet, afin de prendre en charge la rotation des clés). Les numéros de paquet sont uniques (et toujours croissants) pour une connexion et une phase de clé données.
• Trame – Contient le type, l’identifiant du flux, le décalage et les données du flux. Les données du flux sont réparties sur plusieurs trames, mais peuvent être réassemblées à l’aide de l’identifiant de connexion, de l’identifiant du flux et du décalage, qui permet de présenter les blocs de données dans le bon ordre.
• Flux – Un flux de données unidirectionnel ou bidirectionnel au sein d’une même connexion QUIC. Chaque connexion QUIC peut prendre en charge plusieurs flux indépendants, chacun possédant son propre identifiant de flux. Si un paquet QUIC contenant certains flux est perdu, cela n’affecte pas la progression des flux qui ne figurent pas dans le paquet manquant (ce point est essentiel pour éviter le blocage en tête de file rencontré avec HTTP/2). Les flux peuvent être bidirectionnels et créés par l’un ou l’autre des points de terminaison.

Établissement de la connexion

La célèbre poignée de main en trois étapes SYN / SYN-ACK / ACK permet d’établir une connexion TCP :

Figure 2. La poignée de main en trois étapes qui établit une connexion TCP

L’établissement d’une connexion QUIC suit des étapes similaires, mais de manière plus efficace. Il intègre également la validation de l’adresse à l’établissement de la connexion dans le cadre de l’échange cryptographique. La validation de l’adresse protège contre les attaques par amplification de trafic, lors desquelles un acteur malveillant envoie au serveur un paquet contenant une adresse source usurpée correspondant à celle de la victime ciblée. L’attaquant espère que le serveur générera à destination de la victime des paquets plus nombreux ou plus volumineux que ceux qu’il peut générer lui-même, provoquant ainsi un volume de trafic écrasant. (Pour plus de détails, consultez la section 8 de la RFC 9000, QUIC : un protocole de transport sécurisé et multiplexé basé sur UDP.)

Lors de l’établissement de la connexion, le client et le serveur fournissent chacun un identifiant de connexion indépendant, encodé dans l’en-tête QUIC, ce qui permet d’identifier facilement la connexion, indépendamment de l’adresse IP source du client.

Cependant, comme l’établissement initial d’une connexion QUIC comprend également des opérations d’échange de clés de chiffrement TLS, il nécessite davantage de ressources de calcul côté serveur que la simple réponse « SYN-ACK » générée lors de l’établissement d’une connexion TCP. Cela crée également un vecteur potentiel d’attaques par déni de service distribué (DDoS) car l’adresse IP du client n’est pas validée avant les opérations d’échange de clés.

Vous pouvez toutefois configurer NGINX pour qu’il valide l’adresse IP du client avant le début des opérations cryptographiques complexes, en définissant la directive quic_retry sur on. Dans ce cas, NGINX envoie au client un paquet de nouvelle tentative contenant un jeton que le client doit inclure dans les paquets d’établissement de la connexion.

Figure 3. Établissement d’une connexion QUIC, sans et avec paquet de nouvelle tentative

Ce mécanisme s’apparente quelque peu à la poignée de main TCP en trois étapes et, surtout, permet de vérifier que le client est bien propriétaire de l’adresse IP source qu’il présente. Sans cette vérification, les serveurs QUIC tels que NGINX pourraient être facilement exposés à des attaques par déni de service (DoS) utilisant des adresses IP source usurpées. (Un autre mécanisme de QUIC permettant d’atténuer ce type d’attaque impose que tous les paquets initiaux de connexion soient complétés pour atteindre une taille minimale de 1 200 octets, ce qui rend leur envoi plus coûteux.)

En outre, les paquets Retry atténuent une attaque similaire à l’attaque TCP par inondation SYN (dans laquelle les ressources du serveur sont épuisées par un très grand nombre de négociations de connexion ouvertes, mais non terminées, conservées en mémoire), en encodant les détails de la connexion dans l’identifiant de connexion qu’ils envoient au client. Cela présente également l’avantage de ne nécessiter la conservation d’aucune information côté serveur, puisque les informations de connexion peuvent être reconstituées à partir de l’identifiant de connexion et du jeton présentés ultérieurement par le client. Cette technique est analogue aux cookies SYN de TCP. En outre, les serveurs QUIC tels que NGINX peuvent fournir un jeton à durée de validité limitée, destiné à être utilisé lors de futures connexions du client afin d’accélérer la reprise de connexion.

L’utilisation d’identifiants de connexion permet à la connexion d’être indépendante de la couche de transport sous-jacente, de sorte que les changements de réseau n’entraînent pas nécessairement l’interruption des connexions. Ce point est abordé dans Gestion transparente des changements d’adresse IP du client.

Détection des pertes

Une fois la connexion établie (et le chiffrement activé, comme expliqué plus en détail ci-dessous), les requêtes et réponses HTTP peuvent circuler dans les deux sens entre le client et NGINX. Des datagrammes UDP sont envoyés et reçus. Cependant, de nombreux facteurs peuvent entraîner la perte ou le retard de certains de ces datagrammes.

TCP dispose de mécanismes complexes permettant d’accuser réception des paquets, de détecter leur perte ou leur retard et de gérer la retransmission des paquets perdus, afin de fournir à la couche applicative des données complètes et correctement ordonnées. UDP ne dispose pas de cette fonctionnalité ; le contrôle de congestion et la détection des pertes sont donc mis en œuvre dans la couche QUIC.

• Le client et le serveur envoient tous deux un accusé de réception explicite pour chaque paquet QUIC reçu (bien que les paquets contenant uniquement des trames de faible priorité ne fassent pas l’objet d’un accusé de réception immédiat).
• Lorsqu’un paquet contenant des trames nécessitant une livraison fiable n’a pas fait l’objet d’un accusé de réception après un délai défini, il est considéré comme perdu. Les délais d’expiration varient en fonction du contenu du paquet : par exemple, le délai est plus court pour les paquets nécessaires à l’établissement du chiffrement et à la configuration de la connexion, car ils sont essentiels aux performances de la négociation QUIC.
• Lorsqu’un paquet est considéré comme perdu, les trames manquantes sont retransmises dans un nouveau paquet, auquel est attribué un nouveau numéro de séquence.
• Le destinataire des paquets utilise l’identifiant du flux et le décalage indiqués dans les paquets pour réassembler les données transmises dans le bon ordre. Le numéro de paquet indique uniquement l’ordre d’envoi, et non la manière dont les paquets doivent être réassemblés.
• Comme l’assemblage des données côté récepteur est indépendant de l’ordre de transmission, un paquet perdu ou retardé n’affecte que les flux individuels qu’il contient, et non tous les flux de la connexion. Cela élimine le problème de blocage en tête de ligne qui affecte HTTP/1.x et HTTP/2, car les flux ne font pas partie de la couche de transport.

Une description complète de la détection des pertes dépasse le cadre de cette introduction. Consultez la RFC 9002, « Détection des pertes et contrôle de congestion dans QUIC », pour en savoir plus sur les mécanismes permettant de déterminer les délais d’expiration et la quantité de données non acquittées pouvant être en transit.

Gérer avec élégance les changements d’adresse IP du client

L’adresse IP d’un client (appelée « adresse IP source » dans le contexte d’une session d’application) est susceptible de changer au cours de la session, par exemple lorsqu’un VPN ou une passerelle change d’adresse publique, ou lorsqu’un utilisateur de smartphone quitte une zone couverte par le Wi-Fi, ce qui entraîne le basculement vers un réseau cellulaire. Par ailleurs, les administrateurs réseau ont traditionnellement défini des délais d’expiration plus courts pour le trafic UDP que pour les connexions TCP, ce qui augmente la probabilité d’une réaffectation de la traduction d’adresses réseau (NAT).

QUIC fournit deux mécanismes permettant de réduire les perturbations qui peuvent en résulter : un client peut informer de manière proactive le serveur que son adresse va changer, et les serveurs peuvent gérer sans interruption un changement imprévu de l’adresse du client. Comme l’identifiant de connexion reste inchangé pendant la transition, les trames non acquittées peuvent être retransmises à la nouvelle adresse IP.

Les changements d’adresse IP source au cours des sessions QUIC peuvent poser problème aux répartiteurs de charge en aval (ou à d’autres composants réseau de couche 4) qui utilisent l’adresse IP source et le port pour déterminer le serveur en amont auquel transmettre un datagramme UDP donné. Pour garantir une gestion correcte du trafic, les fournisseurs d’équipements réseau de couche 4 devront les mettre à jour afin qu’ils prennent en charge les identifiants de connexion QUIC. Pour en savoir plus sur l’avenir de la répartition de charge et de QUIC, consultez le projet de l’IETF QUIC‑LB : génération d’identifiants de connexion QUIC routables.

Chiffrement

Dans la section « Établissement de la connexion », nous avons indiqué que la négociation QUIC initiale ne se contente pas d’établir une connexion. Contrairement à la négociation TLS pour TCP, avec UDP, l’échange des clés et des paramètres de chiffrement TLS 1.3 s’effectue dans le cadre de la connexion initiale. Cette fonctionnalité élimine plusieurs échanges et permet une reprise sans aller-retour (0-RTT) lorsque le client rétablit une connexion antérieure.

En plus d’intégrer la négociation du chiffrement au processus d’établissement de la connexion, QUIC chiffre une plus grande partie des métadonnées que TCP+TLS. Les paquets initiaux de la connexion sont chiffrés avant même que l’échange de clés ait eu lieu ; bien qu’une personne espionnant les communications puisse toujours retrouver les clés, cela demande davantage d’efforts qu’avec des paquets non chiffrés. Les données telles que l’indication du nom du serveur (SNI), qui intéressent aussi bien les attaquants que les organismes de censure étatiques potentiels, sont ainsi mieux protégées. La figure 5 montre que QUIC chiffre davantage de métadonnées potentiellement sensibles (en rouge) que TCP+TLS.

Toutes les données de la charge utile QUIC sont chiffrées à l’aide de TLS 1.3. Cela présente deux avantages : les anciennes suites de chiffrement et les anciens algorithmes de hachage vulnérables ne sont pas autorisés, et les mécanismes d’échange de clés assurant la confidentialité persistante (FS) sont obligatoires. La confidentialité persistante empêche un attaquant de déchiffrer les données, même s’il parvient à obtenir la clé privée et une copie du trafic.

Les connexions à faible latence et à zéro RTT réduisent la latence

Réduire le nombre d’allers-retours nécessaires entre un client et un serveur avant de pouvoir transmettre des données applicatives améliore les performances des applications, en particulier sur les réseaux présentant une latence élevée.

TLS 1.3 a permis d’établir une connexion chiffrée en un seul aller-retour et de reprendre une connexion sans aucun aller-retour. Toutefois, avec TCP, cela signifie que la négociation doit avoir lieu avant le message Client Hello de TLS.

Comme QUIC combine les opérations cryptographiques avec l’établissement de la connexion, il permet une véritable reprise de connexion en 0‑RTT, où un client peut envoyer une requête dès le tout premier paquet QUIC. Cela réduit la latence en supprimant l’aller-retour initial nécessaire à l’établissement de la connexion avant la première requête.

Dans ce cas, le client envoie une requête HTTP chiffrée à l’aide des paramètres utilisés lors d’une connexion précédente et y inclut, à des fins de validation de l’adresse, un jeton fourni par le serveur au cours de cette connexion.

Malheureusement, la reprise de connexion 0‑RTT n’offre pas de confidentialité persistante. La requête initiale du client n’est donc pas chiffrée de manière aussi sûre que les autres échanges. Les requêtes et réponses qui suivent la première requête sont protégées par la confidentialité persistante. Plus problématique encore, la requête initiale est également vulnérable aux attaques par rejeu, lors desquelles un attaquant peut intercepter la requête initiale et la renvoyer plusieurs fois au serveur.

Pour de nombreuses applications et de nombreux sites web, le gain de performances offert par la reprise de connexion 0‑RTT l’emporte sur ces vulnérabilités potentielles, mais c’est à vous d’en décider.

Cette fonctionnalité est désactivée par défaut dans NGINX. Pour l’activer, définissez la directive « ssl_early_data » sur « on ».

Passer de HTTP/1.1 à HTTP/3 avec l’en-tête « Alt-Svc »

La quasi-totalité des clients (notamment les navigateurs) établissent leurs connexions initiales via TCP/TLS. Si un serveur prend en charge QUIC+HTTP/3, il le signale au client en renvoyant une réponse HTTP/1.1 qui inclut le paramètre h3 dans l’en-tête Alt-Svc. Le client choisit alors d’utiliser QUIC+HTTP/3 ou de conserver une version antérieure de HTTP. (À titre d’information, l’en-tête Alt-Svc, défini dans la RFC 7838, est antérieur à QUIC et peut également être utilisé à d’autres fins.)

L’en-tête « Alt-Svc » indique au client que le même service est disponible sur un autre hôte, via un autre protocole ou sur un autre port (ou une combinaison de ces possibilités). Il permet également d’indiquer aux clients pendant combien de temps ils peuvent raisonnablement supposer que ce service restera disponible.

Quelques exemples :

Alt-Svc: h3=":443" HTTP/3 est disponible sur ce serveur, sur le port 443Alt-Svc: h3="new.example.com:8443" HTTP/3 est disponible sur le serveur new.example.com sur le port 8443Alt-Svc: h3=":8443"; ma=600 HTTP/3 est disponible sur ce serveur, sur le port 8443, et le restera pendant au moins 10 minutes

Bien que cela ne soit pas obligatoire, dans la plupart des cas, les serveurs sont configurés pour répondre aux connexions QUIC sur le même port que TCP+TLS.

Pour configurer NGINX afin d’inclure l’en-tête Alt-Svc, utilisez la directive add_header. Dans cet exemple, la variable $server_port signifie que NGINX accepte les connexions QUIC sur le port auquel le client a envoyé sa requête TCP+TLS, et 86 400 correspond à 24 heures :

add_header Alt-Svc 'h3=":$server_port"; ma=86400';

Conclusion

Cet article de blog propose une introduction simplifiée à QUIC et, nous l’espérons, vous donne une vue d’ensemble suffisante pour comprendre les principales opérations de mise en réseau et de chiffrement utilisées avec QUIC.

Pour en savoir plus sur la configuration de NGINX pour QUIC + HTTP/3, consultez l’article Des paquets binaires sont désormais disponibles pour la version préliminaire de l’implémentation NGINX QUIC+HTTP/3 sur notre blog ou regardez notre webinaire « Prenez en main NGINX et QUIC+HTTP/3 ». Pour obtenir des informations détaillées sur toutes les directives NGINX pour QUIC+HTTP/3 ainsi que des instructions complètes pour installer des binaires précompilés ou effectuer une compilation à partir du code source, consultez la page web NGINX QUIC.

À propos de l’auteur

Robert HaynesResponsable marketing technique

Autres articles de Robert Haynes