La plupart des communications sur Internet sont actuellement chiffrées, afin d’assurer que leur contenu est uniquement intelligible pour les points de terminaison (c'est-à-dire le client et le serveur). Toutefois, le chiffrement nécessite une clé, et les points de terminaison doivent donc s’accorder sur une clé de chiffrement, et cela, sans révéler la clé à des auteurs d’attaques potentiels. Le protocole de chiffrement le plus fréquemment utilisé à cette fin, appelé échange de clés, est la négociation Transport Layer Security (TLS).
Dans cette publication, nous allons étudier Encrypted Client Hello (ECH), une nouvelle extension pour TLS qui promet d'améliorer considérablement la confidentialité de ce protocole Internet essentiel. Aujourd'hui, un certain nombre de paramètres sensibles à la confidentialité de la connexion TLS sont négociés sans chiffrement. Les observateurs du réseau ont ainsi accès à une mine de métadonnées, notamment aux identités des points de terminaison, à la façon dont ils utilisent la connexion, etc.
ECH chiffre l'ensemble de la négociation, afin que ces métadonnées restent secrètes. Un avantage crucial est que cette approche permet de combler une faille de confidentialité connue de longue date en protégeant l'indication du nom du serveur (SNI) contre les écoutes clandestines sur le réseau. Le chiffrement du secret du SNI est important, car il constitue l'indication la plus claire du serveur avec lequel communique un client donné. Toutefois, et c'est peut-être plus important encore, ECH pose également les fondations de l'ajout de futures fonctionnalités de sécurité et améliorations des performances de TLS, tout en minimisant leur impact sur la confidentialité des données des utilisateurs finaux.
ECH est le fruit d’une étroite collaboration, facilitée par la communauté IETF, entre les milieux universitaires et les leaders de l’industrie technologique, notamment Cloudflare, nos amis de Fastly et Mozilla (tous deux affiliés aux co-auteurs de la norme) et bien d’autres. Cette fonctionnalité représente une mise à jour importante du protocole TLS et repose sur des technologies de pointe, telles que DNS-over-HTTPS, qui commencent juste à révéler tout leur intérêt. À l’heure actuelle, le protocole n’est donc pas encore prêt pour un déploiement à l’échelle d’Internet. Cette publication est destinée à offrir des indications sur le chemin vers le chiffrement de l’ensemble de la négociation.
Contexte
L’histoire du protocole TLS est l’histoire d’Internet. Le protocole a évolué, à la mesure de notre dépendance vis-à-vis d’Internet, pour répondre aux exigences opérationnelles, aux scénarios d’utilisation et aux modèles de menaces continuellement changeants. Le client et le serveur n’échangent pas simplement une clé ; ils négocient de nombreux paramètres et fonctionnalités différents, tels que la méthode exacte d’échange de clés, l’algorithme de chiffrement, les utilisateurs authentifiés et la méthode d’authentification utilisée, le protocole de couche d’application utilisé après la négociation et bien davantage. Tous ces paramètres ont, d’une manière ou d’une autre, une incidence sur les propriétés de sécurité du canal de communication.
Le SNI est un excellent exemple d’un paramètre qui affecte la sécurité du canal. L’extension SNI est utilisée par le client pour indiquer au serveur quel site web il veut atteindre. Ceci est essentiel pour l'Internet moderne, car il est aujourd’hui fréquent que de nombreux serveurs d’origine résident derrière un opérateur TLS unique. Dans ce cas, l’opérateur utilise le SNI pour déterminer qui authentifiera la connexion : sans lui, il serait impossible de déterminer quel certificat TLS présenter au client. Le problème est que le SNI transmet au réseau l'identité du serveur d’origine auquel veut se connecter le client, ce qui permet potentiellement à des observateurs clandestins de déduire beaucoup d’informations sur leur communication. (Bien entendu, il existe d’autres moyens pour un observateur du réseau d’identifier le serveur d’origine : l’adresse IP du serveur d’origine, par exemple. Cependant, la colocalisation avec d’autres serveurs d'origine sur une même adresse IP rend beaucoup plus difficile l’identification du serveur d'origine avec cet indicateur que par la simple inspection du SNI.)
Bien que la protection du SNI constitue le principe fondamental d’ECH, il ne s’agit en aucun cas du seul paramètre de négociation sensible à la confidentialité qu'échangent le client et le serveur. Un autre paramètre est l’extension ALPN, qui est utilisée pour décider quel protocole de couche application sera utilisé lorsque la connexion TLS sera établie. Le client envoie la liste des applications qu’il prend en charge (qu’il s’agisse du protocole HTTPS, d’un client de messagerie, d'un logiciel de messagerie instantanée ou de la myriade d’autres applications qui utilisent TLS pour la sécurité du transport), et le serveur en sélectionne une parmi cette liste, puis envoie sa sélection au client. Le client et le serveur divulguent ainsi au réseau un signal clair de leurs capacités et de l’utilisation possible de la connexion.
Certaines fonctionnalités sont tellement sensibles à la confidentialité que leur inclusion dans la négociation est exclue. Une idée qui a été lancée consiste à remplacer l’échange de clés au cœur du protocole TLS par un échange de clés authentifié par mot de passe (PAKE). Cela permettrait d’utiliser l’authentification par mot de passe conjointement à l’authentification par certificat (ou à la place de celle-ci), ce qui rendrait le protocole TLS plus fiable et mieux adapté à des applications plus nombreuses. La question de la confidentialité est ici analogue à celle du SNI : les serveurs associent habituellement à chaque client un identifiant unique (par exemple, un nom d’utilisateur ou une adresse e-mail), qui est utilisé pour récupérer les informations d’identification du client ; et le client doit, d’une manière ou d’une autre, transmettre cette identité au serveur pendant la négociation. Si elles étaient envoyées sans être chiffrées, ces données à caractère personnel seraient facilement accessibles à d’éventuels observateurs du réseau.
Un ingrédient nécessaire pour remédier aux divulgations de données confidentielles est le chiffrement de la négociation, c’est-à-dire le chiffrement des messages de la négociation en plus des données de l’application. Cela paraît assez simple, mais cette solution présente un autre problème : comment le client et le serveur choisissent-ils une clé de chiffrement si, après tout, la négociation est elle-même un moyen d’échanger une clé ? Certains paramètres doivent être envoyés sans chiffrement, bien sûr. Aussi, l’objectif d’ECH est de chiffrer tous les paramètres de la négociation, excepté ceux qui sont essentiels à l’échange des clés.
Pour comprendre ECH et les choix de conception sur lesquels il repose, il est utile de connaître un peu l’histoire du chiffrement de la négociation dans le protocole TLS.
Chiffrement de la poignée de main dans le protocole TLS
Le protocole TLS ne comportait aucun chiffrement de la négociation avant la dernière version, TLS 1.3. À la suite des révélations de Snowden en 2013, la communauté IETF a commencé à réfléchir à des moyens de contrer la menace que constitue la surveillance de masse pour l’Internet ouvert. Lorsque le processus de normalisation de TLS 1.3 a débuté en 2014, un de ses objectifs intrinsèques était de chiffrer autant de données de la négociation que possible. Malheureusement, la norme finale n’applique pas le chiffrement de l’intégralité de la négociation, et plusieurs paramètres (notamment le SNI) sont toujours transmis sans chiffrement. Examinons de plus près la raison.
Le flux du protocole TLS 1.3 est illustré sur la Figure 1. Le chiffrement de la négociation débute dès que le client et le serveur calculent un nouveau secret partagé. Pour cela, le client transmet un partage de clé dans son message ClientHello, et le serveur répond en transmettant son partage de clé dans son message ServerHello. Après avoir échangé ces partages, le client et le serveur peuvent en déduire un secret partagé. Chaque message de négociation ultérieur est chiffré avec la clé de trafic de négociation, issue du secret partagé. Les données de l’application sont chiffrées avec une autre clé, appelée clé de trafic d’application, également issue du secret partagé. Ces clés dérivées ont des propriétés de sécurité différentes : pour le souligner, elles sont illustrées dans des couleurs différentes.
Le premier message de négociation chiffré est le message EncryptedExtensions du serveur. Le but de ce message est de protéger les paramètres de négociation confidentiels du serveur, notamment l’extension ALPN du serveur, qui contient l’application sélectionnée dans la liste ALPN du client. Les paramètres d’échange de clés sont transmis sans chiffrement dans les messages ClientHello et ServerHello.
Tous les paramètres de négociation du client, confidentiels ou non, sont transmis dans le message ClientHello. En examinant la Figure 1, vous réfléchissez peut-être à des moyens de retravailler la négociation de telle manière que certains paramètres puissent être chiffrés, peut-être au prix d’une latence supplémentaire (c’est-à-dire plus d’allers-retours sur le réseau). Cependant, les extensions telles que le SNI créent une sorte de « problème de l’œuf et de la poule ».
Le client ne chiffre aucune donnée avant d’avoir vérifié l’identité du serveur (c’est le rôle des messages Certificate et CertificateVerify) et tant que le serveur n'a pas confirmé qu’il connaît le secret partagé (rôle du message Finished). Ces mesures assurent que l’échange de clés est authentifié, empêchant ainsi les attaques de l’homme du milieu (MITM, Monster-in-the-Middle) lors desquelles l’adversaire usurpe l’identité du serveur auprès du client, d’une manière qui lui permet de déchiffrer les messages envoyés par le client. Puisque le SNI est requis par le serveur pour sélectionner le certificat, il doit être transmis avant que l’échange de clés soit authentifié.
En général, il est uniquement possible d’assurer la confidentialité des paramètres de négociation utilisés lors de l’authentification si le client et le serveur partagent déjà une clé de chiffrement. Mais d’où pourrait provenir cette clé?
Chiffrement de l’intégralité de la négociation aux prémices de TLS 1.3. Il est intéressant de noter que le chiffrement de l’ensemble de la négociation a autrefois été proposé comme une fonctionnalité essentielle de TLS 1.3. Dans les premières versions du protocole (draft-10, vers 2015), pendant la négociation, le serveur devait fournir au client une clé publique durable, que le client utiliserait ensuite pour le chiffrement de négociations ultérieures. (Ce concept est issu d’un protocole appelé OPTLS qui, à son tour, était emprunté à la proposition originale de QUIC.) Appelé « 0-RTT », ce mode avait pour objectif principal de permettre au client de commencer à transmettre les données de l’application avant la conclusion de la négociation. Il aurait en outre permis au client de chiffrer son premier envoi de messages de négociation après le message ClientHello, notamment ses propres messages EncryptedExtensions, qui pouvaient être utilisés pour protéger les paramètres confidentiels de négociation du client.
Cette fonctionnalité n’a finalement pas été incluse dans la norme finale (RFC 8446, publiée en 2018), principalement parce que la complexité qu'elle ajoutait dépassait son utilité. En particulier, elle ne fait rien pour protéger la négociation initiale, durant laquelle le client apprend la clé publique du serveur. Les paramètres nécessaires à l’authentification du serveur, comme le SNI, seraient toujours transmis sans chiffrement.
Néanmoins, ce système peut être considéré comme le précurseur d’autres mécanismes de chiffrement de la négociation, comme ECH, qui utilisent le chiffrement à clé publique pour protéger les paramètres confidentiels du message ClientHello. Le principal problème que doivent résoudre ces mécanismes est la diffusion des clés.
Avant ECH, il y avait (et il y a toujours !) ESNI
Le prédécesseur immédiat d’ECH était l’extension Encrypted SNI (ESNI). Comme son nom l’indique, l’objectif d’ESNI était d’assurer la confidentialité du SNI. Pour cela, le client devait chiffrer son extension SNI sous la clé publique du serveur et envoyer le texte chiffré au serveur. Le serveur tenterait de déchiffrer le texte chiffré avec la clé secrète correspondant à sa clé publique. Si le déchiffrage réussissait, le serveur établirait la connexion avec le SNI déchiffré. Dans le cas contraire, il annulerait simplement la négociation. Le flux général de ce protocole simple est illustré sur la Figure 2.
Pour la diffusion des clés, ESNI s’est appuyée sur un autre protocole vital : Domain Name Service (DNS). Pour utiliser ESNI pour se connecter à un site web, le client ajoutait à ses requêtes standard A/AAAA une requête d'enregistrement TXT contenant la clé publique ESNI. Par exemple, pour obtenir la clé pour crypto.dance, le client demanderait l'enregistrement TXT d'_esni.crypto.dance:
$ dig _esni.crypto.dance TXT +short
"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="
Le blob codé en base64 contient une clé publique ESNI et les paramètres connexes, tels que l’algorithme de chiffrement.
Mais quel intérêt offre le chiffrement du SNI si l'on divulgue simplement le nom du serveur aux observateurs du réseau via une requête DNS sous forme de texte non chiffré ? Ce déploiement d’ESNI est devenu réalisable avec l’introduction de DNS-over-HTTPS (DoH), qui permet le chiffrement des requêtes DNS transmises aux résolveurs qui fournissent le service DoH (1.1.1.1 est un exemple d’un tel service). Une autre fonctionnalité essentielle de DoH est qu’il fournit un canal authentifié pour la transmission de la clé publique ESNI du serveur DoH au client. Cela permet d’éviter les attaques par empoisonnement du cache lancées depuis le réseau local du client : en l’absence de DoH, l’auteur local d’une attaque pourrait empêcher le client de proposer l’extension ESNI en renvoyant un enregistrement TXT vide ou obliger le client à utiliser ESNI avec une clé qu'il contrôle.
Si ESNI a représenté un grand pas en avant, l'extension n’atteint pas l’objectif d’atteindre le chiffrement complet de la négociation. Outre le fait qu’elle est incomplète, puisqu’elle ne protège que le SNI, elle est vulnérable à un petit nombre d'attaques sophistiquées qui, bien que difficiles à exécuter, mettent en évidence, dans la conception du protocole, des faiblesses théoriques auxquelles il est impératif de remédier.
ESNI a été déployée par Cloudflare et mise en œuvre par Firefox, au choix des utilisateurs, en 2018. Cette expérience a mis en évidence certains des défis que comporte la dépendance à DNS pour la diffusion des clés. Cloudflare modifie sa clé ESNI toutes les heures, afin de minimiser les dommages collatéraux dans l’éventualité où une clé serait compromise. Les artefacts DNS sont parfois mis en cache beaucoup plus longtemps, ce qui signifie qu’il y a de bonnes chances qu’un client dispose d’une clé publique obsolète. Bien que le service ESNI de Cloudflare ait une certaine tolérance à cet égard, chaque clé doit expirer, tôt ou tard. La question que le protocole ESNI laisse sans réponse est de savoir comment le client doit procéder si le déchiffrement échoue et il ne parvient pas à accéder à la clé publique actuelle via DNS ou autrement.
Un autre problème lié à l’utilisation de DNS pour la diffusion des clés est que plusieurs points de terminaison peuvent faire autorité pour un même serveur d’origine, mais avoir des capacités différentes. Par exemple, une requête concernant l’enregistrement « exemple.com » pourrait renvoyer l’une de deux adresses IP différentes, chacune gérée par un CDN différent. L’enregistrement TXT associé à « _esni.exemple.com » contiendrait la clé publique d’un de ces CDN, mais certainement pas les deux. Le protocole DNS ne permet pas de lier au niveau atomique des enregistrements de ressources correspondant à un même point de terminaison. En particulier, il est possible qu’un client fournisse par inadvertance l’extension ESNI à un point de terminaison qui ne la prend pas en charge, entraînant l’échec de la négociation. Pour résoudre ce problème, il est nécessaire de modifier le protocole DNS. (Plus d’informations ci-dessous.)
L'avenir d'ESNI. Dans la section suivante, nous allons décrire la spécification ECH et la manière dont elle comble les lacunes d'ESNI. En dépit de ses limites, ESNI offre un avantage concret considérable en matière de protection de la confidentialité. Cloudflare a l'intention de poursuivre la prise en charge d'ESNI jusqu'à ce qu'ECH soit prêt pour la production.
Les tenants et aboutissants d’ECH
L’objectif d’ECH est de chiffrer l’intégralité du message ClientHello, et ainsi, de combler la faille restée ouverte dans TLS 1.3 et ESNI en protégeant tous les paramètres confidentiels de la négociation. Comme ESNI, le protocole utilise une clé publique, diffusée via DNS et obtenue avec DoH, pour le chiffrement du premier message du client. Cependant, ECH apporte des améliorations à la diffusion des clés qui rendent le protocole moins sensible aux incohérences de cache DNS. Alors que le serveur ESNI interrompt la connexion en cas d’échec du déchiffrement, le serveur ECH tente de finaliser la négociation et de fournir au client une clé publique qu’il peut utiliser pour réessayer d’établir une connexion.
Mais comment le serveur peut-il finaliser la négociation s’il n’est pas en mesure de déchiffrer le message ClientHello ? Comme l’illustre la Figure 3, le protocole ECH implique en réalité deux messages ClientHello : le message ClientHelloOuter, envoyé sans chiffrement, comme d’habitude ; et le message ClientHelloInner, chiffré et envoyé en tant qu’extension du message ClientHelloOuter. Le serveur finalise la négociation avec un de ces messages ClientHello : si le déchiffrement réussit, il poursuit avec le message ClientHelloInner ; sinon, il poursuit avec le message ClientHelloOuter.
Le message ClientHelloInner contient les paramètres de négociation que le client souhaite utiliser pour la connexion. Ces paramètres incluent les valeurs confidentielles, telles que le SNI du serveur d’origine qu’il veut atteindre (appelé serveur principal en langage ECH), la liste ALPN, etc. Le message ClientHelloOuter, bien qu’il soit également un message ClientHello à part entière, n’est pas utilisé pour la connexion prévue. Au lieu de cela, la négociation est finalisée par le fournisseur de services ECH lui-même (appelé serveur côté client), ce qui signale au client que sa destination prévue n’a pas pu être atteinte en raison d’un échec du déchiffrement. Dans ce cas, le fournisseur de services transmet également la clé publique ECH correcte, avec laquelle le client peut réessayer de conclure la négociation, « corrigeant » ainsi la configuration du client. (Ce mécanisme est similaire à la manière dont le serveur diffusait sa clé publique pour le mode 0-RTT au lancement de TLS 1.3.).
Au minimum, les deux messages ClientHello doivent contenir les paramètres de négociation nécessaires pour un échange de clés authentifié par le serveur. En particulier, alors que le message ClientHelloInner contient le SNI réel, le message ClientHelloOuter contient également une valeur SNI que le client s’attend à vérifier en cas d’échec du déchiffrement ECH (c’est-à-dire le serveur côté client). Si la connexion est établie avec le message ClientHelloOuter, le client doit immédiatement interrompre la connexion et réessayer de conclure la négociation avec la clé publique fournie par le serveur. Il n’est pas nécessaire que le client spécifie une liste ALPN dans le message ClientHelloOuter, ni aucune autre extension utilisée pour guider le comportement après la négociation. Tous ces paramètres sont encapsulés dans le message ClientHelloInner chiffré.
Ce concept permet de relever (et de manière assez élégante, je pense) la plupart des défis inhérents au déploiement sécurisé du chiffrement de la négociation, auxquels se heurtaient les mécanismes précédents. Il est important de noter que le concept d'ECH n’a pas été élaboré sans raison. Le protocole reflète les perspectives variées de la communauté IETF, et son développement est lié à celui de deux autres normes cruciales au succès d’ECH.
La première est une nouvelle fonctionnalité DNS importante, appelée type d’enregistrement de ressource HTTPS. Dans les grandes lignes, ce type d’enregistrement est conçu pour permettre à plusieurs points de terminaison HTTPS faisant autorité pour un même nom de domaine de publier différentes fonctionnalités pour le protocole TLS. Ceci permet de se fier à DNS pour la diffusion des clés, et ainsi, de résoudre une des problématiques de déploiement mises en évidence par le déploiement initial d’ESNI. Pour étudier ce nouveau type d’enregistrement dans le détail et comprendre sa signification pour Internet en général, consultez la récente publication de blog d’Alessandro Ghedini à ce sujet.
La deuxième est la norme Hybrid Public Key Encryption (HPKE) du forum CFRG, qui spécifie une infrastructure extensible pour la création de systèmes de chiffrement de clés publiques adaptés à de nombreuses applications différentes. En particulier, ECH délègue tous les détails de son mécanisme de chiffrement de négociation à HPKE, rendant ainsi la spécification considérablement plus simple et facile à analyser. (À ce sujet, HPKE est également une des principales composantes d’Oblivious DNS-over-HTTPS.
Le chemin qui nous attend
La spécification ECH actuelle est l’aboutissement d’une collaboration pluriannuelle. À ce stade, le concept global du protocole est assez stable ; d’ailleurs, le projet de spécification actuel sera le premier à être ciblé, parmi les déploiements, aux fins des tests d’interopérabilité. Il reste néanmoins un certain nombre de détails à régler. Concluons cette publication avec un bref aperçu du chemin qui nous attend.
Résistance à l'analyse du trafic
En fin de compte, l’objectif d’ECH est d’assurer que les connexions TLS établies avec différents serveurs d’origine derrière un même fournisseur de services ECH sont indiscernables les unes des autres. En d’autres termes, lorsque vous vous connectez à un serveur d’origine derrière Cloudflare, aucune personne sur le réseau entre vous et Cloudflare ne devrait être en mesure de discerner quel serveur d’origine vous avez contacté, ni quels paramètres de négociation confidentiels le serveur d’origine et vous avez échangés. Outre l’amélioration immédiate de la confidentialité, cette propriété, si elle est mise en œuvre, ouvre la voie au déploiement de nouvelles fonctionnalités pour le protocole TLS, sans risque de compromettre la confidentialité.
Le chiffrement du message ClientHello est une étape importante pour atteindre cet objectif, mais nous devons faire un peu mieux. Un vecteur d’attaque important dont nous n’avons pas encore parlé est l’analyse du trafic. Il s’agit de la collecte et de l’analyse des propriétés du canal de communication qui révèlent une partie du contenu du texte chiffré, sans toutefois percer le schéma de chiffrement sous-jacent. Par exemple, la longueur du message ClientHello pourrait divulguer suffisamment d’informations sur le SNI pour qu’un adversaire puisse en évaluer la valeur (le risque est particulièrement élevé pour les noms de domaine qui sont soit particulièrement courts, soit particulièrement longs). Il est donc crucial que la longueur de chaque texte chiffré soit indépendante des valeurs des paramètres sensibles à la confidentialité. La spécification actuelle d’ECH prévoit quelques atténuations, mais leur portée est incomplète. Ainsi, l’amélioration de la résistance d’ECH à l’analyse du trafic est une orientation importante pour les travaux futurs.
Le spectre de l'ossification
Une question ouverte importante pour ECH est l'impact qu'elle aura sur l'exploitation du réseau.
Un des enseignements du déploiement de TLS 1.3 est que la mise à niveau d'un protocole Internet essentiel peut provoquer des comportements inattendus du réseau. Cloudflare a été l'un des premiers grands opérateurs TLS à déployer TLS 1.3 à grande échelle. Lorsque des navigateurs comme Firefox et Chrome ont commencé à l'activer, à titre expérimental, ils ont observé un taux d'échec des connexions significativement plus élevé qu'avec TLS 1.2. La cause première de ces échecs était l'ossification du réseau, c'est-à-dire la tendance qu'ont lesboîtiers intermédiaires (c'est-à-dire les appareils réseau présents entre les clients et les serveurs, qui surveillent et interceptent parfois le trafic) à écrire des logiciels qui prévoient que le trafic aura une apparence et un comportement spécifiques. La modification du protocole avant la mise à jour du logiciel des boîtiers intermédiaires a conduit ces derniers à tenter d'analyser des paquets qu'ils ne reconnaissaient pas, provoquant des bugs logiciels qui, dans certains cas, entraînaient l'interruption totale des connexions.
Ce problème était si répandu qu'au lieu d'attendre la mise à jour des logiciels des opérateurs de réseaux, le concept de TLS 1.3 a été modifié dans le but d'atténuer l'impact de l'ossification du réseau. La solution ingénieuse a consisté à donner à TLS 1.3 « l'apparence » d'un autre protocole, que les boîtiers intermédiaires sont connus pour tolérer. Plus précisément, le format de câble et même le contenu des messages de négociation ont été conçus pour ressembler à TLS 1.2. Ces deux protocoles ne sont pas identiques, bien sûr (un observateur du réseau curieux peut toujours les distinguer), mais ils se ressemblent et se comportent assez similairement pour assurer que la majorité des boîtiers intermédiaires existants ne les traitent pas différemment. Empiriquement, il a été révélé que cette stratégie réduisait considérablement le taux d'échecs de connexion, et suffisamment pour rendre viable le déploiement de TLS 1.3.
Une fois encore, ECH représente une mise à niveau significative pour TLS, menacé par le spectre de l'ossification du réseau. Le message ClientHello contient des paramètres, tels que le SNI, qui existent depuis longtemps dans la négociation, et nous ne savons pas encore quel sera l'impact de leur chiffrement. En prévision des problèmes de déploiement que pourrait causer l'ossification, le protocole ECH a été conçu pour ressembler autant que possible à une négociation TLS 1.3 standard. La différence la plus notable est l'extension ECH elle-même : si les boîtiers intermédiaires l'ignorent (comme ils le devraient, s'ils sont conformes à la norme TLS 1.3), le reste de la négociation se déroulera comme d'habitude.
Il reste à voir si cette stratégie sera suffisante pour assurer un déploiement à grande échelle d'ECH. Si c'est le cas, il convient de noter que cette nouvelle fonctionnalité aidera à atténuer l'impact des futures mises à niveau de TLS sur l'exploitation des réseaux. Le chiffrement de l'ensemble de la négociation réduit le risque d'ossification, car cela signifie qu'il existe des fonctionnalités de protocole moins visibles susceptibles de provoquer l'ossification des logiciels. Nous pensons que cela sera bénéfique à la santé d'Internet dans son ensemble.
Conclusion
L'ancienne négociation TLS comporte des fuites de données (involontaires). Les exigences opérationnelles du client et du serveur ont conduit à la négociation de paramètres sensibles à la confidentialité, comme le SNI, sans chiffrement, ce qui les rend accessibles aux observateurs du réseau. L'extension ECH vise à combler cette lacune en permettant le chiffrement de l'ensemble de la négociation. Cela représente une mise à niveau significative de TLS, qui contribuera à préserver la confidentialité des données des utilisateurs finaux à mesure que le protocole continue d'évoluer.
La norme ECH est un travail en cours. Tandis que ce travail se poursuit, Cloudflare s’engage à tout mettre en œuvre pour s’assurer que cette mise à niveau importante pour le protocole TLS atteindra un déploiement à l’échelle d’Internet.