Mozilla a annoncé l'inclusion de la prise en charge pour les utilisateurs de la branche stable de Firefox pour le mécanisme ECH (Encrypted Client Hello), qui poursuit le développement de la technologie ESNI (Encrypted Server Name Indication) et est conçu pour crypter les informations sur les paramètres des sessions TLS. , tel que le nom de domaine demandé. Le code permettant de travailler avec ECH a été initialement ajouté à la version Firefox 85, mais a été désactivé par défaut. Chrome a progressivement commencé à inclure la prise en charge d'ECH à partir de la sortie de Chrome 115.
En plus de se connecter avec serveur Les informations du domaine demandé sont divulguées via DNS. Pour une protection complète, en plus d'ECH, vous devez utiliser DNS sur HTTPS ou DNS sur TLS pour chiffrer le trafic DNS. Firefox n'utilisera pas ECH si DNS sur HTTPS n'est pas activé dans ses paramètres. Vous pouvez vérifier la compatibilité d'ECH avec votre navigateur sur cette page.
L'un des facteurs qui ont activé la prise en charge ECH par défaut dans Firefox a été l'inclusion par Cloudflare de la prise en charge ECH dans son réseau de diffusion de contenu il y a quelques jours. Côté pratique, puisque les données sur les hôtes demandés lors de l'utilisation d'ECH sont cachées à l'analyse, filtrer et bloquer les sites indésirables à l'aide de Cloudflare CDN nécessitera désormais de bloquer l'ensemble du réseau Cloudflare, de bloquer toutes les requêtes d'ECH, ou d'organiser l'interception HTTPS à l'aide de faux certificats racines. sur le système utilisateur.
Initialement, pour organiser le travail sur une adresse IP de plusieurs sites HTTPS, on utilisait l'extension TLS SNI, dans laquelle le nom de l'hôte demandé était indiqué dans le message ClientHello transmis avant d'établir un canal de communication crypté. Cette fonctionnalité a permis de répartir les requêtes entre les hôtes virtuels à un stade précoce du traitement de la connexion, mais a également permis du côté du FAI de filtrer sélectivement le trafic HTTPS et d'analyser les sites ouverts par l'utilisateur, ce qui ne permettait pas d'obtenir une confidentialité totale lors de l'utilisation. HTTPS.
Pour résoudre ce problème et éviter la fuite d'informations sur le site demandé, une extension ESNI a ensuite été proposée qui implémente le cryptage des données avec le nom d'hôte. Lors de la mise en œuvre d'ESNI, il a été révélé que le mécanisme proposé ne couvre pas toutes les sources possibles de fuite de données de l'hôte et que son utilisation n'est pas suffisante pour garantir une confidentialité totale des sessions HTTPS. En particulier, lors de la reprise d'une session précédemment établie, le nom de domaine en clair continuait à être précisé parmi les paramètres de l'extension TLS PSK (Pre-Shared Key). En outre, les efforts visant à mettre en œuvre ESNI ont identifié des problèmes de compatibilité et de mise à l’échelle qui ont empêché une adoption généralisée d’ESNI.
Compte tenu des lacunes identifiées d'ESNI, un nouveau mécanisme ECH universel a été développé qui permet le cryptage des paramètres de toutes les extensions TLS. Techniquement, la principale différence entre ECH et ESNI est qu'au lieu de champs individuels, l'intégralité du message ClientHello est cryptée en une seule fois. ECH implique de diviser le ClientHello en deux messages distincts : le message ClientHelloInner chiffré (SNI Inner) et le message ClientHelloOuter sous-jacent non chiffré (SNI Outer). Un SNI externe non chiffré contient des données non confidentielles telles que la version TLS et une liste des chiffrements utilisés, ainsi qu'un nom de domaine commun qui ne chevauche pas le nom réel du domaine demandé. Par exemple, pour tous les clients Cloudflare, le SNI externe non chiffré spécifie l'hôte commun « cloudflare-ech.com », mais le nom réel de l'hôte demandé est transmis dans le SNI interne chiffré et n'est pas disponible pour analyse.
ECH utilise également un schéma de distribution des clés de chiffrement différent : les informations de clé publique sont transmises via des enregistrements DNS HTTPSSVC plutôt que TXT. Un chiffrement de bout en bout authentifié, basé sur le mécanisme HPKE (Hybrid Public Key Encryption), est utilisé pour obtenir et chiffrer la clé. ECH prend également en charge la retransmission sécurisée de la clé depuis le serveur, ce qui peut s'avérer utile en cas de rotation des clés. serveur et de résoudre les problèmes liés à la récupération des clés obsolètes dans le cache DNS.
Source: opennet.ru
