Invisible pour la plupart des internautes, l’extension SNI joue pourtant un rôle décisif lorsqu’un navigateur ouvre une page en HTTPS. Sans elle, héberger plusieurs sites sécurisés sur une même adresse IP serait beaucoup plus complexe, plus coûteux et moins souple. Voici comment fonctionne Server Name Indication, pourquoi cette extension a transformé le déploiement de TLS, et quelles limites elle rencontre aujourd’hui.
SNI, pour Server Name Indication, est une extension du protocole TLS qui permet au client, le plus souvent un navigateur web, d’indiquer dès le début de la connexion le nom de domaine qu’il souhaite joindre. Cette information est transmise dans le message ClientHello, c’est-à-dire l’un des premiers messages échangés lors de la négociation TLS.
Son utilité est simple à comprendre avec un exemple concret. Un même serveur peut héberger plusieurs sites, comme exemple.com, boutique-exemple.fr et api.exemple.net, tous associés à la même adresse IP. Avant SNI, le serveur ne savait pas toujours quel certificat présenter au client au moment d’établir la connexion chiffrée. Grâce à SNI, il peut sélectionner le bon certificat TLS avant même que la session sécurisée ne soit complètement établie.
Historiquement, HTTPS posait une contrainte forte aux hébergeurs : une adresse IP distincte était souvent nécessaire pour chaque site sécurisé. Cette situation compliquait l’administration des infrastructures, augmentait les coûts et accélérait la consommation d’adresses IPv4, déjà limitées. SNI a levé une partie importante de cette contrainte en rendant possible l’hébergement virtuel HTTPS à grande échelle.
Le principe ressemble à celui de l’en-tête Host en HTTP, qui indique au serveur quel site est demandé lorsqu’une même adresse IP sert plusieurs domaines. Mais il existe une différence majeure : l’en-tête Host est envoyé dans la requête HTTP, donc après l’établissement de la connexion TLS en HTTPS. SNI intervient plus tôt, pendant la négociation TLS, au moment où le serveur doit justement choisir le certificat à présenter.
Une connexion HTTPS ne commence pas directement par TLS. Le client doit d’abord résoudre le nom de domaine via le DNS, puis établir une connexion TCP avec le serveur. Ce socle réseau précède la négociation TLS, comme le montre le fonctionnement du handshake TCP avant l’échange TLS, indispensable pour créer un canal de communication fiable.
Une fois cette connexion TCP ouverte, le client envoie un message ClientHello. Ce message contient plusieurs informations : les versions de TLS supportées, les suites cryptographiques proposées, des paramètres de sécurité, et, si le client l’utilise, l’extension SNI. Le serveur lit alors le nom de domaine transmis, choisit le certificat correspondant, puis poursuit la négociation TLS.
Dans la pratique, SNI transporte principalement un nom d’hôte, par exemple www.exemple.fr. Cette valeur correspond au domaine que le client souhaite contacter. Elle ne contient pas une URL complète, ni un chemin comme /contact, ni des paramètres de requête. Le serveur n’a donc pas accès, via SNI, à la page précise que l’utilisateur veut consulter.
L’extension est définie dans les spécifications TLS sous le nom server_name. Le type le plus courant est host_name, conçu pour les noms DNS. Les adresses IP littérales n’ont pas le même usage dans SNI, car le mécanisme vise précisément à distinguer plusieurs noms de domaine susceptibles de partager une même adresse réseau. Le certificat renvoyé devra ensuite correspondre au nom demandé, par exemple via le champ Subject Alternative Name.
Un certificat TLS atteste qu’un serveur est autorisé à représenter un ou plusieurs noms de domaine. Lorsqu’un navigateur reçoit ce certificat, il vérifie notamment sa validité, son autorité de certification, sa date d’expiration et sa correspondance avec le domaine demandé. Si le serveur présente un certificat prévu pour un autre site, le navigateur affiche généralement une alerte de sécurité.
SNI permet donc au serveur ou au répartiteur de charge de sélectionner le bon certificat au bon moment. C’est crucial pour les hébergeurs mutualisés, les CDN, les plateformes SaaS et les architectures cloud. Le même principe de confiance fondé sur le DNS se retrouve dans d’autres mécanismes de sécurité, par exemple lorsqu’un domaine publie une politique DMARC pour protéger ses emails.
Une limite importante de SNI tient à sa visibilité. Dans les versions classiques de TLS, y compris TLS 1.3 sans mécanisme complémentaire, le ClientHello reste envoyé en clair. Cela signifie qu’un observateur situé sur le réseau peut voir le nom de domaine indiqué dans SNI, même s’il ne peut pas lire ensuite le contenu chiffré de la connexion HTTPS.
Cette exposition ne révèle pas l’URL complète, les identifiants, les formulaires ou les données échangées. Elle peut toutefois indiquer qu’un utilisateur contacte un domaine précis. Pour répondre à ce problème, l’IETF a travaillé sur ECH, pour Encrypted ClientHello, qui vise à chiffrer aussi cette partie de la négociation. Son déploiement dépend cependant du support des navigateurs, des serveurs, des fournisseurs DNS et des opérateurs d’infrastructure.
La généralisation de SNI a accompagné l’essor du HTTPS par défaut. Aujourd’hui, un hébergeur peut proposer à des milliers de clients des certificats distincts sans attribuer une adresse IP à chaque site. Les CDN l’utilisent aussi massivement pour servir des contenus depuis des points de présence répartis dans le monde, tout en présentant le certificat adapté au domaine demandé.
SNI intervient avant les politiques applicatives comme HSTS. Une fois la connexion TLS établie et la réponse HTTP reçue, le navigateur peut appliquer des règles de sécurité supplémentaires, notamment celles décrites dans le fonctionnement de l’en-tête HSTS. Les deux mécanismes sont complémentaires : SNI aide à établir la bonne connexion chiffrée, HSTS renforce ensuite l’usage systématique de HTTPS.
Les erreurs liées à SNI se manifestent souvent par un certificat inattendu, une alerte de navigateur ou un échec de négociation TLS. Elles peuvent venir d’un serveur mal configuré, d’un certificat absent, d’un proxy qui ne transmet pas correctement l’extension, ou d’un ancien client ne prenant pas SNI en charge. Ce dernier cas est devenu rare, mais il peut encore exister dans des systèmes embarqués ou de très vieux environnements.
Le diagnostic commence généralement par vérifier le nom demandé, le certificat renvoyé et la configuration du serveur web ou du load balancer. Des outils comme openssl s_client permettent d’indiquer explicitement un nom SNI et d’observer la réponse. À un niveau plus bas, la connectivité peut aussi dépendre de mécanismes réseau fondamentaux ; le rôle d’ICMP dans le diagnostic d’Internet reste utile pour comprendre certains problèmes de routage ou de disponibilité.
SNI illustre parfaitement l’importance des détails techniques dans l’évolution d’Internet. En ajoutant un nom de domaine au début de la négociation TLS, cette extension a rendu possible un usage massif, économique et flexible du HTTPS. Elle a facilité l’hébergement mutualisé sécurisé, simplifié les architectures cloud et contribué à la généralisation du chiffrement sur le web.
Son fonctionnement dépend toutefois d’une chaîne complète : DNS, TCP, TLS, certificats, configuration serveur et horloge système fiable. La validation des certificats repose notamment sur des dates précises, ce qui explique pourquoi la synchronisation horaire avec NTP peut avoir un impact indirect sur les connexions sécurisées. Discret mais essentiel, SNI reste aujourd’hui l’un des mécanismes clés du HTTPS moderne.
