Server Name Indication (SNI) : que signifie cette norme ?

La sécurité joue un rôle très important sur Internet. Par conséquent, les normes, les certificats et les protocoles tentent de protéger à la fois les utilisateurs et les serveurs contre les attaques malveillantes. L’un de ces protocoles est appelé Transport Layer Security (TLS). Cependant, il existe des problèmes avec son utilisation. Mais avec le Server Name Indication (SNI), qui peut se traduire par « indication de nom de serveur », une extension du protocole a été créée.

Avant de pouvoir comprendre pourquoi le SNI a été développé, il est important de comprendre comment fonctionne TLS. Le successeur du protocole SSL (Secure Sockets Layer) dispose d’un Handshake TLS. Le client et le serveur (dans la pratique, il s’agit en général du navigateur Web et du site Web) échangent des informations avant que le transfert de données proprement dit ne commence. Dans ce Handshake virtuel (ou établissement d’une liaison), le serveur s’identifie au client et envoie également le certificat de sécurité correspondant. Ce n’est qu’après vérification par le client que les deux partenaires de communication établissent une connexion et échangent alors des données. Si la vérification est négative, aucune autre transmission de données n’a lieu.

Mais que se passe-t-il si plusieurs sites Web fonctionnent sur une même adresse IP, comme avec l’hébergement virtuel (Virtual Hosting) ? Comme IPv6 n’est pas encore établi, nous travaillons dans un cadre d’adresses IP très limité, et tous les domaines ne peuvent donc pas revendiquer leur propre adresse IP pour eux-mêmes. A qui le client adresse-t-il alors son « Hello » (la première étape d’un Handshake TLS) ? La probabilité que le mauvais site Web réagisse, n’envoie pas le bon certificat (avec le bon nom d’hôte) et n’établisse pas la connexion est élevée. Il est ainsi nécessaire que le client indique au serveur à quel domaine (hôte) il souhaite établir une connexion. C’est pourquoi le Server Name Indication a été introduit.

Dans le cas d’une connexion non sécurisée, si plusieurs sites Web fonctionnent sur une adresse IP, en principe vous n’avez pas ce problème. Dans HTTP, le nom d’hôte est spécifié dans un en-tête lorsqu’un site Web est demandé. Avec TLS, cependant, le Handshake doit avoir lieu avant même que le navigateur Web puisse envoyer ces informations. L’indication de nom de serveur garantit que le nom d’hôte est déjà transmis entre le serveur et le client avant l’échange du certificat.

SNI est une extension de TLS. Le protocole de chiffrement fait partie de la pile de protocoles TCP/IP. Ainsi, TLS apporte le chiffrement au protocole TCP (Transmission Control Protocol). La couche supplémentaire rend également HTTP en HTTPS. Si TLS a été étendu par l’indication du nom du serveur, le protocole de sécurité fournit un champ supplémentaire pour le handshake : sous le champ ClientHelloExtension, vous trouverez le champ facultatif ServerName. Dans ce champ, le client (le navigateur Web le fait automatiquement) entre le nom de l’hôte auquel il veut s’adresser. Cela permet de s’assurer que le bon hôte répond.

En tant qu’internaute ordinaire, vous ne devriez rien remarquer à propos de SNI. En effet, dans la plupart des cas, les utilisateurs n’ont pas besoin d’installer ou de configurer quoi que ce soit. Il suffit juste d’utiliser un système d’exploitation actuel et un navigateur moderne. Firefox, Chrome, Edge, Opera et Safari supportent l’extension par défaut. Seuls les utilisateurs qui utilisent encore Windows XP (ou même des versions antérieures de Windows) et Internet Explorer ne peuvent pas utiliser l’indication de nom de serveur. Si vous utilisez toujours le système d’exploitation qui n’est plus pris en charge par les mises à jour, vous pouvez utiliser un autre navigateur qui prend en charge le SNI. La majorité des navigateurs mobiles utilisent également le SNI.

La situation est différente si vous êtes vous-même l’opérateur d’un serveur Web, car vous devrez peut-être prendre des mesures en fonction du serveur Web que vous utilisez. Depuis IIS 8, Microsoft a intégré une option pour l’indication de nom de serveur dans son logiciel par défaut. Le serveur HTTP Apache est un peu différent : ici, il est possible d’intégrer SNI en utilisant OpenSSL (ou mod_ssl). En principe, vous n’avez qu’à exécuter le module avec des extensions TLS (la version 0.9.8k est de toute façon prédéfinie). Des instructions détaillées pour configurer SNI sous Apache se trouvent dans le Wiki du serveur HTTP Apache.

Aussi sous Nginx, le support SNI est fourni avec la version 0.5.23 et fonctionne en principe comme sous Apache. Vous pouvez vérifier si votre version supporte le Server Name Indication avec la commande nginx -V. Si c’est le cas, en tant que Webmaster, vous donnez à chaque hôte virtuel son propre nom et lui attribuez le bon certificat. Plus d’informations peuvent être trouvées dans la documentation officielle de Nginx.

Le Server Name Indication n’a pas que des avantages. D’une part, le SNI n’est pas supporté par tous les navigateurs Web, mais cela ne concerne qu’un petit nombre d’utilisateurs. Le fait que le SNI n’est pas un modèle parfait, mais seulement une solution provisoire, peut être reconnu par le fait que des informations non chiffrées sont transmises. Ce n’est que le nom d’hôte, mais même cette information ne devrait pas pouvoir être exploitée par des tiers avec un chiffrement complet. Ainsi, plus de sécurité est donnée si vous n’avez pas à utiliser le SNI et si chaque site Web obtient sa propre adresse IP.

Comme cela ne peut pas être modifié en raison de la trame d’adresse IP serrée (au moins jusqu’à ce que IPv6 soit introduit au niveau mondial), d’autres possibilités doivent être trouvées. L’une de ces possibilités est le SNI. Un autre serait les certificatsSubject Alternative Name (SAN) : avec ces certificats, vous avez en effet la possibilité d’entrer plusieurs domaines ou noms d’hôtes. Cela signifierait à l’inverse que le domaine auquel le client souhaite réellement s’adresser n’a pas d’importance pour le serveur, car le certificat est valide pour tous les domaines du serveur. L’inconvénient de ces certificats, cependant, est qu’ils sont relativement chers. Par conséquent, de nombreux exploitants de sites Web ne sont pas disposés, ce qui est compréhensible, à mettre en œuvre de tels certificats. Ainsi, au lieu de n’utiliser aucun chiffrement, le SNI est et reste une bonne solution provisoire.