Qu'est-ce que le QUIC ? Comprendre le protocole
Un protocole définit la manière dont les données sont transférées sur l'internet entre deux appareils. Et comme les protocoles doivent être adaptés entre le client et le serveur qui répond, l'industrie s'est largement appuyée sur quelques éléments de base largement adoptés. Les protocoles les plus anciens sont le TCP et l'UDP, qui existent tous deux depuis des décennies.
Cela a changé en 2013, lorsque Google a commencé à tester une nouvelle approche : le protocole QUIC permet aux applications Google de transmettre des données plus rapidement et avec moins de latence que les protocoles traditionnels.
Comment fonctionne le protocole QUIC ?
QUIC est un protocole de transport crypté basé sur UDP. Il est conçu pour combiner la vitesse de l'UDP avec la sécurité de protocoles tels que TLS, créant ainsi une connexion internet rapide et sécurisée.
Contrairement aux protocoles traditionnels où l'authentification et le chiffrement sont gérés par des solutions de niveau supérieur, telles que TLS, QUIC intègre ces fonctions directement dans la couche de transport.
QUIC est ainsi plus rapide et plus efficace pour le trafic web moderne.
- Il fonctionne en initiant un processus de poignée de main rapide, ce qui lui permet d'établir rapidement une connexion sécurisée.
- Une fois la poignée de main terminée, QUIC envoie simultanément plusieurs flux de données cryptées au serveur, réduisant ainsi la latence et améliorant les performances.
En intégrant l'authentification et le chiffrement dans le protocole lui-même, QUIC rationalise la communication sécurisée tout en conservant les avantages de la légèreté du protocole UDP.
Fast Handshake
La poignée de main est un élément essentiel de tout protocole de réseau. QUIC remplace la traditionnelle poignée de main à trois voies utilisée dans TCP par le processus d'authentification et de chiffrement de la poignée de main TLS 1.3.
Pour schématiser, une connexion TCP typique implique :
- Le client envoie un paquet SYN
- Le serveur répond par un paquet SYN-ACK
- Le client finalise la connexion avec un paquet ACK.
Ce processus en trois étapes est nécessaire avant de pouvoir transmettre des données.
QUIC élimine cette exigence en fonctionnant sur UDP. Comme l'UDP ne nécessite pas l'établissement d'une connexion de la même manière, le QUIC permet d'envoyer immédiatement des données sur des liaisons compatibles avec l'UDP, ce qui réduit le temps de latence.
Dans certains cas, QUIC peut envoyer des données lors du tout premier cycle de connexion - connu sous le nom de 0-RTT (zero round-trip time). Cela est possible lorsque le serveur dispose d'une connexion précédemment mise en cache avec le client. Mais si le 0-RTT améliore la vitesse, il n'est pas toujours l'option la plus sûre et peut exposer les données à des attaques par rejeu s'il n'est pas correctement géré.
Chiffrement
En plus de sa poignée de main rapide, QUIC introduit un chiffrement intégré. Traditionnellement, sur TCP, le chiffrement était traité séparément par le protocole TLS, qui nécessitait sa propre poignée de main pour négocier la version et la suite de chiffrement. Cette poignée de main établit les algorithmes de chiffrement et les protocoles qui seront utilisés pour la session.
Comme QUIC est basé sur UDP, il modifie la poignée de main TLS traditionnelle pour l'adapter à son architecture simplifiée. QUIC y parvient en envoyant un Client Hello (CHLO) enveloppé dans deux composants spécifiques :
- Un premier paquet
- Un cadre Crypto
Ce conditionnement permet d'inclure la poignée de main cryptographique dans le tout premier datagramme UDP envoyé par le client. Ainsi, le transport et le chiffrement sont fusionnés en une seule étape efficace. Après cet échange initial, QUIC se comporte comme TLS 1.3.
Toutes les communications ultérieures entre le client et le serveur sont cryptées à l'aide des clés de session issues de la poignée de main.
Commande de paquets
QUIC est basé sur UDP, un protocole connu pour sa vitesse mais pas pour sa fiabilité - les paquets peuvent être abandonnés ou arriver dans le désordre. D'autre part, le TCP garantit la fiabilité, mais au prix d'une latence accrue. En TCP, si une erreur survient dans un flux, tous les flux simultanés du client sont mis en pause jusqu'à ce que le problème soit résolu.
QUIC établit un équilibre entre vitesse et fiabilité en organisant les données en flux indépendants et en veillant à ce que chaque flux conserve son propre ordre interne des paquets.
Mais QUIC n'impose pas l'ordre des paquets entre les différents flux.
Par exemple, imaginez deux flux - le flux A et le flux B - transférés d'un serveur à un client.
- Flux A. Si un paquet du flux A est perdu, le flux A gérera la retransmission de manière indépendante.
- Le flux B se poursuit sans interruption et peut achever son transfert sans être affecté par la perte du flux A.
Ce niveau d'indépendance des flux constitue une amélioration majeure par rapport aux protocoles précédents tels que HTTP/2, où la perte de paquets dans un flux pouvait bloquer les autres flux partageant la même connexion.
Les défis du protocole QUIC
Bien que QUIC transporte déjà une part importante des données d'application de Google, son adoption plus large dans des environnements distribués à l'échelle mondiale reste limitée.
L'un des principaux obstacles est la lenteur de l'évolution de l'infrastructure internet. Le TCP est le protocole de couche de transport dominant depuis plus de 40 ans et il est capable de transporter pratiquement n'importe quel type de données. Bien que QUIC offre des avantages évidents, notamment en réduisant la latence sur de longues distances, telles que les connexions intercontinentales, ses avantages sont souvent considérés comme limités par rapport à la polyvalence de TCP.
Google a fortement encouragé l'adoption du QUIC, en faisant progresser son développement et son intégration dans l'ensemble de ses services. Cependant, de nombreuses entreprises ont dû se démener pour s'adapter aux normes et aux tendances.
Par conséquent, les défis de mise en œuvre de QUIC restent considérables, en particulier pour les organisations disposant d'une infrastructure complexe, de systèmes existants ou d'un manque d'expertise interne.
Risques de 0-RTT
Pour les connexions en cache, QUIC permet d'envoyer des données lors du tout premier aller-retour - connu sous le nom de 0-RTT. Si cette approche élimine effectivement la latence de la poignée de main, elle pose des problèmes de sécurité notables.
L'un des risques majeurs est l'absence d'une nouvelle poignée de main cryptographique. Si la connexion initiale utilisée pour mettre en cache les informations de session est compromise, toutes les données d'application envoyées lors de la reprise de la connexion peuvent également être exposées.
Un autre problème concerne les attaques par rejeu. Les données d'application envoyées via 0-RTT peuvent être interceptées par un attaquant sur le chemin et rejouées plusieurs fois sur le même serveur. Dans la plupart des cas, le chiffrement permet d'atténuer ce type de menace, mais le 0-RTT affaiblit cette couche de protection en contournant la renégociation complète.
Par conséquent, bien que le 0-RTT offre des avantages en termes de performances, il doit être utilisé avec prudence, en particulier dans les scénarios impliquant des données sensibles ou des exigences élevées en matière de sécurité.
Incompatibilité du pare-feu
Du point de vue de la sécurité de l'entreprise, QUIC introduit des défis supplémentaires, en particulier pour les organisations qui s'appuient sur l'inspection approfondie des paquets et le décryptage du trafic.
L'un des principaux problèmes est que QUIC ne prend pas en charge le décryptage SSL, qui est une méthode couramment utilisée par les pare-feu d'entreprise pour inspecter et sécuriser le trafic réseau. Au lieu de cela, QUIC utilise son propre chiffrement. Comme il est largement déployé dans la suite d'applications de Google, cela crée un angle mort important dans la visibilité et le contrôle du réseau pour les équipes informatiques.
Un autre défi réside dans la philosophie de conception de QUIC.
Google a conçu QUIC de manière à ce qu'il soit flexible et facilement actualisable, contrairement à l'infrastructure TCP rigide et vieillissante. Si cette approche favorise l'innovation rapide, elle exige également que les pare-feu et les outils de sécurité s'adaptent rapidement aux changements au niveau des protocoles. Ce besoin permanent de mises à jour peut faire peser une lourde charge sur les équipes et les infrastructures informatiques.
Par conséquent, certains fournisseurs de pare-feu recommandent de bloquer complètement QUIC jusqu'à ce que des outils de sécurité plus matures et compatibles soient disponibles. De l'évolution de la documentation à une mise en œuvre incohérente, les défis de sécurité de QUIC continuent de s'accumuler, en particulier pour les environnements d'entreprise.
Renforcer la sécurité des réseaux à haut débit avec Check Point
Check Point is an industry-leading firewall that now supports QUIC. But Check Point Network Security offers far more than visibility into Google applications: it delivers Check Point’s deep threat awareness alongside SandBlast zero-day protection. To gain an understanding of those cutting-edge threats, explore our 2025 risk report.
On-demand hyperscale infrastructure keeps latency low and provides seamless scalability as an organization’s needs evolve. For better, clearer management, Check Point offers a unified management system that integrates visibility into networks, clouds, and IoT environments.
Experience the full capabilities of Check Point by starting your free demo today.
