HTTP/3 sur la base de QUIC : le même niveau de sécurité en plus rapide !

Cybersécurité

L’IETF (Internet Engineering Task Force) travaille sur l’utilisation du HTTP sur la base du QUIC depuis un certain temps maintenant, afin d’aboutir à la prochaine version majeure du HTTP, qui s’appellera HTTP/3 !

quic

La campagne de Google visant à accélérer les performances du web a franchi une nouvelle étape décisive le mois dernier. Des employés de l’IETF (Internet Engineering Task Force) ont suggéré de bâtir la prochaine version du protocole de base sur une technologie issue du géant de la recherche en ligne.

L’IETF est responsable de la validation d’un grand nombre des normes clés qui sous-tendent l’Internet et le Web. L’une d’entre elles est le protocole de transport hypertexte (HTTP), qui permet aux navigateurs de rechercher des pages web.

En 2013, Google a lancé un nouveau protocole expérimental appelé QUIC (Quick UDP Internet Connections), qui rendait les requêtes HTTP plus rapides et plus sécurisées.

Google a proposé l’utilisation de QUIC en 2016 pour l’exécution des requêtes HTTP. L’IETF a fait évoluer le protocole qui a finalement débouché sur leur propre version (parfois appelée iQUIC, contrairement à la version gQUIC de Google).

L’IETF travaille sur l’utilisation du HTTP sur la base du QUIC depuis un certain temps. Le 18 octobre, Mark Nottingham, président des groupes de travail HTTP et QUIC, a laissé entendre qu’il était temps d’appeler cette nouvelle version HTTP/3. Cette initiative en ferait effectivement la prochaine version majeure du HTTP et représenterait ainsi un changement important.

Un internet plus rapide, plus QUIC !

QUIC cherche à rendre les connexions réseau plus rapides en réduisant le nombre d’allers et retours qu’un ordinateur doit effectuer lors du téléchargement d’informations depuis un autre appareil via le HTTP.  Les allers-retours se produisent au niveau des requêtes HTTP car le client (généralement le navigateur) doit établir une connexion avec le serveur. Faites un parallèle avec le fait de demander un service à votre nouveau collègue de travail. Tout d’abord, vous devez vous présenter, en expliquant qui vous êtes et ce que vous faites. Ensuite, vous devez attendre qu’il vous salut et vous reconnaisse avant de faire votre demande. Ensuite, après avoir appris à vous connaître, vous pouvez vous permettre simplement de passer la tête par la porte en disant “hey, Paul, puis-je t’emprunter ce fichier ?”. Paul vous le donnera sans aucun problème car, à présent, il vous connait et vous fait confiance. QUIC fonctionne de la même manière !

Le protocole possède d’autres atouts dans sa manche. L’un d’eux, s’appuyant sur des travaux antérieurs dans le HTTP/2, utilise plusieurs connexions à la fois. Il évalue également la bande passante que les connexions utiliseront à l’avance dans les deux sens, afin de minimiser d’éventuelles congestions en espaçant, en conséquence, les transmissions de paquets, et utilise la correction d’erreur pour minimiser la retransmission de données perdues.

QUIC utilise également la version 1.3 de la norme de chiffrement et de certification TLS, qui est devenue une “proposition de norme” officielle de l’IETF en août 2018.

Contrairement à HTTP/2, TLS 1.3 n’est cependant pas facultatif. Si vous souhaitez profiter de la vitesse supplémentaire du HTTP/3, vous devrez également vous conformer à la confidentialité et à la sécurité supplémentaires de TLS 1.3.

Lors de la conception de QUIC, Google a franchi une étape importante en abandonnant le mécanisme de réseau principal pour le transport du trafic, connu sous le nom de Transmission Control Protocol (TCP). Ce dernier a été un composant essentiel pour les communications Internet depuis le milieu des années 1970 et sous-tend le web depuis ses débuts. Au lieu de cela, QUIC est passé à l’autre protocole UDP (User Datagram Protocol), conçu pour les communications à faible latence. En effet, UDP se concentre uniquement sur l’envoi de paquets, évitant ainsi les fonctions supplémentaires offertes par le TCP, telles que le renvoi des paquets perdus et le ré-assemblage des paquets dans l’ordre. Cela le rend donc plus rapide.

Le souhait de passer à l’UDP est la raison pour laquelle Google n’a pas continué avec SPDY, un protocole antérieur qu’il avait également proposé. Il s’agissait d’un protocole basé sur le TCP, également conçu pour accélérer les transmissions HTTP. Il a servi de base pour le HTTP/2, ratifié en 2015, mais Google lui a retiré son soutien la même année, après l’avoir déprécié.

Google estime que les requêtes HTTP traditionnelles basées sur le protocole TCP prennent environ 100 ms, car le client doit établir une connexion avec le serveur avant de faire une quelconque demande. Ce délai s’allonge sérieusement lorsque vous utilisez le TCP et le TLS pour plus de sécurité, allant jusqu’à 300 ms. Sur une connexion QUIC, cela prendra initialement le même temps qu’une connexion TCP. Lorsque le client a déjà échangé avec le serveur, cela prendra 0 ms, car il n’y aura pas d’aller-retour. Le serveur sait déjà qui est le client, il n’y aura donc pas besoin de faire les présentations.

Le projet préliminaire de l’IETF pour un protocole HTTP avec l’utilisation de QUIC a été publié le 24 octobre. Sa ratification prendra du temps. Si et quand une telle évolution se produira, alors le monde entier ne basculera pas soudainement vers le HTTP/3. Toutefois, les sites web en mesure de répondre aux requêtes des navigateurs compatibles seront traités plus rapidement et en toute sécurité !


Billet inspiré de HTTP/3: Come for the speed, stay for the security, sur Sophos nakedsecurity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.