Aujourd’hui, nous avons annoncé la prise en charge de la SNI chiffrée, une extension du protocole TLS 1.3 qui améliore la vie privée des utilisateurs Internet en empêchant les observateurs sur le trajet, notamment les ISP, les propriétaires de café et les pare-feux, d’intercepter l’extension SNI (TLS Server Name Indication) et l'utiliser pour déterminer quels sites Web sont visités par les utilisateurs.
La SNI chiffrée, associée aux autres fonctionnalités de sécurité Internet déjà offertes gratuitement par Cloudflare, rendra plus difficile la censure de contenu et le suivi des utilisateurs sur Internet. Lisez la suite pour savoir comment cela fonctionne.
SNWhy ?
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 à préciser le site auquel ils souhaitent se connecter lors l’établissement de la liaison initiale TLS. Sans SNI, le serveur ne saurait pas, 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 l’établissement de la liaison TLS. Malheureusement, le message ClientHello est envoyé non chiffré car le client et le serveur ne partagent pas de clé de chiffrement à ce stade.
TLS 1.3 sans SNI chiffré
TLS 1.3 avec SNI non chiffré
Cela signifie qu'un observateur sur chemin (par exemple, un ISP, propriétaire d'un café ou pare-feu) peut intercepter le message ClientHello en texte clair 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 le chiffrement SNI, le client chiffre le SNI même si le reste de ClientHello est envoyé en texte clair.
T_TLS 1.3 avec SNI chiffré_
TLS 1.3 avec SNI chiffré
Alors, comment se fait-il que le SNI d’origine n’a pas pu être chiffrée auparavant alors que c’est le cas maintenant ? D'où vient la clé de chiffrement si le client et le serveur n'en ont pas encore négocié une ?
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 dossier 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 dossiers). Le client remplace ensuite l’extension SNI dans ClientHello par une extension « SNI chiffrée », qui n’est autre que l’extension SNI d’origine, mais chiffrée à l’aide d’une clé de chiffrement 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 dorsal). Étant donné que seuls le client et le serveur auquel il se connecte peuvent extraire la clé de chiffrement, le SNI chiffré ne peut pas être déchiffré 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 en est très simple : une des modifications introduites par TLS 1.3 (non sans problèmes) signifiait déplacer le message de certificat envoyé par le serveur vers la partie chiffrée de l'établissement de liaison TLS (avant la version 1.3, il était envoyé en texte en clair). Sans cette modification fondamentale du protocole, un pirate 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ée par le client lui-même à la volée et détruite 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 de SNI chiffré réels, mais également le partage de clé publique du client, l'ensemble de chiffrement qu’il a utilisé pour le chiffrement et le résumé du dossier 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.
Si cela peut sembler excessivement compliqué, cela garantit que la clé de chiffrement 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 pour plusieurs connexions. Cela empêche un pirate capable d'observer l'extension chiffrée envoyée par le client de la capturer simplement et de la retransmettre au serveur dans une autre session afin de démasquer l'identité du site Web auquel l'utilisateur tentait de se connecter (ceci est connu sous le nom d'attaque de « rapiéçage »).
Cependant, une défaillance de la clé privée du serveur mettrait en péril toutes les clés symétriques ESNI générées à partir de celle-ci (ce qui permettrait aux observateurs de déchiffrer les données chiffrées précédemment collectées). C'est pourquoi l'implémentation du chiffrement SNI de Cloudflare fait pivoter les clés du serveur toutes les heures pour améliorer la confidentialité, mais garde une trace des clés des dernières heures pour permettre la mise en cache DNS et les retards de réplication. Ainsi, les clients ayant des clés légèrement obsolètes puissent toujours utiliser ESNI sans problème (mais finalement toutes les clés sont jetées et oubliées).
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 chiffré) rendrait totalement inutile l'idée de SNI chiffré : un observateur sur chemin serait en mesure de déterminer le site Web auquel le client se connecte en observant simplement les requêtes DNS en texte clair envoyées par le client lui-même, que le SNI chiffré soit 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 la propre version de Cloudflare 1.1.1.1), les requêtes DNS peuvent désormais être chiffrées et à l'abri des regards curieux des censeurs et traqueurs.
Cependant, bien que les réponses des résolveurs DNS DoT/DoH sont fiables, dans une certaine mesure (malgré les résolveurs malveillants), un pirate déterminé peut toujours empoisonner le cache du résolveur en interceptant sa communication avec le serveur DNS faisant autorité et en injectant des données malveillantes. Autrement dit, à moins que le serveur faisant autorité et le résolveur prennent en charge DNSSEC [1]. Notamment, 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.
Qu'en est-il de l'adresse IP ?
Alors que les requêtes DNS et les extensions TLS SNI peuvent désormais être protégées contre des pirates 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 leurs appareils. 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. Cependant, cela ne suffit pas et il faut déployer davantage d'efforts pour protéger le plus d’utilisateurs finaux possible. Restez à l'écoute pour plus de mises à jour de Cloudflare sur le sujet à l'avenir.
Où puis-je m'inscrire ?
Le SNI chiffré est maintenant activé gratuitement sur toutes les zones Cloudflare en utilisant nos serveurs de noms. Vous n'avez donc rien à faire pour l'activer sur votre site Web Cloudflare. Concernant le navigateur, nos collègues de Firefox nous ont dit qu’ils s’attendent à ajouter la prise en charge de SNI chiffrée cette semaine à Firefox Nightly (gardez à l’esprit que la spécification SNI chiffrée est encore en développement, elle n’est donc pas encore stable).
En visitant encryptedsni.com, 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 à l’abri des regards indiscrets.
Conclusion
Le SNI chiffré, ainsi que TLS 1.3, DNSSEC et DoT/DoH, bloquent l’une des rares failles restantes qui facilitent la surveillance et la censure sur Internet. Il y a encore du travail pour obtenir un Internet sans surveillance, mais nous y parviendrons (lentement mais sûrement).
[1] : Il est important de mentionner que DNSSEC pourrait être désactivé par le détournement d'adresse IP 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.
Abonnez-vous à notre blog pour recevoir quotidiennement des informations concernant toutes nos annonces de la Semaine d'anniversaire.