Auteur Sujet: Encrypted SNI où la fin de la surveillance d'internet / bridage DPI  (Lu 10812 fois)

0 Membres et 1 Invité sur ce sujet

adhame95

  • Client Monaco Telecom
  • *
  • Messages: 131
  • Monaco
    • Facebook
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #24 le: 27 janvier 2021 à 13:39:06 »
firefox 85 est sorti en finale, dommage que cloudflare ne prenne pas encore en charge ECH

il faut aussi activer network.dns.upgrade_with_https_rr

https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

vivien

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

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

Écrit par Kevin Jacobs, le 7 janvier 2021

Contexte

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

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

Arrivée du Encrypted Client Hello (ECH)

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

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

ECH dans Firefox 85

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

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

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

hwti

  • Client Orange Fibre
  • *
  • Messages: 1 548
  • Chambly (60)
Encrypted SNI où la fin de la surveillance d'internet / bridage DPI
« Réponse #26 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  ???

 

Mobile View