La société Mozilla a annoncé l'activation pour les utilisateurs de la version stable de Firefox du mécanisme ECH (Encrypted Client Hello), poursuivant le développement de la technologie ESNI (Encrypted Server Name Indication) et visant à chiffrer les informations sur les paramètres des sessions TLS, telles que le nom de domaine demandé. Le code pour le fonctionnement de l'ECH a été initialement intégré dans la version 85 de Firefox, mais était désactivé par défaut. Dans Chrome, le support de l'ECH a été progressivement activé, à partir de la version 115 de Chrome.
Étant donné qu'en plus de la connexion à serveur la fuite d'informations sur les domaines demandés se produit via le DNS, pour une protection complète, en plus de l'ECH, l'application de la technologie DNS over HTTPS ou DNS over TLS est nécessaire pour chiffrer le trafic DNS. Firefox n'utilisera pas l'ECH sans l'activation de DNS over HTTPS dans les réglages. Vous pouvez vérifier le support de l'ECH dans le navigateur sur cette page.
L'un des facteurs de l'activation par défaut du support de l'ECH dans Firefox a été l'activation il y a quelques jours par Cloudflare de la prise en charge de l'ECH dans son réseau de distribution de contenu. D'un point de vue pratique, puisque les données sur les hôtes demandés sont cachées de l'analyse lors de l'application de l'ECH, pour filtrer et bloquer les sites indésirables utilisant le CDN Cloudflare, il sera désormais nécessaire de bloquer tout le réseau Cloudflare, de bloquer toutes les demandes avec ECH ou d'organiser l'interception HTTPS à l'aide de certificats racines falsifiés sur le système de l'utilisateur.
Initialement, pour permettre le fonctionnement de plusieurs sites HTTPS sur une même adresse IP, l'extension TLS SNI était utilisée, qui indiquait le nom de l'hôte demandé dans le message ClientHello, transmis avant l'établissement du canal de communication chiffré. Cette fonctionnalité permettait, à un stade précoce du traitement de la connexion, de distribuer les demandes entre des hôtes virtuels, mais permettait également à l'opérateur Internet de filtrer sélectivement le trafic HTTPS et d'analyser quels sites l'utilisateur visitait, ce qui ne permettait pas d'atteindre une confidentialité totale lors de l'utilisation de HTTPS.
Pour résoudre ce problème et éviter les fuites d'informations concernant le site demandé, une extension appelée ESNI a été proposée, mettant en œuvre le cryptage des données avec le nom d'hôte. Lors de la mise en œuvre d'ESNI, il a été constaté que le mécanisme proposé ne couvre pas toutes les sources possibles de fuite de données concernant l'hôte, et son application est insuffisante pour garantir la confidentialité totale des sessions HTTPS. En particulier, lors de la reprise d'une session établie auparavant, le nom de domaine était toujours transmis en clair parmi les paramètres de l'extension TLS PSK (Pre-Shared Key). De plus, les tentatives de mise en œuvre d'ESNI ont révélé des problèmes de compatibilité et d'évolutivité qui empêchaient la diffusion généralisée d'ESNI.
Compte tenu des lacunes identifiées d'ESNI, un nouveau mécanisme universel appelé ECH a été développé, permettant le cryptage des paramètres de toutes les extensions TLS. Techniquement, la principale différence entre ECH et ESNI est que, au lieu de seuls champs distincts, l'ensemble du message ClientHello est crypté. ECH implique la division de ClientHello en deux messages distincts : un message crypté ClientHelloInner (SNI Inner) et un message de base non crypté ClientHelloOuter (SNI Outer). Dans le SNI Outer non crypté, des données qui ne compromettent pas la confidentialité, telles que la version TLS et la liste des chiffrements utilisés, sont transmises, ainsi que le nom de domaine générique qui ne se croise pas avec le nom de domaine demandé. Par exemple, pour tous les clients de Cloudflare, le SNI Outer non crypté indique l'hôte générique «cloudflare-ech.com», tandis que le nom de l'hôte demandé est transmis dans le SNI Inner crypté et n'est pas accessible pour analyse.
ECH utilise également un autre schéma de distribution des clés pour le cryptage : l'information sur la clé publique est transmise dans les enregistrements DNS HTTPSSVC, et non dans des enregistrements de type TXT. Pour obtenir et crypter la clé, un cryptage de bout en bout authentifié basé sur le mécanisme HPKE (Hybrid Public Key Encryption) est utilisé. ECH prend également en charge la retransmission sécurisée de la clé depuis le serveur, ce qui peut être appliqué en cas de rotation des clés. le serveur et pour résoudre les problèmes lors de l'obtention des anciennes clés à partir du cache DNS.
Source : opennet.ru
