[go: up one dir, main page]
More Web Proxy on the site http://driver.im/Aller au contenu

Server Name Indication

Un article de Wikipédia, l'encyclopédie libre.

L'Indication du nom de serveur, ou Server Name Indication (SNI), est une extension du protocole TLS[1], utilisé pour sécuriser les communications entre un client (par exemple un navigateur web) et un serveur web via Internet. L'extension SNI est cruciale pour permettre aux serveurs d'héberger plusieurs noms de domaine sous une seule adresse IP. Un même serveur peut grâce à cette extension mutualiser l'hébergement de plusieurs domaines : truc.fr, machin.org, bidule.com... peuvent être hébergés sur une même machine.

Les navigateurs web modernes prennent en charge le SNI depuis 2013[2]. Lorsque le navigateur ne gère pas le SNI, le serveur fournit le certificat par défaut, et un avertissement au sujet du certificat se produit donc le plus souvent. Dès 2024, les navigateurs les plus récents comprennent également une nouvelle extension à TLS, appelée ECH, permettant de chiffrer la communication de bout en bout dès le premier message.

Fonctionnement et motivation

[modifier | modifier le code]

C'est lors du Client Hello du protocole TLS, c'est-à-dire le premier message TLS de négociation entre client et serveur, que le client indique au serveur le nom de domaine auquel il veut accéder. C'est là l'évolution majeure du SNI : l'indication du nom de serveur. Cela permet au serveur de présenter le certificat électronique X.509 approprié pour le nom de domaine demandé, dès le début de la négociation TLS. Auparavant, un serveur sans SNI ne pouvait utiliser qu'un seul certificat X.509 pour toutes les connexions TLS, indépendamment du nombre de domaines hébergés sur l'adresse IP.

Avec SNI, le serveur peut présenter des certificats différents selon le nom de domaine spécifié dans le champ «ServerName» du premier message de négociation TLS. Cela permet non seulement une meilleure gestion des certificats mais aussi une adaptation plus fine aux exigences de sécurité spécifiques de chaque site hébergé, puisque chaque certificat peut être optimisé pour des configurations de sécurité différentes, selon les besoins de chaque nom de domaine. En outre, cela optimise l'utilisation des ressources IP dans le contexte des raréfactions des adresses IPv4.

L'extension a donc ajouté au premier message de négociation TLS une extension : le champ «ServerName», qui accepte une liste de noms de domaine codés en UTF-8. Il peut être en effet avantageux que le serveur sache que le client souhaite accéder à plusieurs noms : commerce.bidule.fr, api.bidule.fr, etc., afin de déterminer la réponse appropriée. Il est par ailleurs prévu que cette liste puisse contenir autre chose que des noms de domaine, mais cette possibilité n'est pas utilisée en pratique.

Une fois que le serveur a envoyé le certificat électronique adéquat, le navigateur l'examine et vérifie que le nom de domaine demandé est bien présent dans le certificat. Si une correspondance est trouvée, la connexion continue comme d'habitude. Sinon, l'utilisateur est généralement prévenu d'un problème et la connexion est alors interrompue, puisqu'un tel problème peut signaler une tentative d'attaque de l'homme du milieu. Cependant, certaines applications autorisent l'utilisateur à passer outre l'avertissement, et se connecter tout de même, l'utilisateur prenant alors seul la responsabilité de la confiance envers le certificat concerné.

Il est possible à un certificat électronique de couvrir plusieurs noms DNS, depuis longtemps. La norme X.509 v3 avait ajouté un champ subjectAltName qui permet à un certificat de préciser plusieurs noms DNS, et de préciser les jokers (wildcards). Cela ne répondait toutefois pas aux exigences de l'hébergement multiple, car il était long et coûteux de produire un certificat électronique, et les hébergeurs devaient donc en produire un nouveau à chaque nouveau nom de domaine. De même, depuis longtemps, l'hébergement virtuel permet à plusieurs noms de domaine DNS d'être hébergé sur un même serveur, grâce au champ Host: du protocole HTTP par exemple, mais les premiers échanges TLS arrivent avant même l'utilisation du protocole HTTP. SNI a donc rendu possible le chiffrement des communication de façon efficace, flexible et peu coûteuse pour les hébergeurs mutualisés[3].

SNI est victime de mesures de censure, notamment par des gouvernements qui cherchent à contrôler l'accès à l'information, dans des pays comme la Chine, l'Égypte, la Corée du Sud, la Turquie, le Turkménistan, les Emirats Arabes Unis, la Russie et l'Iran[4], les autorités bloquent des technologies de chiffrement (SNI, ECH...) pour contrôler l'accès à l'information[5],[6],[7].

Évolution avec l'Encrypted Client Hello (ECH)

[modifier | modifier le code]

Malgré ses avantages, SNI a un inconvénient majeur : il ne chiffre pas les noms des serveurs lors des échanges initiaux. Cela permet aux intermédiaires réseau (notamment les gouvernements via le fournisseur d'accès à Internet) d'espionner le nom des sites Web visités par un individu.

En réponse aux limites de SNI, l'extension TLS 1.3, Encrypted Client Hello (ECH)[8], a été développée pour renforcer la confidentialité des échanges. Contrairement à SNI qui ne chiffre pas le nom du serveur, ECH permet de chiffrer l'intégralité du message ClientHello, incluant le nom du serveur, rendant ainsi les tentatives d'espionnage nettement plus difficiles[9]. Ce mécanisme offre une protection accrue contre la censure et le filtrage basés sur le nom du serveur.

L'Encrypted Client Hello (ECH), proposé initialement par l'Internet Engineering Task Force (IETF), chiffre les communications en utilisant une clé publique partagée. Les clés publiques sont distribuées via DNS ou d'autres mécanismes de configuration préalable, permettant au client de les récupérer et de les utiliser pour chiffrer les informations avant de les envoyer au serveur.

Le protocole cryptographique SSL/TLS, introduit en 1994 par Netscape Communications pour sécuriser les communications sur un réseau d'ordinateurs, nécessitait à l'origine que chaque nom de domaine avec une connexion sécurisée ait sa propre adresse IP, chose difficile au vu de la raréfaction des IPv4. À partir de 2003, SNI a changé la donne en permettant à un seul serveur de présenter des certificats multiples pour différents sites hébergés sur une même adresse IP, améliorant ainsi l'utilisation des ressources IP limitées et réduisant les coûts pour les hébergeurs web.

En 2004, un correctif ajoutant TLS/SNI à OpenSSL a été créé par le projet EdelKey[10]. En 2006, ce correctif a été inclus dans la branche principale de OpenSSL, et porté sur l'ancienne version de OpenSSL 0.9.8 en 2007. Pour pouvoir implémenter correctement SNI, l'application doit en avoir connaissance, et passer le nom de domaine à sa bibliothèque TLS. La complication augmente quand on sait que de nombreux logiciels client ou serveur utilisent TLS sous forme d'un composant extérieur (une bibliothèque ou un greffon), dépendant du système d'exploitation.

L'implémentation de SNI dans les navigateurs a commencé en 2006 avec Mozilla Firefox 2.0 et Internet Explorer 7. D'autres navigateurs ont rapidement suivi, avec Opera intégrant le support de SNI à partir de la version 8.0, et Google Chrome offrant le support à partir de la version 6. En 2013, la plupart des navigateurs et bibliothèques TLS implémentaient correctement SNI, mais un grand nombre d'utilisateurs (environ 20%) avaient toujours une combinaison d'application et de logiciel client incompatibles avec SNI [11]. En 2019, ce nombre est passé sous la barre des 3%.

En 2020, une extension à SNI appelée Encrypted Client Hello (ECH) a été proposée pour chiffrer le SNI dès le premier message avec le serveur, améliorant la confidentialité en masquant les noms des serveurs durant les échanges initiaux. La spécification ECH a été avancée en 2020, et depuis, des navigateurs comme Google Chrome, Mozilla Firefox, et Microsoft Edge ont intégré ECH dans leurs versions respectives de 2023 et 2024. Chrome a introduit ECH en 2023 avec sa version 104, Firefox a suivi avec la version 119 en 2024, et Edge a implémenté ECH dès la version 108 en 2023[12],[13],[14].

Notes et références

[modifier | modifier le code]
  1. section de 3.1 de la norme RFC4366 qui décrit les extensions du TLS
  2. (en) « Can I use... Support tables for HTML5, CSS3, etc », sur caniuse.com (consulté le )
  3. {en} "TLS Server Name Indication". Paul's Journal.
  4. (en) « A Survey of Worldwide Censorship Techniques » (consulté le )
  5. « La Chine renforce sa censure sur l'internet », Le Monde (consulté le )
  6. (en) « How Encrypted SNI is reshaping censorship », NordVPN (consulté le )
  7. « L'Iran bloque l'accès à internet pour étouffer les protestations », RFI (consulté le )
  8. (en) « Document technique spécifiant l'extension TLS Encrypted Client Hello »
  9. (en) « TLS Encrypted Client Hello », Internet Engineering Task Force (consulté le )
  10. {en} http://www.edelweb.fr/EdelKey/
  11. Statistiques de navigateurs en Juillet 2013, 20 % des utilisateurs sont sous Windows XP, dont le navigateur Internet Explorer n'implémente pas SNI à cause de la bibliothèque TLS de Windows XP.
  12. « Understanding Encrypted Client Hello (ECH) », Internet Engineering Task Force (consulté le )
  13. « Firefox 119 Release Notes », Mozilla (consulté le )
  14. « Latest Edge 108 Stable brings better privacy with ECH », Neowin (consulté le )