Cloudflare a fait son entrée le 27 septembre 2010. Depuis, nous considérons le 27 septembre comme notre date d'anniversaire. Ce jeudi, nous fêterons nos 8 ans.
Depuis le début, nous profitons de l'occasion pour lancer de nouveaux produits ou services. Au fil des ans, nous en sommes venus à la conclusion qu'il ne s'agissait pas tant de lancer des produits qui nous permettraient de gagner de l'argent que de faire des cadeaux à nos utilisateurs et à l'Internet en général pour fêter notre anniversaire. Ma cofondatrice Michelle a rédigé hier un excellent article de blog sur cette tradition.
Pour ma part, l'un des moments dont je suis le plus fier chez Cloudflare est notre anniversaire en 2014, lorsque nous avons rendu la prise en charge HTTPS gratuite pour tous nos utilisateurs. À l'époque, on nous a traités de fous, et ce littéralement et à maintes reprises. Pour être honnête, nous avons longuement débattu en interne pour savoir si nous étions fous puisque le cryptage était la principale raison pour laquelle les gens passaient d'un compte gratuit à un compte payant.
Mais c’était la bonne chose à faire. Le fait que le cryptage n'ait pas été intégré au Web dès le début était, dans notre esprit, une anomalie. Aujourd'hui, quatre ans plus tard presque jour pour jour, le web est crypté à près de 80 % grâce aux efforts de grands projets comme Let's Encrypt, des équipes de développeurs chez Google, Apple, Microsoft et Mozilla, et du fait que de plus en plus de fournisseurs de services SaaS et d’hébergement prennent en charge HTTPS gratuitement. Je suis fier du fait que nous ayons été un chef de file dans l'amorce de cette tendance.
J'espère que je pourrai être tout aussi fier de ce que nous allons faire aujourd'hui, car nous espérons participer au lancement d'une nouvelle tendance visant à rendre le Web crypté plus privé et sécurisé. Pour comprendre cela, vous devez comprendre un peu pourquoi le Web crypté tel qu'il existe aujourd'hui continue de dévoiler une grande partie de votre historique de navigation.
Votre historique de navigation est-il vraiment confidentiel ?
Lorsque vous visitez un site via HTTPS, vous vous attendez à ce que personne ne puisse vous épier. Dans une certaine mesure, c’est le cas. Sur le site Web de votre banque, le protocole HTTPS empêche efficacement que le contenu envoyé vers ou à partir du site (par exemple, votre nom d'utilisateur et votre mot de passe, ou le solde de votre compte bancaire) ne soit divulgué à votre FAI ou à toute autre personne surveillant votre connexion.
Bien que le contenu envoyé ou reçu d'un site HTTPS soit protégé, il existe plusieurs moyens simples de savoir que vous avez accédé à ce site. Les DNS ont toujours été l'un d'entre eux. Par défaut, les requêtes DNS ne sont pas cryptées, de sorte que votre FAI ou toute autre personne peut voir où vous naviguez. C’est pourquoi, en avril dernier, nous avons lancé 1.1.1.1, un résolveur DNS public et gratuit (et insolemment rapide) prenant en charge DNS over TLS et DNS over HTTPS.
1.1.1.1 a rencontré un vif succès et nous avons considérablement augmenté le pourcentage de requêtes DNS envoyées via une connexion cryptée. Les critiques, cependant, ont souligné à juste titre que l'identité des sites que vous visitez peut encore fuiter par d'autres moyens. Le plus problématique est ce que l'on appelle l'extension Server Name Indication (SNI).
À quoi sert le protocole SNI ?
Le SNI existe essentiellement pour permettre d'héberger plusieurs sites Web cryptés sur une même adresse IP. Les premiers navigateurs ne comprenaient pas d'extension SNI. Par conséquent, au moment de la demande d'établissement d'une connexion HTTPS, le serveur Web ne disposait pas de beaucoup d'informations et ne pouvait restituer qu'un seul certificat SSL par adresse IP écoutée.
Pour résoudre ce problème, une solution consistait à créer des certificats avec plusieurs noms alternatifs (Subject Alternative Names, SAN). Ces certificats cryptaient le trafic de plusieurs domaines qui pouvaient tous être hébergés sur la même adresse IP. C'est ainsi que Cloudflare gère le trafic HTTPS des anciens navigateurs qui ne prennent pas en charge le SNI. Nous limitons cette fonctionnalité à nos clients payants, cependant, pour la même raison que les SAN ne sont pas une bonne solution : ils sont fastidieux à gérer et peuvent ralentir les performances s'ils comprennent trop de domaines.
La solution la plus flexible était le SNI. La comparaison que je trouve la plus pertinente est celle d'une enveloppe postale. Le contenu de l'enveloppe est protégé et le facteur ne peut pas le voir. Cependant, elle comporte une adresse que le service postal utilise pour la distribuer dans le bon bâtiment. Sur Internet, l'adresse IP d'un serveur Web est l'équivalent d'une adresse postale.
Cependant, si vous habitez dans un immeuble, celle-ci ne suffit pas pour que l'enveloppe parvienne au bon destinataire. En plus de l'adresse, vous devez indiquer un numéro d'appartement ou le nom du destinataire. C’est l’équivalent du SNI. Si un serveur Web héberge plusieurs domaines, le SNI garantit qu'une requête est acheminée vers le bon site afin que le bon certificat SSL puisse être renvoyé pour pouvoir crypter et décrypter tout contenu.
Réseaux indiscrets
La norme SNI a été présentée par l'IETF en 2003 et les navigateurs ont commencé à le prendre en charge au cours des années qui ont suivi. À l'époque, le compromis semblait acceptable. La grande majorité du trafic sur Internet n'était pas cryptée. L'ajout d'une extension TLS facilitant la prise en charge du chiffrement semblait une excellente solution, même si cette extension n'était pas elle-même chiffrée.
Mais, aujourd'hui, comme le protocole HTTPS représente près de 80 % de l'ensemble du trafic Web, le fait que le SNI dévoile à votre FAI et à tous les autres utilisateurs en ligne l'adresse de tous les sites que vous consultez est devenu une véritable faille en matière de confidentialité. Savoir quels sites vous visitez peut dresser un portrait très précis de vous, ce qui crée à la fois des risques pour la vie privée et pour la sécurité.
Aux États-Unis, les FAI ont brièvement vu leur capacité à collecter les données de navigation des clients limitée par les règles de la FCC adoptées à la fin de l'administration Obama. Cependant, les FAI ont fait pression sur le Congrès et, en avril 2017, le Président Trump a signé une résolution du Congrès abrogeant ces protections. À mesure que les FAI acquièrent des entreprises de médias et des entreprises de publicité ciblée, le fait de pouvoir extraire les données qui circulent dans leurs réseaux constitue pour eux une activité toujours plus alléchante et nous pose à tous un problème de protection des données personnelles de plus en plus préoccupant.
Combler la faille de confidentialité du SNI
Le 3 mai, environ un mois après le lancement de 1.1.1.1, je lisais un article sur notre nouveau service. Bien que l'article fit l'éloge du fait que 1.1.1.1 était axé sur la protection de la vie privée, il concluait avec un certain nihilisme que tout était inutile, car les FAI pouvaient encore vous surveiller avec le SNI. Furieux, j'ai envoyé un e-mail à certains ingénieurs de Cloudflare et à l'équipe senior de Mozilla, avec qui nous avions travaillé sur un projet de cryptage des DNS. J’ai conclu mon e-mail par ceci :
C’est simple : si Firefox se connecte à une IP Cloudflare, nous vous donnerons une clé publique à utiliser pour chiffrer l'entrée SNI avant de nous l'envoyer. Comment adapter cela à d'autres fournisseurs ? Je ne sais pas, mais il faut bien commencer quelque part. La solution était toute trouvée, non ?
Il s'est avéré que c'était un peu plus compliqué que ça. Cependant, aujourd'hui, je suis fier d'annoncer que le SNI crypté (ESNI) est opérationnel sur le réseau Cloudflare. Dans le courant de la semaine, Firefox de Mozilla devrait devenir le premier navigateur à prendre en charge le nouveau protocole dans sa version Nightly. Dans les mois à venir, nous prévoyons de généraliser cette tendance. Ils ne sont pas les seuls. Tous les principaux développeurs de navigateurs se sont montrés très intéressés, et j'espère qu'ils ajouteront tous la prise en charge ESNI avec le temps.
Nous espérons lancer une nouvelle tendance
Bien que nous soyons les premiers à prendre en charge ESNI, nous ne l'avons pas créé seuls. Nous avons travaillé sur ESNI avec d'excellentes équipes d'Apple, de Fastly, de Mozilla et d'autres entreprises du secteur qui, comme nous, se soucient du respect de la confidentialité sur Internet. Bien que Cloudflare soit le premier réseau de contenu à prendre en charge l'ESNI, il ne s'agit pas d'un protocole propriétaire. Il est en cours d'élaboration en tant queprojet de RFC de l'IETF, et nous espérons que d'autres organismes nous aideront à le concrétiser et à le mettre en œuvre. Si vous voulez en savoir plus sur les détails techniques de l'ESNI, vous pouvez consulter l'excellent article de blog de mon collègue Alessandro Ghedini. Enfin, lorsque la prise en charge par les navigateurs sera lancée vers la fin de la semaine, vous pourrez effectuer un test avec notre astucieux outil de test ESNI.
Je suis fier que nous ayons contribué, il y a quatre ans, à lancer une tendance qui a conduit aujourd'hui à ce que presque tout le Web soit crypté. Aujourd'hui, j'espère que nous contribuons encore une fois à lancer une tendance, cette fois pour rendre le Web crypté encore plus privé et sécurisé.
Abonnez-vous à notre blog pour recevoir quotidiennement des informations concernant toutes nos annonces de la Semaine d'anniversaire.