La Fibre

Télécom => Réseau => reseau Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 24 mai 2019 à 11:07:41

Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 24 mai 2019 à 11:07:41
Edit : ECH (Encrypted Client Hello) est le successeur de ESNI (Encrypted SNI)

Citation de: vivien le 27 janvier 2021 à 14:22:30
ECH (Encrypted Client Hello): l'avenir d'ESNI dans Firefox

(https://lafibre.info/images/logo/logo_encrypted_client_hello.jpg)

É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 (https://datatracker.ietf.org/doc/draft-ietf-tls-esni/) 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 (https://blog.cloudflare.com/encrypted-client-hello/).

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.

Message d'origine de mai 2019 :


Aujourd'hui les outils de surveillance d'internet et les bridage DPI (Deep Packet Inspection soit L'inspection profonde de paquets) utilisent le SNI.

La chiffrement du SNI, via encrypted SNI, est l'arme ultime pour en finir avec les entraves de la neutralité et la surveillance d'internet.

J'ai traduit ci-dessous l’article Cloudflare du 24 septembre 2018, écrit par Alessandro Ghedini sur encrypted SNI :

Comment fonctionne encrypted SNI

(https://lafibre.info/images/ssl/logo_encrypted_sni.png)

Aujourd’hui, nous avons annoncé la prise en charge de encrypted SNI (SNI chiffré), une extension du protocole TLS 1.3 qui améliore la confidentialité des utilisateurs Internet en empêchant les observateurs sur le trajet, y compris les FAI, les propriétaires de café et les pare-feu, d’intercepter l’extension SNI (TLS Server Name Indication) pour déterminer quels sites Web les utilisateurs visitent.

L'utilisation d'encrypted SNI, associée aux autres fonctionnalités de sécurité Internet déjà offertes gratuitement par Cloudflare, rendra plus difficile la censure du contenu et le suivi des utilisateurs sur Internet. Lisez la suite pour savoir comment cela fonctionne.

SNI Quoi ?

L’extension SNI (TLS Server Name Indication), normalisée à l’origine en 2003, permet aux serveurs d’héberger plusieurs sites Web compatibles TLS sur le même ensemble d’adresses IP, en obligeant les clients à spécifier le site auquel ils souhaitent se connecter lors de la prise de contact TLS initiale. Sans SNI, le serveur ne saurait, par exemple, quel certificat servir au client ou quelle configuration appliquer à la connexion.

Le client ajoute l’extension SNI contenant le nom d’hôte du site auquel il se connecte au message "ClientHello". Il envoie le "ClientHello" au serveur au cours de la négociation TLS. Malheureusement, le message "ClientHello" est envoyé non chiffré, car le client et le serveur ne partagent pas de clé de chiffrement à ce stade.

Sans encrypted SNI :
(https://lafibre.info/images/ssl/201809_cloudflare_tls13_unencrypted_sni.png)

Cela signifie qu'un observateur sur le chemin d'accès (par exemple, un fournisseur d'accés internet, le propriétaire d'un café ou un pare-feu) peut intercepter le message "ClientHello" en texte brut et déterminer le site Web auquel le client tente de se connecter. Cela permet à l'observateur de savoir quels sites un utilisateur visite.

Mais avec encrypted SNI, le client chiffre le SNI, même si le reste de "ClientHello" est envoyé en texte brut.

Avec encrypted SNI :
(https://lafibre.info/images/ssl/201809_cloudflare_tls13_encrypted_sni.png)

Alors, comment se fait-il que le SNI d’origine n’ait pas pu être chiffré auparavant, mais que c'est possible maintenant ?
D'où vient la clé de chiffrement, si le client et le serveur n'en ont pas encore négocié ?

Si la poule doit venir avant l’œuf, où la mettez-vous ?

Comme avec beaucoup d'autres fonctionnalités Internet, la réponse est simplement «DNS».

Le serveur publie une clé publique sur un enregistrement DNS bien connu, qui peut être récupérée par le client avant la connexion (comme il le fait déjà pour A, AAAA et d'autres enregistrements). Le client remplace ensuite l’extension SNI dans "ClientHello" par une extension «encrypted SNI», qui n’est autre que l’extension SNI d’origine, mais cryptée à l’aide d’une clé de cryptage symétrique dérivée de la clé publique du serveur, comme décrit ci-dessous. Le serveur, qui possède la clé privée et peut également extraire la clé de chiffrement symétrique, peut alors déchiffrer l'extension et par conséquent mettre fin à la connexion (ou la transférer à un serveur principal). Étant donné que seul le client et le serveur auquel il se connecte peuvent dériver la clé de cryptage, le SNI crypté ne peut pas être décrypté et utilisé par des tiers.

Il est important de noter qu’il s’agit d’une extension de la version 1.3 et ultérieure de TLS et qu’il ne fonctionne pas avec les versions précédentes du protocole. La raison est très simple: une des modifications introduites par TLS 1.3 (non sans problèmes) impliquait de déplacer le message de certificat envoyé par le serveur vers la partie chiffrée de la négociation TLS (avant la version 1.3, il était envoyé en texte clair). Sans cette modification fondamentale du protocole, un attaquant serait toujours en mesure de déterminer l'identité du serveur en observant simplement le certificat en texte clair envoyé sur le réseau.

La machinerie cryptographique sous-jacente implique l’utilisation de l’algorithme d’échange de clé Diffie-Hellman, qui permet au client et au serveur de générer une clé de chiffrement partagée sur un canal non approuvé. La clé de chiffrement SNI chiffrée est ainsi calculée côté client en utilisant la clé publique du serveur (qui est en fait la partie publique d'un partage de clé semi-statique Diffie-Hellman) et la partie privée d'un partage éphémère Diffie-Hellman généré par le client lui-même à la volée et jeté immédiatement après l'envoi de ClientHello au serveur. Des données supplèmentaires (telles que certains des paramètres cryptographiques envoyés par le client dans le cadre de son message ClientHello) sont également mélangées dans le processus cryptographique pour une bonne mesure.

L’extension ESNI du client inclut alors non seulement les bits SNI chiffrés, mais également le partage de clé publique du client, la suite de chiffrement utilisée pour le chiffrement et le résumé de l’enregistrement DNS ESNI du serveur. De l’autre côté, le serveur utilise son propre partage de clé privée et la partie publique du partage du client pour générer la clé de chiffrement et déchiffrer l’extension.

Bien que cela puisse sembler excessivement compliqué, cela garantit que la clé de cryptage est liée de manière cryptographique à la session TLS spécifique pour laquelle elle a été générée et ne peut pas être réutilisée avec plusieurs connexions. Cela empêche un attaquant capable d'observer l'extension cryptée envoyée par le client de la capturer simplement et de le retransmettre au serveur dans une session distincte afin de démasquer l'identité du site Web auquel l'utilisateur tentait de se connecter (ce que l'on appelle «couper»). "coller").

Cependant, un compromis de la clé privée du serveur mettrait en péril toutes les clés symétriques ESNI générées à partir de celui-ci (ce qui permettrait aux observateurs de déchiffrer les données cryptées précédemment collectées). C'est pourquoi l'implèmentation du cryptage SNI de Cloudflare fait pivoter les clés du serveur toutes les heures pour améliorer le secret, mais garde une trace des clés des dernières heures pour permettre la mise en cache DNS et les retards de réplication, afin que les clients avec des clés légèrement obsolètes puissent toujours utiliser ESNI sans problème.


Mais attendez, DNS? Pour de vrai ?

Le lecteur attentif aurait peut-être compris que le simple fait d'utiliser DNS (qui est, par défaut, non crypté) rendrait totalement inutile l'idée SNI cryptée: un observateur sur le chemin serait en mesure de déterminer le site Web auquel le client se connecte en observant simplement le Requêtes DNS en texte brut envoyées par le client lui-même, que le SNI crypté ait été utilisé ou non.

Mais avec l'introduction de fonctionnalités DNS telles que DNS sur TLS (DoT) et DNS sur HTTPS (DoH), ainsi que de résolveurs DNS publics qui fournissent ces fonctionnalités à leurs utilisateurs (comme le service DNS de Cloudflare 1.1.1.1), les requêtes DNS peuvent désormais être traitées, chiffrées et protégées des regards indiscrets des censeurs et des traqueurs.

Cependant, bien que les réponses des résolveurs DNS DoT / DoH soient fiables, dans une certaine mesure (malgré les DNS menteurs), un attaquant déterminé peut toujours empoisonner le cache du résolveur DNS en interceptant sa communication avec le serveur DNS faisant autorité et en injectant des messages malveillants. Autrement dit, à moins que le serveur faisant autorité et le résolveur prennent en charge DNSSEC [1]. Incidemment, les serveurs DNS faisant autorité de Cloudflare peuvent signer les réponses renvoyées aux résolveurs et le résolveur 1.1.1.1 peut les vérifier.

[1]: Il est important de mentionner que DNSSEC pourrait être désactivé par le détournement de route BGP entre un résolveur DNS et le serveur TLD. La semaine dernière, nous avons annoncé notre engagement en faveur de RPKI. Si les résolveurs DNS et les TLD implèmentent également RPKI, ce type de détournement sera beaucoup plus difficile.


Qu'en est-il de l'adresse IP ?

Alors que les deux requêtes DNS et les extensions TLS SNI peuvent désormais être protégées par des attaquants situés sur le chemin d'accès, il est toujours possible de déterminer les sites Web consultés par les utilisateurs en regardant simplement les adresses IP de destination du trafic provenant des appareils des utilisateurs. Certains de nos clients sont protégés dans une certaine mesure par le fait que de nombreux domaines Cloudflare partagent les mêmes ensembles d'adresses, mais cela ne suffit pas et il faut déployer davantage d'efforts pour protéger davantage les utilisateurs finaux. Cloudflare reviendra sur le sujet à l'avenir.


Où puis-je m'inscrire ?

SNI crypté est maintenant activé gratuitement sur toutes les zones Cloudflare en utilisant nos DNS. Vous n'avez donc rien à faire pour l'activer sur votre site Web Cloudflare. Du côté du navigateur, nos amis de Firefox nous ont dit s’attendre à ajouter dans Firefox Nightly cette semaine le support de encrypted SNI (gardez à l’esprit que la spécification encrypted SNI est encore en développement, elle n’est donc pas encore stable).

En visitant https://www.cloudflare.com/ssl/encrypted-sni/, vous pouvez vérifier le niveau de sécurité de votre expérience de navigation. Utilisez-vous un DNS sécurisé? Votre résolveur valide-t-il les signatures DNSSEC? Votre navigateur prend-il en charge TLS 1.3? Votre navigateur a-t-il chiffré le SNI? Si la réponse à toutes ces questions est «oui», vous pouvez dormir paisiblement en sachant que votre navigation est protégée des regards indiscrets.


Conclusion

Encrypted SNI, ainsi que TLS 1.3, DNSSEC et DoT / DoH, bloque l’un des rares trous restants permettant la surveillance et la censure sur Internet. Davantage de travail est encore nécessaire pour obtenir un Internet sans surveillance, mais nous y allons (lentement).

Source: Blog Cloudflare (https://blog.cloudflare.com/encrypted-sni/), le 24 septembre 2018, par Alessandro Ghedini
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 24 mai 2019 à 11:15:59
Pour ceux qui pensent que personne n'utilisent le DPI :

Au moins 186 FAI européens utilisent le DPI pour court-circuiter la neutralité du net

Selon un groupe comprenant des ONG, des universitaires et des entreprises, les fournisseurs européens de services Internet enfreignent déjà les règles de neutralité du net et façonnent le trafic Internet, bien que la réglementation sur la neutralité du réseau soit en vigueur dans l'UE depuis 2016.

Ce groupe - composé de 45 entités de 15 pays - a envoyé une lettre ouverte aux autorités de l'Union Européenne pour leur faire part de préoccupations concernant le non-respect par les FAI européens des règles de neutralité du réseau et le fait que les régulateurs locaux ignorent ces activités.

Cette lettre a été envoyée alors que les autorités européennes sont en pleine négociation sur les nouvelles règles de neutralité du net au sein de l'UE. Ces négociations se déroulent actuellement à huis clos avec les régulateurs nationaux des télécommunications.

Le groupe d'ONG et d'universitaires, mené par l'organisation European Digital Rights (EDRi), s'inquiète du fait que "certains régulateurs des télécommunications semblent pousser à la légalisation de l'inspection approfondie des paquets (DPI - Deep Packet Inspection)".

L'EDRi s'inquiète de l'utilisation accrue de la technologie d'inspection approfondie des paquets car cette technologie permet aux FAI de façonner le trafic et d'appliquer des plans de tarification différenciés. Mais elle constitue également une menace pour la vie privée des utilisateurs, car elle permet aux opérateurs de télécommunications d'examiner plus en profondeur la nature du trafic auxquels les utilisateurs ont accès.


Certains FAI européens enfreignent déjà les règles

Les règles actuelles de neutralité du réseau permettent aux FAI européens d'inspecter et de façonner le trafic dans certaines circonstances, mais uniquement pour optimiser les ressources du réseau, et non à des fins commerciales ou de surveillance.

L'EDRi souligne dans sa lettre que certains FAI de l'UE ignorent déjà les règles de neutralité du réseau et, depuis quelques années, déploient le DPI pour examiner le trafic des clients et détecter les destinations des communications.

L'EDRi cite un rapport publié en janvier 2019, selon lequel 186 FAI européens semblent utiliser le DPI pour proposer aux clients des offres tarifaires différenciées. "Les FAI utilisent de plus en plus la technologie de DPI pour la gestion du trafic et la tarification différenciée d'applications ou de services spécifiques dans le cadre de la conception de leurs produits", ont déclaré l'EDRi et ses partenaires.

"Le DPI permet aux [FAI] de distinguer le trafic sur leurs réseaux afin d'identifier le trafic d'applications ou de services spécifiques dans le but, par exemple, de les facturer différemment en limitant ou en les classant par ordre de priorité par rapport aux autres trafic".

"La plupart des régulateurs ont jusqu'à présent fermé les yeux sur ces violations de la neutralité du réseau. Au lieu de remplir leurs devoirs, ils semblent maintenant viser à édulcorer les règles qui interdisent le DPI", a déclaré l'EDRi.


Le DPI ne devrait pas être légalisé

Si les FAI obtiennent des exemptions pour utiliser légalement la technologie de DPI, il est possible que les entreprises de télécommunications l'utilisent pour masquer les plans de tarification sous la forme d'opérations de gestion du trafic et contournent la règle actuelle de neutralité du net.

En outre, l'EDRi met en garde contre l'énorme menace que le DPI fait peser sur la vie privée des utilisateurs au sein de l'UE, car il permettrait également aux opérateurs de télécommunications d'accéder aux données des utilisateurs sans leur consentement, sous couvert d'opérations "autorisées" de gestion du trafic.

Les autorités européennes doivent organiser une consultation publique sur les nouvelles règles de neutralité du réseau à l'automne 2019. Les règles révisées de l'UE en matière de neutralité du réseau devraient être soumises au vote en mars 2020. L'EDRi et ses partenaires espèrent que le DPI ne sera pas légalisé et ne neutralise pas ainsi la neutralité du net et la législation de l'UE sur la protection de la vie privée.

Source: ZD-Net (https://www.zdnet.fr/actualites/au-moins-186-fai-europeens-utilisent-le-dpi-pour-court-circuiter-la-neutralite-du-net-39884877.htm), le 20 mai 2019 par Catalin Cimpanu
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 24 mai 2019 à 11:19:59
La lettre du groupe composé de 45 entités de 15 pays sur le DPI :

(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ssl/201905_edri_open_letter_dpi.png) (https://lafibre.info/images/ssl/201905_edri_open_letter_dpi.pdf)

Note: le zero rating évoqué dans cette lettre, c'est lorsqu’un opérateur qui propose un forfait limité en données offre certains services « en illimité », non-décomptés du forfait. On a eu le cas avec YouTube en illimité chez SFR eu début de la 4G (depuis SFR a arrêté le zero rating), B.tv en illimité via un bonus chez Bouygues Telecom,...
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: Marco POLO le 24 mai 2019 à 17:49:34
Qu'est-ce qu'un résolveur ? Tout ce que j'ai trouvé, c'est ça (https://fr.wikipedia.org/wiki/R%C3%A9solveur) ! Et comment savoir s'il valide les signatures DNSSEC (https://fr.wikipedia.org/wiki/DNSSEC) ?  (https://lafibre.info/images/smileys/@GregLand/cs.gif)
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 24 mai 2019 à 17:57:49
Un résolveur DNS est utilisé pour chaque nom de domaine que tu souhaite résoudre :

Ton navigateur va demander "quel est l'IPv4 de lafibre.info" et le résolveur DNS va répondre "c'est 46.227.16.8"

Cloudflare gère le résolveur DNS 1.1.1.1 (cf https://1.1.1.1/fr/ ) mais par défaut tu utilises celui de ton FAI.
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti le 26 mai 2019 à 00:11:25
Firefox supporte le ESNI, pour ça il faut :
 - activer le DNS sur HTTPS (DoH) : dans les options, ou network.trr.mode=2 dans about:config (par exemple sur Android)
 - activer network.security.esni.enabled dans about:config

Je ne sais pas pourquoi ils ont lié les deux fonctionnalités. Certes avec le DNS en clair celui qui observe le réseau a beaucoup d'informations, mais pas autant que le SNI.
En plus, on peut très bien avoir un relai DNS sur la machine (type dnsmasq ou autre), qui pourrait être configuré pour faire du DoH/DoT vers l'extérieur tout en résolvant les adresses internes (en entreprise par exemple) avec le DNS par défaut du réseau.
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: Electrocut le 27 mai 2019 à 11:12:21
Citation de: hwti le 26 mai 2019 à 00:11:25
Certes avec le DNS en clair celui qui observe le réseau a beaucoup d'informations, mais pas autant que le SNI.
Dans les 2 cas (DNS ou SNI), c'est bien le nom de domaine complet (ex : www.lafibre.info) qui est transmis, non ?
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 27 mai 2019 à 11:19:32
Oui, le nom de domaine entier.
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti le 28 mai 2019 à 02:33:03
Citation de: Electrocut le 27 mai 2019 à 11:12:21
Dans les 2 cas (DNS ou SNI), c'est bien le nom de domaine complet (ex : www.lafibre.info) qui est transmis, non ?
Oui, mais le DNS est mis en cache, donc on capture une requête de temps en temps.
Le SNI permet de voir connexion par connexion, et de faire un blocage plus difficile à contourner que via le DNS (qui est la solution utilisée actuellement par les FAI en France pour les blocages exigés par la justice et l'exécutif).
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 03 février 2020 à 20:55:25
Pour activer Encrypted SNI sur Firefox :

Firefox 72 propose Encrypted SNI, mais il n'est pas activé.
Il faut activer l'option network.security.esni.enabled

Pour activer network.security.esni.enabled, il faut se rendre dans about:config qu'il faut rentrer dans la barre d'adresse.

(https://lafibre.info/images/ssl/202002_firefox_activer_esni_1.png)

Un message vous informe des risques si vous modifiez un paramètre sans savoir ce que vous faites.

Validez et cherchez esni

network.security.esni.enabled apparaît.

(https://lafibre.info/images/ssl/202002_firefox_activer_esni_2.png)

Cliquez sur la double flèche à droite pour changer son état de false à true

(https://lafibre.info/images/ssl/202002_firefox_activer_esni_3.png)

Vous pouvez vérifier l'activation d'Encrypted SNI sur https://www.cloudflare.com/ssl/encrypted-sni/
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 03 février 2020 à 20:55:42
network.security.esni.enabled est activé, mais je n'ai pas d'Encrypted SNI

Mais Encrypted SNI n'est toujours pas activé !
(https://lafibre.info/images/ssl/2020_cloudflare_esni_test_1.png)

En effet FireFox ne demande le champ ESNI au DNS qu'en cas d'utilisation de DoH (DNS over HTTPS).

Pour ceux qui se demandent comment activer DNS over HTTPS dans Firefox :

Il faut aller dans Préférences :
(https://lafibre.info/images/tuto/201911_firefox_activation_dns_over_https_1.png)

Tout en bas de la page il faut cliquer sur Paramètres pour ouvrir les paramètres réseaux.
(https://lafibre.info/images/tuto/201911_firefox_activation_dns_over_https_2.png)

Enfin en bas de la page, cocher "Activer le DNS via HTTPS" : Vous pouvez sélectionner Cloudflare ou rentrer une URL personnalisée ( du type https:// )
(https://lafibre.info/images/tuto/201911_firefox_activation_dns_over_https_3.png)

Là Encrypted SNI est bien activé :
(https://lafibre.info/images/ssl/2020_cloudflare_esni_test_3.png)
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 03 février 2020 à 20:59:56
Si vous souhaitez utiliser Encrypted SNI sans utiliser le DNS ovuer HTTPS de Cloudflare, d'autre choix sont possibles.

HébergeurType de DNSLatence (depuis Paris)  URL DNS over HTTPS (DoH)
CloudFlarestandard1mshttps://cloudflare-dns.com/dns-query
CloudFlareDNS64 (il ne répond qu'en IPv6, logique)1mshttps://dns64.cloudflare-dns.com/dns-query
Google Public DNSstandard1mshttps://dns.google/dns-query
Google Public DNSDNS64 (il ne répond qu'en IPv6, logique)1mshttps://dns64.dns.google/dns-query
NextDNSstandard (incompatible IPv6)1mshttps://dns.nextdns.io/ cf https://my.nextdns.io/configuration/ pour la configuration
AdGuardstandard84mshttps://dns.adguard.com/dns-query
AdGuardmode "Family protection"84mshttps://dns-family.adguard.com/dns-query
CleanBrowsingmode "Security Filter" (incompatible IPv6)8mshttps://doh.cleanbrowsing.org/doh/security-filter/
CleanBrowsingmode "Family Filter" (incompatible IPv6)8mshttps://doh.cleanbrowsing.org/doh/family-filter/
CleanBrowsingmode "Adult Filter" (incompatible IPv6)8mshttps://doh.cleanbrowsing.org/doh/adult-filter/
OpenDNSstandard9mshttps://doh.opendns.com/dns-query
OpenDNSmode "FamilyShield"9mshttps://doh.familyshield.opendns.com/dns-query
Quad9 DNSstandard (Unsecured)1mshttps://dns10.quad9.net/dns-query
Quad9 DNSmode "Secure Recommended"1mshttps://dns.quad9.net/dns-query
Quad9 DNSmode "Secured"1mshttps://dns9.quad9.net/dns-query
Quad9 DNSmode "Secured w/ ECS (https://en.wikipedia.org/wiki/EDNS_Client_Subnet) support"1mshttps://dns11.quad9.net/dns-query
Switch Public DNSstandard26mshttps://dns.switch.ch/dns-query

Source : Wikipedia "Public recursive name server" (https://en.wikipedia.org/wiki/Public_recursive_name_server)

Attention, dans ce cas là le test de cloudflare sera Orange pour le DNS, mais tout est bon et Encrypted SNI est bien actif.
(https://lafibre.info/images/ssl/2020_cloudflare_esni_test_2.png)

Encrypted SNI n'étant presque disponible que chez CloudFlare, j'aimerais bien tester l’efficacité de la chose.

Si vous trouvez un site adulte hébergé chez CloudFlare, je suis intéressé, cela permettra de faire des tests sur de vrais réseaux, qui bloquent les sites pour adultes.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti le 03 février 2020 à 23:37:52
A noter qu'il y a un bug avec l'ESNI : https://bugzilla.mozilla.org/show_bug.cgi?id=1566175, qui provoque des échecs de chargement avec l'erreur SSL_ERROR_MISSING_ESNI_EXTENSION.
Ça se corrige au bout de quelques minutes, donc il s'agit certainement d'un problème de cache, soit dans Firefox, soit côté serveur(s), au moment d'un changement de clé ESNI (à priori toutes les heures chez Cloudflare).
Ca fait plusieurs mois que je n'ai pas vu l'erreur, mais pour d'autres ça semble arriver plus souvent.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 10 février 2020 à 08:15:22
Précisions, je ne suis pas un grand fan d'Encrypted SNI : Je pense que son adoption pourrait retarder l'extinction de l'IP4 sur Internet.

Dans les scénarios possible pour achever la transition d'IPv4 vers IPv6 (« scénarios de sortie »), le DNS46/NAT46 permet de laisser des clients entreprises en mode IPv4 only (Certaines entreprises sont bloquées pour la migration par des équipements incompatible IPv6 qu'il n'est pas simple de changer) tout en ayant un accès complet à IPv6 (c'est à moyen terme, quand les sites web n'auront que des IPv6 et plus d'IPv4).

Dans ce scénario, la plateforme NAT46 qui permet de faire le lien entre l'IPv4 de l'entreprise et l'Internet IPv6 serait chez l'opérateur. Contrairement au NAT64 utilisé sur les téléphones mobiles, où un mobile IPv6 only accède à l'Internet IPv4 pas un DNS64 qui va encoder l'IPv4 dans une IPv6, sur la NAT46, il est impossible de mettre une IPv6 dans une partie de l'IPv4 et donc la seule solution pour retrouver la cible, c'est le SNI.

Encrypted SNI si il est massivement déployé ce qui n'est pas le cas aujourd'hui, tuerait la possibilité de finir les derniers % de transition IPv6 via du NAT46/DNS46.


Exemple de « scénario de sortie » avec Encrypted SNI et donc sans DNS46/NAT46 :

• 2025 : La quasi-totalité des offres d'accès internet grand public commercialisées proposent de l'IPv6 activé par défaut et de l'IPv4 via une IPv4 dédiée ou partagée.

• 2030 : La quasi-totalité des offres d'accès internet grand public, pro et entreprise proposent de l'IPv6 activé par défaut. Une connectivité IPv4 est toujours proposée.

• 2035 : Malgré des poches de résistances à l’IPv6 pour l’accès proposés par quelques entreprises à ses salariés, une part non négligeable des sites web sont hébergés en IPv6 uniquement. Ces sites ne sont plus accessibles depuis une entreprise qui bloque l'IPv6.

• 2040 : Une part non négligeable des offres des fournisseur d'accès à Internet ne proposent plus de connectivité IPv4. Il n'est plus possible de consulter des sites web hébergés en IPv4 uniquement.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti le 10 février 2020 à 11:02:36
Citation de: vivien le 10 février 2020 à 08:15:22
Dans ce scénario, la plateforme NAT46 qui permet de faire le lien entre l'IPv4 de l'entreprise et l'Internet IPv6 serait chez l'opérateur. Contrairement au NAT64 utilisé sur les téléphones mobiles, où un mobile IPv6 only accède à l'Internet IPv4 pas un DNS64 qui va encoder l'IPv4 dans une IPv6, sur la NAT46, il est impossible de mettre une IPv6 dans une partie de l'IPv4 et donc la seule solution pour retrouver la cible, c'est le SNI.
Le SNI ne s'applique qu'au TLS, comment cette solution de NAT46 s'appliquerait à Internet en général, et pas uniquement au web ?
Quel serait l'avantage par rapport à un proxy HTTP (qui permet de faire passer toutes les connexions sortantes TCP) ? En plus le nom de domaine pourrait être caché après le proxy.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 10 février 2020 à 11:42:50
Pour les grandes entreprises qui ont un proxy, la solution passe bien sur la mise à jour du proxy pour qu'il accède à l'Internet en IPv6 et que tous les salariés de l'entreprise, probablement en IPv4 privée uniquement derrière ce proxy, aient accès à l'Internet IPv6.

Maintenant toutes les entreprises n'ont pas de proxy. Dans certaines petites entreprises certaines sont en direct derrière la box de leur opérateur et ces cas là vont facilement migrer vers IPv6.

D'autres entreprises sans proxy ont du matériel spécifique qui n'est pas compatible IPv6 et qu'il peut être très couteux de faire évoluer, car il n'y a aucune compétence en interne et aucun contrat avec une société pour ce matériel. Pour eux le DNS46/NAT46 pourrait être une solution que les flux web IPv6 passent. La plupart des autres protocoles autres que le web ne passeront pas, mais dans le cas où le web http / https est l'unique besoin de connectivité avec Internet, le DNS46/NAT46 pourrait jouer son rôle.

Pour donner un exemple des vieilleries qu'on trouver, le système Decor (diffusion des données d’environnement contrôle d’Orly et de Roissy), relié à Météo France fonctionne sous Windows 3.1. cf Une panne informatique à l’aéroport d’Orly liée à... Windows 3.1 (https://lafibre.info/systeme-exploitation/une-panne-informatique-a-laeroport-dorly-liee-a-windows-3-1/msg274795/#msg274795).
Il arrive que les ordinateurs connectés directement à ces systèmes anciens aient besoin d'accéder à Internet pour le web (http / https) mais doivent passer par des équipements spécifiques non compatible IPv6. Le DNS46/NAT46 en amont permettrait cet accès.

L'objectif reste de trouver des solutions pour les dernières pourcentage de migration vers IPv6, ces derniers % seront complexes et longs et donc j'aimerais bien trouver des solutions. Penser que IPv6 va croitre de +8% par an (rythme observé  depuis 4 ans), c'est bon pour les premières années, mais pas quand on sera vers la fin du process.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: decalage le 10 février 2020 à 18:07:41
Ceux-là n'auront qu'à désactiver ESNI dans leur navigateur. Attendre les retardataires n'est pas toujours la bonne solution.
Titre: encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: Marco POLO le 02 mars 2020 à 17:56:19
Citation de: hwti le 26 mai 2019 à 00:11:25
Firefox supporte le ESNI, pour ça il faut :
 - activer le DNS sur HTTPS (DoH) : dans les options, ou network.trr.mode=2 dans about:config (par exemple sur Android)
 - activer network.security.esni.enabled dans about:config ...
Suite au tutoriel de Vivien (Mozilla active DNS over HTTPS par défaut dans Firefox (https://lafibre.info/navigateurs/doh-usa/msg735608/#msg735608)), merci pour le tuyau.  (https://lafibre.info/images/smileys/@GregLand/ay.gif)

Edit: Merci également à Vivien (https://lafibre.info/cryptographie/encrypted-sni/msg728705/#msg728705).  (https://lafibre.info/images/smileys/@GregLand/en.gif)
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: kazyor le 10 août 2020 à 14:45:00
La Chine bloque désormais tout le trafic HTTPS utilisant TLS 1.3 et ESNI

Le gouvernement chinois utilise actuellement son "Great Firewall" pour bloquer certains types de connexions HTTPS chiffrées.

Le blocage est en place depuis plus d'une semaine, selon un rapport conjoint rédigé par trois organisations qui suivent la censure chinoise du réseau : iYouPort, l'université du Maryland (https://geneva.cs.umd.edu/posts/china-censors-esni/esni/) et le rapport sur le great firewall (https://gfw.report/blog/gfw_esni_blocking/en/).

ZDNet a également confirmé les conclusions de ce rapport auprès de deux autres sources, à savoir les membres d'un fournisseur de télécommunications américain et un point d'échange Internet (IXP), en utilisant les instructions fournies dans une liste de diffusion. (https://mailarchive.ietf.org/arch/msg/tls/Dae-cukKMqfzmTT4Ksh1Bzlx7ws/)

Aucune des deux sources ne voulait que leur identité et leurs employeurs soient nommés en raison des risques de représailles directes ou indirectes contre les entités mettant en avant ses pratiques de censure d'Internet.


La Chine bloque maintenant HTTPS+TLS1.3+ESNI

Selon le rapport, le grand pare-feu chinois (GFW) bloque désormais les connexions HTTPS établies via le nouveau protocole de chiffrement TLS 1.3 et qui utilisent l'ESNI (Encrypted Server Name Indication).

La raison de ce blocage est évidente selon les experts.

Les connexions HTTPS négociées via TLS 1.3 et ESNI empêchent les observateurs tiers de détecter le site web auquel un utilisateur tente d'accéder. Cela empêche effectivement l'outil de surveillance Great Firewall du gouvernement chinois de voir ce que font les internautes en ligne.

Il existe un mythe autour des connexions HTTPS selon lequel les observateurs du réseau (tels que les fournisseurs d'accès Internet) ne peuvent pas voir ce que font les utilisateurs. Cette affirmation est techniquement incorrecte.

Bien que les connexions HTTPS soient chiffrées et empêchent les observateurs du réseau de voir/lire le contenu d'une connexion HTTPS, il y a une courte période avant que les connexions HTTPS soient établies qui permet à des tiers de détecter à quel serveur l'utilisateur se connecte.

Pour ce faire, il suffit d'examiner le champ SNI (Server Name Indication) de la connexion HTTPS.

Dans les connexions HTTPS négociées via des versions antérieures du protocole TLS (telles que TLS 1.1 et TLS 1.2), le champ SNI est visible en clair.

Dans TLS 1.3, une version du protocole lancée en 2018, le champ SNI peut être caché et chiffré via ESNI.

Alors que le protocole TLS 1.3 est aujourd'hui plus largement adopté, l'utilisation de l'ESNI augmente également. De plus en plus de connexions HTTPS sont maintenant plus difficiles à suivre pour les outils de censure en ligne comme le great firewall.

Selon le rapport, le gouvernement chinois cherche à bloquer toutes les connexions HTTPS où TLS 1.3 et ESNI sont utilisés et à bloquer temporairement les adresses IP impliquées dans la connexion pendant deux à trois minutes.


Certaines méthodes de contournement existent... pour l'instant

Heureusement pour les créateurs d'applications et les opérateurs de sites web qui s'adressent au public chinois, les trois organisations ont déclaré avoir trouvé six méthodes de contournement qui peuvent être appliquées côté client (dans les applications et les logiciels) et quatre qui peuvent être appliquées côté serveur (sur les serveurs et les backends des applications) pour contourner le blocage actuel mis en place par le Great Firewall.

"Malheureusement, ces stratégies spécifiques ne constituent peut-être pas une solution à long terme : à mesure que le jeu du chat et de la souris progresse, le Great Firewall continuera probablement à améliorer ses capacités de censure", écrivent les trois organisations dans leur rapport.

Source: ZD-NEt (https://www.zdnet.fr/actualites/la-chine-bloque-desormais-tout-le-trafic-https-utilisant-tls-13-et-esni-39907931.htm), le lundi 10 Août 2020 par Catalin Cimpanu.


Des infos intéressantes dans le mail de la ML cité par ZDNet : https://mailarchive.ietf.org/arch/msg/tls/Dae-cukKMqfzmTT4Ksh1Bzlx7ws/
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: cali le 10 août 2020 à 15:14:26
Citation de: kazyor le 10 août 2020 à 14:45:00
Des infos intéressantes dans le mail de la ML cité par ZDNet : https://mailarchive.ietf.org/arch/msg/tls/Dae-cukKMqfzmTT4Ksh1Bzlx7ws/

J'ai lu l'article mais pourtant j'arrive bien à faire du TLS 1.3 avec le ESNI en Chine.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: adhame95 le 26 août 2020 à 21:03:24
J'ai fait le test avec le site de reporters sans frontières https://rsf.org/ qui est bloqué en egypte.

Avec chrome (ou firefox avec esni désactivé mais doh activé) le site ne charge pas.
Lorsque j'ai activé esni : MAGIE :D le site a chargé normalement
J’espère que le esni va se généraliser !
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien le 27 août 2020 à 09:52:41
C'est le but d'ESNI.

Il n'y a pas que RSF qui dérange, https://www.amnesty.org/ était aussi bloqué dans certains pays.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: kazyor le 23 septembre 2020 à 16:44:57
Après la Chine, au tour de la Russie :

La Russie veut interdire l'utilisation de protocoles sécurisés

Le gouvernement russe travaille à la mise à jour de ses lois sur la technologie afin d'interdire l'utilisation de protocoles internet modernes qui peuvent entraver ses capacités de surveillance et de censure.

Selon une copie de la proposition de modification de la loi (https://www.documentcloud.org/documents/7215232-Proposed-Russia-law-to-ban-secure-encryption.html) et une note explicative (https://www.documentcloud.org/documents/7215233-149-%D0%9F%D0%97.html), l'interdiction vise les protocoles et technologies internet tels que TLS 1.3, DoH, DoT et ESNI.

L'objectif n'est pas d'interdire le HTTPS et les communications chiffrées dans leur ensemble, car ils sont nécessaires aux transactions financières, aux communications, à l'armée et aux infrastructures critiques. Le gouvernement souhaite plutôt interdire l'utilisation de protocoles internet qui cachent « le nom (identifiant) d'une page web » dans le trafic HTTPS.


Le trafic HTTPS a des fuites

Aujourd'hui, si le HTTPS chiffre le contenu d'une connexion internet, il existe diverses techniques que des tiers tels que les opérateurs de télécommunications peuvent appliquer pour déterminer le site auquel un internaute se connecte.

Les tiers ne sont peut-être pas en mesure de casser le chiffrement et d'intercepter le trafic, mais ils peuvent suivre ou bloquer les utilisateurs sur la base de ces fuites d'informations. C'est ainsi que fonctionnent certains contrôles parentaux au niveau des fournisseurs d'accès internet, et certaines listes de blocage de sites pour infraction aux droits d'auteur.

Les deux principales techniques utilisées par les opérateurs de télécommunications aujourd'hui comprennent (1) la surveillance du trafic DNS ou (2) l'analyse du champ SNI (Server Name Identification) dans le trafic HTTPS.

La première technique fonctionne parce que les navigateurs et les applications effectuent des requêtes DNS en clair, révélant la destination du site de l'utilisateur avant même qu'une future connexion HTTPS ne soit établie. La deuxième technique fonctionne parce que le champ SNI des connexions HTTPS est laissé non chiffré et permet également aux tiers de déterminer vers quel site une connexion HTTPS se dirige.


Les nouveaux protocoles

Mais, au cours de la dernière décennie, de nouveaux protocoles internet ont été créés et publiés pour résoudre ces deux problèmes : le DoH (DNS over HTTPS) et le DoT (DNS over TLS) peuvent chiffrer les requêtes DNS. Et lorsqu'ils sont combinés, TLS 1.3 et l'ESNI (Server Name Identification) peuvent également empêcher les fuites d'information au travers du champ SNI.

Ces protocoles sont lentement adoptés, tant par les navigateurs que par les fournisseurs de services dans le cloud et les sites web du monde entier. Preuve de leur efficacité, la Chine a mis à jour son outil de censure Great Firewall (https://www.zdnet.fr/actualites/la-chine-bloque-desormais-tout-le-trafic-https-utilisant-tls-13-et-esni-39907931.htm) pour bloquer le trafic HTTPS qui s'appuyait sur TLS 1.3 et ESNI.

La Russie n'utilise pas de système comparable, mais le régime de Moscou s'appuie sur un système appelé SORM (https://fr.wikipedia.org/wiki/SORM), qui permet aux forces de l'ordre d'intercepter le trafic internet à des fins répressives directement à la source, dans les centres de données des opérateurs de télécommunications.


Les nouveaux protocoles entravent la surveillance et la censure

De plus, le ministère russe des télécommunications, le Roskomnadzor, a mis en place un système de censure grâce à son pouvoir de régulation sur les fournisseurs d'accès locaux. Depuis une dizaine d'années, il interdit les sites web qu'il juge dangereux et demande aux FAI de filtrer leur trafic et de bloquer leur accès. Avec l'adoption de TLS 1.3, du DoH, du DoT et de l'ESNI, tous les outils de surveillance et de censure actuels de la Russie deviendront inutiles, car ils reposent sur l'accès aux identifiants des sites web laissés accessibles.

Et tout comme la Chine, la Russie agit contre ces nouvelles technologies. Selon la proposition d'amendements, toute entreprise ou site web qui utilise la technologie pour cacher l'identifiant de site web dans un trafic chiffré sera interdit en Russie, après un avertissement d'un jour.

La proposition de loi fait actuellement l'objet d'un débat ouvert et attend les réactions du public (https://regulation.gov.ru/projects#npa=108513) jusqu'au mois prochain, le 5 octobre. Compte tenu des avantages stratégiques, politiques et de renseignement qui découlent de cet amendement à la loi, il est presque certain qu'il sera adopté.


Source: ZD-Net (https://www.zdnet.fr/actualites/la-russie-veut-interdire-l-utilisation-de-protocoles-securises-39910089.htm), le mercredi 23 septembre 2020.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti le 28 décembre 2020 à 23:37:25
Firefox 85 supprime le support de l'ESNI, qui est remplacé par ECH.
Il faut activer :
 - le DoH, comme pour ESNI
 - network.dns.echconfig.enabled
 - (probablement) network.dns.upgrade_with_https_rr

Malheureusement Cloudflare ne semble pas l'avoir encore déployé.
about:networking#dnslookuptool pour www.cloudflare.com donne :
Code: [Sélectionner]
1 www.cloudflare.com (alpn="h3-29,h3-28,h3-27,h2" ipv4hint="104.16.123.96, 104.16.124.96" ipv6hint="2606:4700::6810:7b60, 2606:4700::6810:7c60" )Il manque "echconfig" à priori.

https://blog.cloudflare.com/encrypted-client-hello/ (https://blog.cloudflare.com/fr/encrypted-client-hello-fr/ en français).
ECH remplace ESNI, en chiffrant une plus grande partie du Client Hello (d'où son nom), y compris ALPN (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids : si un serveur supporte, on pourra faire passer autre chose que de l'HTTP, comme de l'IMAP ou du DoT, sur le port 443 sans qu'un observateur puisse savoir de tel type de trafic il s'agit).

Il est censé aussi résoudre les problèmes de rotation des clés (qui avaient parfois généré des erreurs avec ESNI sur les serveurs Cloudflare), et permet d'avoir des clés (toujours récupérées via DNS, mais via le "HTTPS record" maintenant) différentes pour chaque IP, par exemple si un même nom de domaine a des serveurs chez plusieurs fournisseurs différents.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien 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

(https://lafibre.info/images/logo/logo_encrypted_client_hello.jpg)

É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 (https://datatracker.ietf.org/doc/draft-ietf-tls-esni/) 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 (https://blog.cloudflare.com/encrypted-client-hello/).

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 (https://tools.ietf.org/html/draft-ietf-tls-esni-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é.

Source : Blog de Mozilla (https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/)
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti 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  ???
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: hwti 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 :
Code: [Sélectionner]
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.
Titre: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
Posté par: vivien 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 ?
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 13 juin 2021 à 12:28:29
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.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 13 juin 2021 à 12:55:09
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
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 13 juin 2021 à 13:42:33
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.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 16 février 2022 à 14:27:53
il smeble que avec firefox 99 nighthly et le site https://crypto.cloudflare.com/cdn-cgi/trace/  le ech draft 13 soit actif

https://crypto.cloudflare.com renvoie https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 16 février 2022 à 14:33:47
par contre lors du test sur https://www.cloudflare.com/ssl/encrypted-sni/ secure sni est pas actif
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 16 février 2022 à 15:56:24
Oui, le draft-13 est fonctionnel depuis au moins un mois sur Nightly.
D'ailleurs, le bug que j'avais vu en juin (une connexion sans ECH en parallèle d'une connexion avec) était toujours présent, donc je l'ai signalé, et c'est maintenant corrigé.

En revanche, le serveur utilisé par https://www.cloudflare.com/ssl/encrypted-sni/, ne gère pas le draft-13.
Il ne doit y avoir que le serveur de test crypto.cloudflare.com qui le supporte.

Mais maintenant il y a un draft-14...
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 03 juillet 2022 à 17:11:13
chromium, chrome canary ainsi que chrome dev supportent maintenant ECH !
j'ai testé sous win11 et android 12

pour ca il faut 3 choses :
- activer doh avec cloudflare dans chrome
- activer "Support for HTTPS records in DNS" (en fait par defaut c’est actif)
- et évidemment "Encrypted ClientHello"

pour faciliter vous pouvez rechercher "DNS" dans chrome://flags/

Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 03 juillet 2022 à 20:02:37
Cela aura mis un sacré temps à venir.

Là, on peut imaginer une mise en prod (activé par défaut) en version stable pas avant 2023.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 03 juillet 2022 à 23:02:17
En pratique ECH ne semble pas déployé chez Cloudflare en France, à part crypto.cloudflare.com.
Ils ont annoncés la disponibilité sur certaines zones, sans préciser lequelles, il y a plusieurs mois.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 03 juillet 2022 à 23:13:30
Il y environ 1 version majeure par mois (https://en.wikipedia.org/wiki/Google_Chrome_version_history)

ECH est dispo sur la version 105 et nous sommes a la version 103 en stable, il est raisonnable de penser que d’ici septembre chrome stable prendra en charge ECH

Mais le souci c’est que a ma connaissance aucun site ne supporte ECH…
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 04 juillet 2022 à 07:44:58
Il y a des fonctions qui restent des années dans Chrome Canary / Firefox Nightly sans passer dans les versions bêta.

Une fois en bêta, oui, ce sera disponible rapidement dans la version stable (un retard d'une version est possible).
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 04 août 2022 à 18:12:57
Citation de: vivien le 04 juillet 2022 à 07:44:58
Il y a des fonctions qui restent des années dans Chrome Canary / Firefox Nightly sans passer dans les versions bêta.

Une fois en bêta, oui, ce sera disponible rapidement dans la version stable (un retard d'une version est possible).

ECH est maintenant actif avec chrome beta (Android et windows) !

Malheureusement sur ios ni doh ni le reste est present sur chrome beta (105)
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 06 août 2022 à 16:40:53
voici le pcap sur https://cloudflareresearch.com/cdn-cgi/trace/ et https://crypto.cloudflare.com/cdn-cgi/trace/
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 06 août 2022 à 17:12:50
Citation de: adhame95 le 04 août 2022 à 18:12:57
Malheureusement sur ios ni doh ni le reste est present sur chrome beta (105)
Sur iOS c'est WebKit derrière (Apple ne permet pas les autre moteurs), donc je pense que ce sont toujours les couches réseau Apple qui sont utilisées.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 07 août 2022 à 11:21:30
Sur iOS, pour résumer, il n'y a que Safari.

Les autres navigateurs se contentent de changer l'interface de Safari, de gérer des fonctions tel quel l'enregistrement des favoris, des morts de passe,...
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: kgersen le 07 août 2022 à 23:24:11
pour suivre le dev chez Chrome on peut s'abonner (en cliquant l'étoile en haut a gauche) a ce "bug": https://bugs.chromium.org/p/chromium/issues/detail?id=1091403

ou a la version moins "technique" (il faut être connecté pour voir l'étoile d'abonnement):
https://chromestatus.com/feature/6196703843581952

pour le moment les 2 flags de control (v105 ou plus) sont:

chrome://flags/#encrypted-client-hello
chrome://flags/#dns-https-svcb (réutilisation d'un vieux flag)

(adhame95 a déjà indiqué plus avant comment ca fonctionne).


Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 08 août 2022 à 20:15:08
A noter que même si chrome://flags/#dns-https-svcb est configuré à "Enabled for DNS-over-HTTPS and insecure DNS", ça semble limité au DoH (au moins sous Linux).
Et puisque Chrome ne permet pas de mettre des domaines en exception au DoH, quand on veut pouvoir utiliser un DNS local (pour le LAN, pour un internet en entreprise, ...), il faut lancer un serveur comme doh-proxy ou dnscrypt-proxy pour se créer un serveur DoH local.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 01 septembre 2022 à 16:41:35
chrome 105 est dispo en version finale avec le support de ECH
testé sous windows
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 01 septembre 2022 à 18:13:08
Fonctionne également sur mac (m1) en ipv4 et v6
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 07 septembre 2022 à 00:48:32
Chrome 105 est sorti sur android
Sans surprise ca fonctionne également

Manque plus que apple le supporte dans webkit… pas demain la veille…
Et bien sur il faudrait que les sites Web s’y mettent sérieusement
Je pense que cloudflare e sera le premier
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 07 septembre 2022 à 07:27:00
Les opérateurs qui font du DPI vont avoir un problème...

ECH peut fonctionner avec HTTP/1.1 ? (oui, c'est assez tordu d'avoir un serveur qui supporte ECH mais pas HTTP/2)
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 07 septembre 2022 à 10:15:33
Il n'y a pas de limitation concernant le protocole qui est encapsulé dans le TLS, donc ça peut fonctionner en HTTP/1.1 sans problème.

Puisqu'il est nécessaire de récupérer l'enregistrement "HTTPS" pour le paramètre ECHConfig, en toute logique le client devrait savoir si HTTP/2 et HTTP/3 sont supportés.
C'est surtout utile pour HTTP/3 (se connecter en QUIC, donc UDP), parce que quand on se connecte au port TCP 443, il y a l'extension TLS ALPN qui décrit les protocoles supportés (par exemple "http/1.1,h2").
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 07 septembre 2022 à 11:17:41
Citation de: vivien le 07 septembre 2022 à 07:27:00
Les opérateurs qui font du DPI vont avoir un problème...

ECH peut fonctionner avec HTTP/1.1 ? (oui, c'est assez tordu d'avoir un serveur qui supporte ECH mais pas HTTP/2)

Si je ne m’abuse en France, ce n’est pas autorisé non ? Sauf dans le cadre d’entreprise privées
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 07 septembre 2022 à 11:41:12
Le DPI n'est pas autorisé en Europe, mais il est très répandu hors d'Europe avec des distinctions tarifaires ou de débit (limitation à 2 Mb/s par exemple) en fonction du SNI.

On voit aussi beaucoup de blocages qui se basent sur le SNI.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: pioup le 07 septembre 2022 à 12:58:24
C'est juste une réduction plus ou moins forte du débit les pass "streaming", "surf" et "réseaux sociaux" chez Air France ou c'est du dpi?
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 07 septembre 2022 à 13:39:20
Pas de DPI chez Air France pour la limitation du débit.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 09 septembre 2022 à 13:49:10
Étrangement ms a décidé de retirer (ou de reporter) la fonction dans edge
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 09 septembre 2022 à 14:27:26
Malgré sa base Chromium, Edge a du retard sur plusieurs nouveautés du web.

J'ai du mal à comprendre pourquoi.

Sur AVIF, c'est le seul navigateur à ne pas prendre en charge ce format d'image :

(https://lafibre.info/images/format/avif_support.webp) (https://lafibre.info/images/format/webp_support.webp)

(https://lafibre.info/images/ssl/tls13_support.webp) (https://lafibre.info/images/ssl/http3_support.webp)

(https://lafibre.info/images/tv/vp9_support.webp) (https://lafibre.info/images/tv/opus_support.webp)
Lien ver le schéma combinant le support du codec vidéo VP9 et du codec audio Opus (https://lafibre.info/images/tv/vp9_opus_support.webp) (les deux sont habituellement utilisés ensemble, même si quelques grandes plateformes sont capables de dissocier le codec vidéo du codec audio)
(https://lafibre.info/images/tv/hevc_support.webp) (https://lafibre.info/images/tv/av1_support.webp)
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: guilhemrambal le 13 novembre 2022 à 10:30:45
Bonjour,
Actuellement j’utilise la fonctionnalité de firefox qui peut voir l'enregistrement dns httpsvc, mais ce n'est pas exhaustif.
Savez vous si on a un moyen plus simple de voir si la fonctionnalité TLS ECS est utilisée sur un site web  ?

Bonne journée
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 13 novembre 2022 à 13:22:48
Citation de: guilhemrambal le 13 novembre 2022 à 10:30:45
Bonjour,
Actuellement j’utilise la fonctionnalité de firefox qui peut voir l'enregistrement dns httpsvc, mais ce n'est pas exhaustif.
Savez vous si on a un moyen plus simple de voir si la fonctionnalité TLS ECS est utilisée sur un site web  ?

Bonne journée

Pour l’instant à part quelques sites pour tester si la fonction est active sur navigateur Aucun site ne supporte ECH
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: guilhemrambal le 13 novembre 2022 à 17:16:44
Merci
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 15 février 2023 à 15:09:29
Firefox et chrome sont entrain de dev un version sans webkit

J’espère que elle sera sur l’app store et avec ECH.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 03 mars 2023 à 19:58:38
https://iphoneaddict.fr/post/news-358922-premier-apercu-google-chrome-ios-moteur-non-webkit-dapple
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 02 avril 2023 à 19:01:05
Il ya un truc bizarre
j'ai testé aujourd'hui sur le pc de mon pere en egypte de me connecter a RSF (qui est bloqué)
sur chrome c'est en échec une première fois, puis ça recharge automatiquement et ça fonctionne
sur firefox c'est tout le temps en echec

sachant que a l'epoque avec ESNI ca fonctionnait et que ech semble pas actif sur rsf (https://rsf.org/cdn-cgi/trace donne cleartext sni)

voci les pcap en PJ

ajoutez le filtre ip.addr ne 92.184.104.98 pour masquer le rdp

ou

 ip.addr eq 172.67.66.183 pour chrome et ip.addr eq 104.25.93.108 pour firefox
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: vivien le 02 avril 2023 à 21:13:00
Je ne vois pas d'information sur les deux captures, mais il manque le début (c'est bien d'avoir une connexion TCP depuis le paquet [SYN]).

Autre chose m'interpelle : l'utilisation de TLS 1.2 alors que https://rsf.org gère TLS 1.3 (et les navigateurs aussi). Comment expliquer que TLS 1.2 soit utilisé ?
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 02 avril 2023 à 22:00:26
Citation de: adhame95 le 02 avril 2023 à 19:01:05
sachant que a l'epoque avec ESNI ca fonctionnait et que ech semble pas actif sur rsf (https://rsf.org/cdn-cgi/trace donne cleartext sni)
Il n'y a pas d'ECH pour rsf.org (cf about:networking#dnslookuptool dans Firefox, pas de "echConfig").
Mais Chrome envoie quand même l'extension (Wireshark indique "Unknown type 65037").
Il s'agit de GREASE ECH : https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15#name-grease-ech.
Je suppose que ça a deux rôles :
 - faire comme GREASE (qui est aussi utilisé) : s'assurer que les différents serveurs et intermédiaires (proxy, ...) n'ont pas de bugs quand ils voient des extensions qu'ils ne connaissent pas
 - noyer le trafic ECH dans le reste
Ici, même avec le SNI rsf.org, ça semble permettre de contourner le blocage.

Pour Firefox, il y a :
 - security.tls.ech.grease_probability (pourcentage des connexions TLS qui ont GREASE ECH activé) : 0 par défaut, 50 sur Nightly
 - security.tls.ech.grease_http3 (activation de GREASE ECH en HTTP/3) : false par défaut

Avec security.tls.ech.grease_probability=100, le comportement serait similaire à Chrome, ça peut permettre de contourner les blocages aussi.
Citation de: vivien le 02 avril 2023 à 21:13:00
Autre chose m'interpelle : l'utilisation de TLS 1.2 alors que https://rsf.org gère TLS 1.3 (et les navigateurs aussi). Comment expliquer que TLS 1.2 soit utilisé ?
Le Client Hello a pour version TLS 1.2, mais l'extension supported_versions indique TLS 1.2, TLS 1.3 (et GREASE pour Chrome).
C'est normal, puisque les navigateurs supportent le deux versions, le serveur répond avec la plus récente qu'il supporte.
Wireshark renseigne probablement la colonne protocole à partir de la version vue dans l'extension supported_versions du Server Hello.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 08 avril 2023 à 22:36:38
Citation de: hwti le 02 avril 2023 à 22:00:26
Il n'y a pas d'ECH pour rsf.org (cf about:networking#dnslookuptool dans Firefox, pas de "echConfig").
Mais Chrome envoie quand même l'extension (Wireshark indique "Unknown type 65037").
Il s'agit de GREASE ECH : https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15#name-grease-ech.
Je suppose que ça a deux rôles :
 - faire comme GREASE (qui est aussi utilisé) : s'assurer que les différents serveurs et intermédiaires (proxy, ...) n'ont pas de bugs quand ils voient des extensions qu'ils ne connaissent pas
 - noyer le trafic ECH dans le reste
Ici, même avec le SNI rsf.org, ça semble permettre de contourner le blocage.

Pour Firefox, il y a :
 - security.tls.ech.grease_probability (pourcentage des connexions TLS qui ont GREASE ECH activé) : 0 par défaut, 50 sur Nightly
 - security.tls.ech.grease_http3 (activation de GREASE ECH en HTTP/3) : false par défaut

Avec security.tls.ech.grease_probability=100, le comportement serait similaire à Chrome, ça peut permettre de contourner les blocages aussi.Le Client Hello a pour version TLS 1.2, mais l'extension supported_versions indique TLS 1.2, TLS 1.3 (et GREASE pour Chrome).
C'est normal, puisque les navigateurs supportent le deux versions, le serveur répond avec la plus récente qu'il supporte.
Wireshark renseigne probablement la colonne protocole à partir de la version vue dans l'extension supported_versions du Server Hello.

Merci pour ces explications,

Première remarque : security.tls.ech.grease_http3 n’est pas present dans la dernière version de Firefox (stable)

2) dans nightly les 2 options sont actives par defaut et grease probability est a 100
Mais bizarrement, ça ne fonctionne pas
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: hwti le 09 avril 2023 à 14:52:30
Citation de: adhame95 le 08 avril 2023 à 22:36:38
2) dans nightly les 2 options sont actives par defaut et grease probability est a 100
Effectivement, ça a changé entre temps.

Citation de: adhame95 le 08 avril 2023 à 22:36:38
Mais bizarrement, ça ne fonctionne pas
Chrome met le SNI vers la fin des extensions, avec notamment le GREASE ECH (282 octets) avant.
Firefox met le SNI en premier, et le GREASE ECH en dernier.
Donc peut-être que le système de DPI est limité dans la taille des données qu'il peut analyser, ou qu'il s'arrête quand il voit l'extension ECH, ou que la taille inhabituelle de l'extension le fait bugger.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: Antoinel le 04 octobre 2023 à 23:35:43
C'est passé inaperçu : Cloudflare a activé le ECH sur toutes les zones DNS gratuites hébergés chez eux (ceux qui paient sont sur OFF par défaut avec un paramètre dans l'espace client).

https://blog.cloudflare.com/announcing-encrypted-client-hello/


Je viens de tester avec Chrome et Firefox, ça marche (en tout cas d'après les divers "testeurs" sur le net) après quelques étapes relativement complexe : j'ai un AdGuard Home qui sert de serveur DNS avec blocklist, j'ai du configuré la partie serveur DoH avec certificat SSL valide notamment et puis forcé dans Chrome / Firefox d'utiliser ECH + DoH.
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: Antoinel le 04 octobre 2023 à 23:46:55
Par contre, il y a certains sites qui ne fonctionnent plus* : https://www.nextinpact.com/ me donne un ERR_ECH_FALLBACK_CERTIFICATE_INVALID (Chrome) et MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT (Firefox).

Il commence à avoir des retours négatifs :

https://community.cloudflare.com/t/getting-ech-fallback-certificate-error/565167
https://support.google.com/chrome/thread/237711423/chrome-throws-err-ech-fallback-certificate-invalid-errror

Une discussion technique sur l'activation de ECH par Cloudflare : https://github.com/haproxy/haproxy/issues/1924


* Je sais pas si c'est ma config ...
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: adhame95 le 07 octobre 2023 à 18:41:09
Ça coïncide avec l’activation par défaut sur chrome et Firefox
Maintenant il suffit d’activer DoH pour avoir ECH
Titre: ECH (Encrypted Client Hello) / ESNI où la fin de la surveillance d'internet
Posté par: Antoinel le 11 octobre 2023 à 20:14:31
Marche arrière pour Cloudflare, ECH est désactivé pour tout le monde suite à des bugs.

https://community.cloudflare.com/t/early-hints-and-encrypted-client-hello-ech-are-currently-disabled-globally/567730