Les défis à venir pour HTTP/3

Si vous avez suivi ma série de billets sur les avantages de HTTP/3 (QUIC) par rapport à HTTP/2 (TCP), vous pensez peut-être que ces nouveaux protocoles semblent trop beaux pour être vrais. Ils améliorent les performances, renforcent la sécurité et la confidentialité et constituent une base parfaite pour des expérimentations et des améliorations à l'épreuve du temps dans les années à venir. Pourtant, ces protocoles ont également fait l'objet de nombreuses critiques, pour plusieurs raisons, que j'aborderai dans ce dernier article.

Une critique courante de HTTP/3 et de QUIC est qu'ils profitent principalement aux grands acteurs et aux grandes entreprises (par exemple, Google et Meta), qui contrôlent souvent un ou même deux des points d'extrémité (par exemple, Google contrôle des services populaires tels que YouTube et la recherche, ainsi que Chrome, le navigateur Web le plus utilisé). Le chiffrement du trafic de manière à ce qu'il ne soit plus visible ou utilisable par des parties intermédiaires ne pose donc pas de problème à ces entreprises : de toute façon, elles ne travaillent qu'au niveau des points d'extrémité. En revanche, les entités telles que les fournisseurs d'accès à Internet (FAI), les sociétés d'hébergement ou les gouvernements, qui opèrent au "milieu" du réseau, se sentent à juste titre exclues de cette démarche.

Dans certains cas, les discussions sont relativement innocentes. Par exemple, les fournisseurs de réseaux se plaignent qu'il est difficile de mesurer les performances du QUIC ou de résoudre les problèmes qu'il pose sur leur réseau. Ils ont longtemps fait pression sur l'IETF (Internet Engineering Task Force) pour obtenir qu'un bit unique soit attribué dans l'en-tête des paquets QUIC (appelé "spinbit"), ce qui leur permet d'avoir une certaine visibilité sur le comportement du protocole. Malheureusement, pour utiliser correctement le spinbit dans les réseaux, il doit être pris en charge et défini par les terminaux et, par exemple, Google a (jusqu'à présent) refusé de l'implémenter dans Chrome ou sur ses serveurs, invoquant des raisons (à mon avis douteuses) de protection de la vie privée.

Dans d'autres cas, les problèmes sont un peu plus importants. Le cryptage important de QUIC signifie également qu'il est plus difficile de mettre en place un pare-feu, car il est plus difficile de discerner les vraies connexions des fausses, et des signaux importants tels que les fermetures de connexion ne peuvent plus être observés directement. Si les pare-feux peuvent (à mon avis) encore faire une grande partie de leur travail pour QUIC dans la pratique (même des choses comme l'inspection approfondie des paquets (DPI) et l'interception de la sécurité de la couche de transport (TLS) sont encore possibles), cela nécessite des changements significatifs dans leurs implémentations, ce que de nombreux fournisseurs de pare-feux ont été lents à faire. C'est pourquoi de nombreux fournisseurs recommandent de désactiver complètement QUIC pour l'instant, car les navigateurs reviennent automatiquement à HTTP/2 sur TCP dans ce cas.

Dans certains cas, cependant, les discussions portent sur des sujets tout à fait fondamentaux. Par exemple, de nombreuses parties affirment que les nouveaux protocoles permettront aux criminels d'échapper plus facilement à certaines mesures d'application de la loi. Ou, de manière similaire mais un peu moins flagrante, qu'ils permettront aux enfants de se soustraire plus facilement à des dispositifs tels que les contrôles parentaux et le filtrage de contenu. Toutefois, ces discussions ne portent pas directement sur QUIC ou HTTP/3, mais sur les efforts de "DNS crypté" et de "Client Hello crypté". Ces deux technologies permettent d'obscurcir davantage les sites web que les utilisateurs tentent de visiter.

Pour clarifier, le système de noms de domaine (DNS) traduit le nom d'un site web en adresse IP. L'indication du nom du serveur (SNI) dans le TLS Client Hello permet aux utilisateurs de choisir un nom de site web spécifique si un seul serveur en héberge plusieurs, ce qui est courant. Ces deux opérations sont souvent effectuées en clair, de sorte que les intermédiaires du réseau peuvent les lire et les manipuler ou bloquer les sites web qu'ils jugent indésirables (elles sont également souvent utilisées pour fournir des fonctions telles que la tarification zéro pour les services populaires, une épine dans l'œil des partisans de la neutralité du réseau).

Le DNS chiffré et le Client Hello chiffré ne sont cependant pas spécifiques à QUIC ou HTTP/3, car ils peuvent (et seront) utilisés avec TCP et HTTP/2. Cela concerne principalement les puristes du protocole et ne constitue pas un argument convaincant pour ceux qui s'inquiètent de la perte croissante de contrôle sur "leurs" réseaux. Les discussions ici sont principalement de nature éthique, les concepteurs de protocoles poussant généralement pour une liberté individuelle maximale des utilisateurs finaux et les gouvernements et autres parties souhaitant garder un certain contrôle (voir aussi : les applications de messagerie cryptées et les portes dérobées potentielles pour les forces de l'ordre). Néanmoins, les participants à l'IETF ne sont pas complètement sourds à ces préoccupations et des propositions ont été faites pour permettre la désactivation de ces fonctionnalités sur certains réseaux.

De nombreux opposants à ces efforts prétendent qu'ils servent une intention néfaste de Google et consorts (puisque QUIC a été développé à l'origine chez Google) de "prendre le contrôle" de l'Internet d'une manière ou d'une autre. En ce qui concerne ces affirmations, je peux dire qu'elles sont totalement fausses.

Alors que Google a lancé QUIC, il a été transféré à l'IETF, où de nombreux autres ingénieurs ont contribué à faire de sa conception ce qu'elle est aujourd'hui. Bien sûr, nombre de ces ingénieurs travaillent dans d'autres grandes entreprises telles qu'Apple ou Meta. Mais d'autres viennent d'entreprises telles que Mozilla (connue pour sa défense des utilisateurs finaux) et du monde universitaire (comme moi).

En outre, tous les travaux de l'IETF sont réalisés de manière ouverte et tous les documents et artefacts sont accessibles au public. Cela ne signifie pas qu'il n'y a pas eu d'agenda d'entreprise derrière certaines décisions ou propositions, mais c'est loin d'être de la collusion.

Cependant, bien qu'il n'y ait pas de complot diabolique dans ces configurations, on ne peut nier que l'internet devient de plus en plus centralisé, avec une grande partie de l'infrastructure et des services critiques de l'internet contrôlés et hébergés par un petit nombre de grandes entreprises. C'est également la raison pour laquelle HTTP/3 a connu un tel succès relatif, car cette douzaine d'entreprises représente une part importante de la distribution du trafic Internet.

Je pense que cette évolution présente des avantages et des inconvénients, car il y a certainement des avantages en termes de performance et de respect de la vie privée pour les utilisateurs finaux. D'un autre côté, ces avantages prennent fin dès que les données arrivent sur les serveurs de ces entreprises, et peut-être qu'à long terme, ces risques pour la vie privée s'avéreront plus importants que ceux que nous pourrions subir de la part des intermédiaires de réseau.

En pesant les avantages et les inconvénients, je pense que HTTP/3 et QUIC sont là pour rester. Ils ont été conçus pour être à l'épreuve du temps et facilement évolutifs dans les années et décennies à venir. Même aujourd'hui, ils servent de base à des protocoles plus spécialisés tels que WebTransport, MASQUE et Media-over-QUIC, qui offrent des avantages supplémentaires pour des cas d'utilisation spécifiques.

Je pense que la poursuite de la tendance à un contrôle accru de l'utilisateur final et/ou à une centralisation plus poussée du web dépendra largement des mesures que les gouvernements décideront de prendre. Nous avons déjà vu des législations et des mesures ayant un impact sur ces sujets (par exemple, le GDPR et le grand firewall de Chine), et d'autres sont en cours de discussion.

Il appartiendra à l'histoire de décider si les contributeurs de l'IETF se révèlent être des combattants de la liberté ou des tyrans d'entreprise. Mais en attendant, nous disposons d'une nouvelle technologie cool avec laquelle jouer dans HTTP/3 et QUIC. Prenez cela comme vous voulez ;).

Robin Marx est expert en protocoles et performances web chez Akamai. Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l'Internet Society.