Worldlex Wiki Contexte du problème
Avant l'introduction de SNI, lors de l'établissement d'une connexion TLS, le client ne pouvait pas spécifier le site auquel il tentait de se connecter. Par conséquent, si un serveur hébergeait plusieurs sites sur un seul écouteur, il ne pouvait pas déterminer quel certificat utiliser pour le protocole TLS. Plus précisément, lors de l'établissement d'une connexion TLS, le client demandait un certificat numérique au serveur web. Une fois le certificat reçu, le client l'examinait et comparait le nom du site auquel il tentait de se connecter avec le ou les noms figurant dans le certificat. En cas de correspondance, la connexion se poursuivait normalement. Dans le cas contraire, l'utilisateur pouvait être averti de l'anomalie et la connexion pouvait être interrompue, car cette divergence pouvait indiquer une tentative d'attaque de l'homme du milieu. Cependant, certaines applications permettaient à l'utilisateur de passer outre cet avertissement et de poursuivre la connexion, l'utilisateur assumant alors la responsabilité de faire confiance au certificat et, par conséquent, à la connexion elle-même.
Toutefois, il peut s'avérer difficile, voire impossible faute de liste exhaustive préalable de tous les noms, d'obtenir un certificat unique couvrant tous les noms dont un serveur sera responsable. Un serveur gérant plusieurs noms d'hôtes devra probablement présenter un certificat différent pour chaque nom (ou petit groupe de noms). Il est possible d'utiliser subjectAltName pour inclure plusieurs domaines contrôlés par une même personne dans un seul certificat. Ces « certificats de communications unifiées » doivent être renouvelés à chaque modification de la liste des domaines.
L'hébergement virtuel basé sur le nom permet à un seul serveur (généralement un serveur web) d'héberger plusieurs noms d'hôtes DNS sur la même adresse IP. Pour ce faire, le serveur utilise un nom d'hôte fourni par le client dans le cadre du protocole (en HTTP, ce nom figure dans l'en-tête Host). Cependant, avec HTTPS, la négociation TLS a lieu avant que le serveur ne reçoive les en-têtes HTTP. Par conséquent, le serveur ne peut pas utiliser les informations de l'en-tête Host HTTP pour déterminer quel certificat présenter ; seuls les noms couverts par le même certificat peuvent donc être servis depuis la même adresse IP.
Concrètement, cela signifiait qu'un serveur HTTPS ne pouvait héberger qu'un seul domaine (ou un petit groupe de domaines) par adresse IP pour une navigation sécurisée et efficace. Attribuer une adresse IP distincte à chaque site augmente le coût de l'hébergement, car les demandes d'adresses IP doivent être justifiées auprès du registre Internet régional et les adresses IPv4 sont désormais épuisées. Pour IPv6 , cela accroît la charge administrative du fait de la présence de plusieurs adresses IP sur une même machine, même si l'espace d'adressage n'est pas épuisé. De ce fait, de nombreux sites web se sont trouvés dans l'impossibilité d'utiliser des communications sécurisées.
Principes techniques
SNI résout ce problème en demandant au client d'envoyer le nom du domaine virtuel dans le cadre du message ClientHello de la négociation TLS. Cela permet au serveur de sélectionner rapidement le domaine virtuel approprié et de présenter au navigateur le certificat contenant le nom correct. Par conséquent, avec des clients et des serveurs compatibles SNI, un serveur disposant d'une seule adresse IP peut gérer un groupe de noms de domaine pour lesquels il est impossible d'obtenir un certificat commun.
Le protocole SNI a été ajouté aux RFC Internet de l' IETF en juin 2003 par le biais de la RFC 3546, Extensions de sécurité de la couche transport (TLS) . La version la plus récente de cette norme est la RFC 6066.
Implications en matière de sécurité
La charge utile d'indication du nom du serveur (SNI) n'est pas chiffrée ; par conséquent, le nom d'hôte du serveur auquel le client tente de se connecter est visible par un espion passif. Cette faille du protocole a été exploitée par des logiciels de sécurité pour le filtrage et la surveillance du réseau et par des gouvernements pour mettre en œuvre la censure
Actuellement, plusieurs technologies tentent de masquer l'indication du nom du serveur :
Frontage de domaine
La version initiale de cette extension, sortie en 2018, s'appelait Encrypted SNI (ESNI) . En mars 2020, ESNI a été remaniée et renommée extension ECH, suite à une analyse démontrant que le chiffrement du seul SNI était insuffisant. Par exemple, les spécifications autorisent l'extension de clé pré-partagée à contenir toutes les données nécessaires à la reprise de session, y compris la transmission d'une copie en clair du nom de serveur chiffré par ESNI. De plus, chiffrer les extensions une par une nécessiterait une version chiffrée de chaque extension, avec des implications potentielles en matière de confidentialité, et exposerait même l'ensemble des extensions déclarées. Enfin, le déploiement concret d'ESNI a mis en évidence des limitations d'interopérabilité. Le nom abrégé était ECHO en mars 2020 et est devenu ECH en mai 2020. En juillet 2023, lors de la réunion IETF117 , les membres travaillant sur ECH ont informé Chrome et Firefox qu'ils effectuaient un test sur un échantillon de 1 % et que l'équipe prévoyait de soumettre la version finale à l' évaluation de l'IESG d'ici janvier 2024.
En septembre 2023, Cloudflare a commencé à prendre en charge ECH pour les domaines hébergés.
En septembre 2023, la version 117 de Chromium (utilisée dans Google Chrome , Microsoft Edge , Samsung Internet et Opera ) a activé ECH par défaut, exigeant également le déploiement des clés dans les enregistrements de ressources HTTPS du DNS. ECH est activé par défaut dans Firefox depuis la version 119 sortie en octobre 2023, et Mozilla recommande son utilisation conjointe avec le DNS sur HTTPS .
En avril 2026, OpenSSL 4.0 a inclus la prise en charge d'ECH. Depuis sa version de décembre 2025, NGINX prend en charge ECH avec OpenSSL 4.0.
ESNI (2018–2020)
La version initiale de cette extension, sortie en 2018, s'appelait Encrypted SNI (ESNI) et son déploiement a été mené de manière expérimentale afin de contrer le risque d'écoute clandestine du domaine. Contrairement à ECH, Encrypted SNI cryptait uniquement le SNI et non l'intégralité du message Client Hello. La prise en charge optionnelle de cette version a été intégrée à Firefox en octobre 2018 et nécessitait l'activation du DNS sur HTTPS (DoH). Cette fonctionnalité a cependant été supprimée en janvier 2021 avec la sortie de Firefox 85.
ESNI et ECH ne sont compatibles qu'avec TLS 1.3 car ils s'appuient sur KeyShareEntry qui a été défini pour la première fois dans TLS 1.3.
En août 2020, le Grand Pare-feu de Chine a commencé à bloquer le trafic ESNI, tout en autorisant toujours le trafic ECH.
En octobre 2020, le fournisseur d'accès Internet russe Rostelecom et son opérateur mobile Tele2 ont commencé à bloquer le trafic ESNI. En septembre de la même année, le ministère russe de la censure, Roscomnadzor, prévoyait d'interdire plusieurs protocoles de chiffrement, dont TLS 1.3 et ESNI, ce qui entravait la censure de l'accès aux sites web.
Mise en œuvre
En 2004, le projet EdelKey a créé un correctif pour ajouter TLS/SNI à OpenSSL . En 2006, ce correctif a été intégré à la branche de développement d'OpenSSL, puis rétroporté en 2007 vers OpenSSL 0.9.8 (initialement publié dans la version 0.9.8f ). Les premiers navigateurs web compatibles SNI sont apparus en 2006 (Mozilla Firefox 2.0, Internet Explorer 7), suivis des serveurs web (Apache HTTP Server en 2009, Microsoft IIS en 2012).
Pour qu'une application prenne en charge SNI, la bibliothèque TLS qu'elle utilise doit l'implémenter et l'application doit lui transmettre le nom d'hôte. De plus, la bibliothèque TLS peut être intégrée à l'application ou faire partie du système d'exploitation. C'est pourquoi certains navigateurs prennent en charge SNI quel que soit le système d'exploitation, tandis que d'autres ne le font que sur certains systèmes.