La notoriété croissante de HTTP/3 est le résultat d’une conception dédiée à la performance et à la sécurité : mais quelles sont les caractéristiques qui en feront une aide indispensable dans la lutte contre la cybercriminalité ? Et est-ce vraiment si sûr ?
Qu’est-ce que HTTP/3 ?
Bien que de manière expérimentale et lente, HTTP/3 a fait ses début en 2018, mais c’est seulement depuis 2020 que le protocole peut être activé dans les navigateurs web tels que Chrome et Firefox. Bien qu’il ne soit pas encore mature, et surtout encore peu répandu, nous pouvons maintenant dire que HTTP/3 est une réalité. Cela entraîne non seulement un certain nombre de considérations techniques, mais doit également être évalué dans le contexte de la cybersécurité.
QUIC remplace le protocole TCP
Au niveau de la conception, HTTP/3 représente un bond en avant par rapport à la version précédente, ce qui ne devrait évidemment pas nous surprendre. Il améliore le protocole sur plusieurs fronts : performances, évolutivité et sécurité. Ce résultat est obtenu grâce à une longue série d’améliorations techniques, bien que la plus évidente, soit la simplification du processus de connexion à trois voies du protocole TCP tout en exploitant le protocole QUIC à sa place.
HTTP/3 : des gains de performances importants
L’un des principaux points critiques de HTTP/2 qui a été mis en évidence surtout ces dernières années réside dans l’utilisation du protocole de contrôle du transfert. En effet, celui-ci est incapable de gérer la transmission de plusieurs fichiers simultanément sur une seule connexion.
Le deuxième problème résulte du fait que le TCP traite chaque flux de données comme un flux unique (flux d’octets). Par conséquent, lorsqu’un paquet est perdu, les autres qui suivent sont mis en attente jusqu’à ce qu’il soit retrouvé. Afin de résoudre ce problème, HTTP/2 utilise le multiplexage, bien que cela ne fonctionne qu’au niveau de la couche applicative, avec des implications importantes en termes de performances et de sécurité.
Enfin, il est important de souligner que la poignée de main à trois voies, qui est devenu extrêmement courant, semble avoir atteint ses limites car il s’agit d’un processus lourd qui peut prendre entre 200 et 300 ms. Ceci explique pourquoi QUIC a été inclus dans HTTP/3.
Le protocole QUIC (Quick UDP Internet Connections) a été créé par Google en 2012 et représente une évolution de UDP. Et comme, même dans QUIC, il n’y a pas de concept de connexion, toute perte d’un paquet n’affecte pas l’ensemble du flux, et donc la transmission, mais seulement le flux d’octets de ce paquet spécifique.
Ainsi, les performances s’améliorent : Google Cloud Platform a introduit QUIC dans les équilibreurs de charge, montrant une nette diminution des temps de chargement, sans aucune optimisation, mais seulement en changeant le protocole.
Quel apport en termes de Cybersécurité pour HTTP/3 ?
Comme l’avons vu précédemment, QUIC s’appuie sur UDP au niveau de la conception, mais s’en distingue par de nombreuses caractéristiques importantes, notamment en termes de sécurité. Par exemple, il prend en charge le cryptage via TLSvc3 par défaut, faisant ainsi de HTTP/3 un « HTTPS » natif.
En outre, QUIC étend le cryptage à la plupart des informations de son en-tête et de sa charge utile, là où TCP exposait beaucoup trop de champs. Sans compter qu’il dispose de solutions de sécurité qui sont le fruit d’une étude approfondie des attaques les plus couramment utilisées ces dernières années.
Par exemple, QUIC se targue d’une forme de protection contre les attaques par rejeu, car il est capable de reconnaître les copies des mêmes valeurs dérivées des clés cryptographiques, en les rejetant au niveau du serveur. En outre, grâce à un système de validation des adresses, QUIC limite les possibilités d’usurpation d’adresse IP.
Une aide précieuse, en somme, pour le monde de la cybersécurité.
Les limites de la sécurité du protocole
La technologie de QUIC, et donc de HTTP/3, semble donc également solide sur le plan de la sécurité, mais certains aspects suscitent des doutes légitimes.
Ainsi, dans une étude réalisée en 2015, des chercheurs de Georgia Tech ont démontré que QUIC pouvait être victime d’une attaque de type Server Config Replay Attack, dont les conséquences ne toucheraient pas l’intégrité et la confidentialité des données, passant plutôt dans le domaine du déni de service. Avec une telle attaque, les performances de la connexion seraient dégradées, et de beaucoup.
À cet égard, certains spéculent également sur le fait que le QUIC n’est pas à l’abri d’une attaque DDoS, réalisée par une attaque par amplification UDP.
C’est pour cette raison que HTTP/3 intègre un système de limitation du trafic et une validation à court terme des jetons de connexion, qui peuvent constituer des méthodes d’atténuation valables.
Un avenir incertain
La principale préoccupation concernant la sécurité de HTTP/3 est liée à sa mise en œuvre pratique. C’est-à-dire le processus qui permettra lentement d’imposer le protocole de manière homogène.
Le fait est qu’à l’heure actuelle HTTP/3 est très peu soutenu. Il faudra beaucoup de temps et d’investissements pour garantir la création d’un cercle vertueux dans sa mise en œuvre, peut être même des années avant que les pare-feu, les proxies, les systèmes SIEM, etc. le prennent en charge.
En attendant, des astuces seront inévitablement utilisées pour faire coexister HTTP/2, voire HTTP/1.1 ou même HTTP/1.0, avec le nouveau venu. Il y aura une longue période d’avances et de rétrogradations de connexions sur lesquelles il n’y aura pratiquement aucune vision, ce qui entraînera d’éventuelles vulnérabilités.
Nonobstant le fait que HTTP/3 est et reste un protocole encore « expérimental », seule l’épreuve du temps permettra de déterminer les failles de sécurité auxquelles nous devrons faire face. Car, comme nous le savons, aucune technologie ne peut être considérée comme sûre de manière pérenne.
