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

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
Edit : ECH (Encrypted Client Hello) est le successeur de ESNI (Encrypted SNI)

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.

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



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 :



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 :



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, le 24 septembre 2018, par Alessandro Ghedini

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #1 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, le 20 mai 2019 par Catalin Cimpanu

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #2 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)


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,...

Marco POLO

  • Abonné Free fibre
  • *
  • Messages: 2 132
  • FTTH 1 Gb/s sur Paris (75)
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #3 le: 24 mai 2019 à 17:49:34 »
Qu'est-ce qu'un résolveur ? Tout ce que j'ai trouvé, c'est ça ! Et comment savoir s'il valide les signatures DNSSEC

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #4 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.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #5 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.

Electrocut

  • Abonné Orange Fibre
  • *
  • Messages: 512
  • Pont-Péan (35)
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #6 le: 27 mai 2019 à 11:12:21 »
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 ?

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #7 le: 27 mai 2019 à 11:19:32 »
Oui, le nom de domaine entier.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #8 le: 28 mai 2019 à 02:33:03 »
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).

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #9 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.



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.



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



Vous pouvez vérifier l'activation d'Encrypted SNI sur https://www.cloudflare.com/ssl/encrypted-sni/

vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #10 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é !


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 :


Tout en bas de la page il faut cliquer sur Paramètres pour ouvrir les paramètres réseaux.


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:// )


Là Encrypted SNI est bien activé :


vivien

  • Administrateur
  • *
  • Messages: 46 992
    • Twitter LaFibre.info
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #11 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 support"1mshttps://dns11.quad9.net/dns-query
Switch Public DNSstandard26mshttps://dns.switch.ch/dns-query

Source : Wikipedia "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.


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.