Server Name In­di­ca­tion (SNI) : que signifie cette norme ?

La sécurité joue un rôle très important sur Internet. Par con­sé­quent, les normes, les cer­ti­fi­cats et les pro­to­coles tentent de protéger à la fois les uti­li­sa­teurs et les serveurs contre les attaques mal­veil­lantes. L’un de ces pro­to­coles est appelé Transport Layer Security (TLS). Cependant, il existe des problèmes avec son uti­li­sa­tion. Mais avec le Server Name In­di­ca­tion (SNI), qui peut se traduire par « in­di­ca­tion de nom de serveur », une extension du protocole a été créée.

Avant de pouvoir com­prendre pourquoi le SNI a été développé, il est important de com­prendre comment fonc­tionne TLS. Le suc­ces­seur 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 na­vi­ga­teur Web et du site Web) échangent des in­for­ma­tions avant que le transfert de données pro­pre­ment dit ne commence. Dans ce Handshake virtuel (ou éta­blis­se­ment d’une liaison), le serveur s’identifie au client et envoie également le cer­ti­fi­cat de sécurité cor­res­pon­dant. Ce n’est qu’après vé­ri­fi­ca­tion par le client que les deux par­te­naires de com­mu­ni­ca­tion éta­blis­sent une connexion et échangent alors des données. Si la vé­ri­fi­ca­tion est négative, aucune autre trans­mis­sion de données n’a lieu.

Mais que se passe-t-il si plusieurs sites Web fonc­tion­nent sur une même adresse IP, comme avec l’hé­ber­ge­ment virtuel (Virtual Hosting) ? Comme IPv6 n’est pas encore établi, nous tra­vail­lons dans un cadre d’adresses IP très limité, et tous les domaines ne peuvent donc pas re­ven­di­quer 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 pro­ba­bi­lité que le mauvais site Web réagisse, n’envoie pas le bon cer­ti­fi­cat (avec le bon nom d’hôte) et n’établisse pas la connexion est élevée. Il est ainsi né­ces­saire que le client indique au serveur à quel domaine (hôte) il souhaite établir une connexion. C’est pourquoi le Server Name In­di­ca­tion a été introduit.

Dans le cas d’une connexion non sécurisée, si plusieurs sites Web fonc­tion­nent 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 na­vi­ga­teur Web puisse envoyer ces in­for­ma­tions. L’in­di­ca­tion 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 cer­ti­fi­cat.

SNI est une extension de TLS. Le protocole de chif­fre­ment fait partie de la pile de pro­to­coles TCP/IP. Ainsi, TLS apporte le chif­fre­ment au protocole TCP (Trans­mis­sion Control Protocol). La couche sup­plé­men­taire rend également HTTP en HTTPS. Si TLS a été étendu par l’in­di­ca­tion du nom du serveur, le protocole de sécurité fournit un champ sup­plé­men­taire pour le handshake : sous le champ Clien­tHel­loEx­ten­sion, vous trouverez le champ fa­cul­ta­tif Ser­ver­Name. Dans ce champ, le client (le na­vi­ga­teur Web le fait au­to­ma­ti­que­ment) 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’in­ter­naute ordinaire, vous ne devriez rien remarquer à propos de SNI. En effet, dans la plupart des cas, les uti­li­sa­teurs n’ont pas besoin d’installer ou de con­fi­gu­rer quoi que ce soit. Il suffit juste d’utiliser un système d’ex­ploi­ta­tion actuel et un na­vi­ga­teur moderne. Firefox, Chrome, Edge, Opera et Safari sup­por­tent l’extension par défaut. Seuls les uti­li­sa­teurs qui utilisent encore Windows XP (ou même des versions an­té­rieures de Windows) et Internet Explorer ne peuvent pas utiliser l’in­di­ca­tion de nom de serveur. Si vous utilisez toujours le système d’ex­ploi­ta­tion qui n’est plus pris en charge par les mises à jour, vous pouvez utiliser un autre na­vi­ga­teur qui prend en charge le SNI. La majorité des na­vi­ga­teurs mobiles utilisent également le SNI.

La situation est dif­fé­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’in­di­ca­tion 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 ex­ten­sions TLS (la version 0.9.8k est de toute façon pré­dé­fi­nie). Des ins­truc­tions dé­tail­lées pour con­fi­gu­rer 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 fonc­tionne en principe comme sous Apache. Vous pouvez vérifier si votre version supporte le Server Name In­di­ca­tion 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 cer­ti­fi­cat. Plus d’in­for­ma­tions peuvent être trouvées dans la do­cu­men­ta­tion of­fi­cielle de Nginx.

Le Server Name In­di­ca­tion n’a pas que des avantages. D’une part, le SNI n’est pas supporté par tous les na­vi­ga­teurs Web, mais cela ne concerne qu’un petit nombre d’uti­li­sa­teurs. Le fait que le SNI n’est pas un modèle parfait, mais seulement une solution pro­vi­soire, peut être reconnu par le fait que des in­for­ma­tions non chiffrées sont trans­mises. Ce n’est que le nom d’hôte, mais même cette in­for­ma­tion ne devrait pas pouvoir être exploitée par des tiers avec un chif­fre­ment 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 pos­si­bi­li­tés doivent être trouvées. L’une de ces pos­si­bi­li­tés est le SNI. Un autre serait les cer­ti­fi­cats Subject Al­ter­na­tive Name (SAN) : avec ces cer­ti­fi­cats, vous avez en effet la pos­si­bi­lité d’entrer plusieurs domaines ou noms d’hôtes. Cela sig­ni­fie­rait à l’inverse que le domaine auquel le client souhaite réel­le­ment s’adresser n’a pas d’im­por­tance pour le serveur, car le cer­ti­fi­cat est valide pour tous les domaines du serveur. L’in­con­vé­nient de ces cer­ti­fi­cats, cependant, est qu’ils sont re­la­ti­ve­ment chers. Par con­sé­quent, de nombreux ex­ploi­tants de sites Web ne sont pas disposés, ce qui est com­pré­hen­sible, à mettre en œuvre de tels cer­ti­fi­cats. Ainsi, au lieu de n’utiliser aucun chif­fre­ment, le SNI est et reste une bonne solution pro­vi­soire.