Auteur Sujet: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet  (Lu 12988 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 39 198
    • Twitter LaFibre.info
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #24 le: 27 janvier 2021 à 14:22:30 »
Une traduction rapide pour ceux que cela intéresse :

ECH (Encrypted Client Hello): l'avenir d'ESNI dans Firefox

Écrit par Kevin Jacobs, le 7 janvier 2021

Contexte

Il y a deux ans, nous avons annoncé la prise en charge expérimentale de l'extension ESNI (Encrypted Server Name Indication) protégeant la confidentialité dans Firefox Nightly. L'extension Server Name Indication (SNI) permet la sélection du bon certificat TLS en transmettant une copie en texte clair du nom d'hôte du serveur, dans le message "Hello" du client TLS. Cela représente une fuite de confidentialité similaire à celle du DNS, et tout comme DNS-over-HTTPS empêche les requêtes DNS d'exposer le nom d'hôte aux observateurs sur chemin, ESNI tente d'empêcher les fuites de nom d'hôte à partir de la négociation TLS elle-même.

Depuis la publication du projet de spécification d'ESNI à l'IETF, l'analyse a montré que le chiffrement uniquement de l'extension SNI fournit une protection incomplète. À titre d'exemple: lors de la reprise de session, l'extension de clé pré-partagée pourrait contenir une copie en texte clair du même nom de serveur chiffré par ESNI. L'approche ESNI nécessiterait une variante cryptée de chaque extension avec des implications potentielles sur la confidentialité, et même cela expose l'ensemble des extensions annoncées. Enfin, l'utilisation d'ESNI dans le monde réel a exposé des problèmes d'interopérabilité et de déploiement qui l'ont empêchée d'être activée à une plus grande échelle.

Arrivée du Encrypted Client Hello (ECH)

Pour remédier aux lacunes d'ESNI, les versions récentes de la spécification ne chiffrent plus uniquement l'extension SNI et chiffrent à la place un message Client Hello entier (ainsi le nom passe de «ESNI» à «ECH»). Toutes les extensions ayant des implications sur la confidentialité peuvent désormais être reléguées à un «ClientHelloInner» chiffré, qui est lui-même annoncé comme une extension d'un «ClientHelloOuter» non chiffré. Si un serveur prend en charge ECH et décrypte avec succès, le client «interne» Hello est alors utilisé comme base pour la connexion TLS. Ceci est expliqué plus en détail dans l'excellent article de blog de Cloudflare sur ECH.

ECH modifie également la distribution des clés et les histoires de chiffrement: un serveur TLS prenant en charge ECH annonce désormais sa clé publique via un enregistrement DNS HTTPSSVC , alors qu'ESNI a utilisé des enregistrements TXT à cette fin. La dérivation et le chiffrement des clés sont rendus plus robustes, car ECH utilise la spécification Hybrid Public Key Encryption plutôt que de définir son propre schéma. Surtout, ECH ajoute également un mécanisme de nouvelle tentative pour augmenter la fiabilité en ce qui concerne la rotation des clés du serveur et la mise en cache DNS. Là où ESNI peut actuellement échouer après avoir reçu des clés obsolètes du DNS, ECH peut récupérer en toute sécurité, car le client reçoit les clés mises à jour directement du serveur.

ECH dans Firefox 85

Conformément à notre mission de protection de votre vie privée en ligne, Mozilla travaille activement avec Cloudflare et d'autres sur la normalisation de la spécification Encrypted Client Hello à l'IETF. Firefox 85 remplace ESNI par ECH draft-08, et une autre mise à jour de draft-09 (qui est ciblée pour des tests et un déploiement d'interopérabilité plus larges) est à venir.

Les utilisateurs qui ont précédemment activé ESNI dans Firefox peuvent remarquer que l'option about:config pour ESNI n'est plus présente. Bien que nous recommandons aux utilisateurs d'attendre que ECH soit activé par défaut, certains voudront peut-être activer cette fonctionnalité plus tôt. Cela peut être fait dans about:config en activant network.dns.echconfig.enabled et network.dns.use_https_rr_as_altsvc, ce qui permettra à Firefox d'utiliser ECH avec les serveurs qui le prennent en charge. Alors que ECH est en cours de développement actif, sa disponibilité peut être intermittente car il nécessite à la fois le client et le serveur pour prendre en charge la même version. Comme toujours, les paramètres exposés uniquement sous about:config sont considérés comme expérimentaux et sujets à changement. Pour l'instant, Firefox ESR continuera à prendre en charge la fonctionnalité ESNI précédente.

En conclusion, ECH est une évolution passionnante et robuste d'ESNI, et le support du protocole arrive dans Firefox. Nous travaillons dur pour nous assurer qu'il est interopérable et déployable à grande échelle, et nous sommes impatients que les utilisateurs réalisent les avantages de cette fonctionnalité en matière de confidentialité.

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 617
  • Chambly (60)
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #25 le: 27 janvier 2021 à 14:51:35 »
network.dns.upgrade_with_https_rr avait été activé sur nightly, et par exemple le chargement de http://ip.lafibre.info pouvait bloquer.
J'ai créé des bugs, qui ont été corrigés depuis, mais je ne sais pas quel est le statut sur la version stable.
https://bugzilla.mozilla.org/show_bug.cgi?id=1686611
https://bugzilla.mozilla.org/show_bug.cgi?id=1686828

network.dns.upgrade_with_https_rr, qui ne fonctionne qu'avec le DoH, récupère le "HTTPS record" DNS qui permet plusieurs choses, en plus de ECH évoqué ici :
 - rediriger le HTTP en HTTPS directement à l'aide du DNS.
Contrairement à https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security, ça ne nécessite pas une première connection en HTTP (donc c'est plus sécurisé), ou une inscription sur https://hstspreload.org pour être ajouté à la liste intégrée à Chrome/Firefox.
 - remplacer le header Alt-Svc (si network.dns.use_https_rr_as_altsvc est activé), pour dire que HTTP/3 est supporté par exemple
Ca semble actuellement nécessaire (en plus de network.http.http3.enabled) pour faire du HTTP/3 en IPv6 avec Cloudflare.
Cloudflare ne semble pas donner le header Alt-Svc en IPv6, alors qu'il est là en IPv4  ???

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 617
  • Chambly (60)
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #26 le: 13 juin 2021 à 02:51:48 »
https://crypto.cloudflare.com/cdn-cgi/trace/ permet de tester l'ECH maintenant (ce n'est activé que sur ce serveur, pas sur tout Cloudflare comme l'ESNI).
J'ai parfois "sni=encrypted", mais pas tout le temps.

A noter que Firefox ne supporte à priori pas encore ECH en QUIC (HTTP/3).

Sur about:networking#dnslookuptool, j'ai bien pour crypto.cloudflare.com :
1 crypto.cloudflare.com (alpn="h2" ipv4hint="162.159.135.79, 162.159.136.79" echConfig="0048FE0A0044DE00200020E7A8835B62302BB1696303E3E48942B870F80FDF853DEF0979765703E0D1596800040001000100000013636C6F7564666C6172652D65736E692E636F6D0000" ipv6hint="2606:4700:7::a29f:874f, 2606:4700:7::a29f:884f" )Il y a "echConfig".

Pour filtrer dans Wireshark : tls.handshake.extension.type==65034
Wireshark n'identifie pas l'extension, qui est encrypted_client_hello.
Le SNI envoyé en clair est cloudflare-esni.com, ce qui est effectivement différent du vrai SNI crypto.cloudflare.com.

vivien

  • Administrateur
  • *
  • Messages: 39 198
    • Twitter LaFibre.info
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #27 le: 13 juin 2021 à 08:41:35 »
Il y a quand même un SNI envoyé en clair dans ECH (Encrypted Client Hello) ?

Il sert à quoi ?

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 617
  • Chambly (60)
C'est expliqué sur https://blog.cloudflare.com/encrypted-client-hello/.
Avec ECH, il y a un ClientHelloOuter en clair, qui a un ClientHelloInner chiffré dans une extension.
Le ClientHelloOuter correspond à la connexion au "client-facing server", qui répondra en cas d'erreur de déchiffrement du ClientHelloInner.
Le echconfig obtenu via DNS contient le nom de ce serveur, et les paramètres de chiffrement ECH.

Le principe est que ce "client-facing server" sert pour plusieurs services. La spécification n'impose rien, mais plus ce nombre est important, plus il est difficile pour quelqu'un observant le traffic de deviner quel est le vrai service.
Là c'est juste un serveur de test, mais si Cloudflare utilise cloudflare-esni.com pour l'ensemble de ses services (ou par datacenter, ou groupe de serveurs correspondant aux IP), ça n'apportera pas plus d'informations que l'IP.
Mais le fait qu'il soit obligatoire d'indiquer le nom de ce serveur dans le SNI implique qu'il soit possible d'en avoir plusieurs sur une même IP, donc tout dépendra de ce qui est fait en pratique.

adhame95

  • Client Orange / Sosh 4G/5G
  • *
  • Messages: 141
  • Monaco
    • Facebook
c'est étrange je n'arrive pas à avoir ech : dans wireshark je vois bien dans sni crypto.cloudflare.com
alors que network.dns.echconfig.enabled et network.dns.use_https_rr_as_altsvc sont bien actifs
j'ai testé en ipv4 et ipv6

edit : cela fonctionne avec firefox nighly

en 1 et 2 c'est nighly
en 3 et 4 ESR
« Modifié: 13 juin 2021 à 13:19:47 par adhame95 »

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 617
  • Chambly (60)
Attention, il y a ton IP dans la réponse.

Même en désactivant network.dns.echconfig.fallback_to_origin_when_all_failed, il y a effectivement des moments pendant lesquels ça ne fonctionne pas.
Activer network.dns.use_https_rr_for_speculative_connection n'aide pas non plus.
Parfois je vois deux connexions en même temps, une avec ECH et l'autre sans.
Ça doit être un bug de Firefox, peut-être que même avec tous ces paramètres il n'utilise pas toujours le "HTTPS record" DNS qui contient l'echconfig.