Remarque : Vous noterez peut-être que nous employons ici le terme techniquement correct de certificat TLS (Transport Layer Security) au lieu de SSL (Secure Socket Layer). Le TLS, qui a succédé au SSL, constitue de fait le protocole utilisé aujourd’hui. Pour plus d’explications, nous vous invitons à lire notre billet SSL vs TLS — Quelle différence ?
L’Indication de nom de serveur (SNI, Server Name Indication) permet à un serveur d’héberger en toute sécurité plusieurs certificats TLS pour plusieurs sites, le tout sous une seule adresse IP. La SNI ajoute le nom d’hôte du serveur (site Web) dans la procédure de handshake TLS en guise d’extension dans le message CLIENT HELLO. Le serveur sait ainsi quel site Web présenter lorsqu’il utilise des adresses IP partagées. Généralement, les entreprises qui utilisent des adresses IP partagées sur un seul serveur sont des hébergeurs qui se posent au quotidien la question suivante : « Comment faire pour que mon serveur sélectionne le bon certificat à présenter ? »
Arrêtons-nous un instant sur ce point. Sur un site HTTP, un serveur utilise les en-têtes HTTP HOST pour déterminer quel site HTTP il doit présenter. Mais avec le TLS (à savoir le protocole derrière le HTTPS), la session sécurisée doit être créée avant que la session HTTP ne soit établie et jusque-là, aucun en-tête d’hôte n’est disponible.
Le dilemme est le suivant : en HTTPS, la procédure de handshake TLS dans le navigateur ne peut, dans un premier temps, être effectuée sans un certificat TLS, et le serveur ignore quel certificat présenter, car il n’a pas accès à l’en-tête de l’hôte.
Qu’est-ce que la SNI et en quoi peut-elle être utile ?
L’Indication de nom de serveur est une extension du protocole TLS. Le client indique le nom d’hôte auquel il veut se connecter à l’aide de l’extension SNI dans le handshake TLS. Un serveur (Apache, Nginx, ou un répartiteur de charge comme HAProxy) peut ainsi sélectionner la clé privée et la chaîne de certificats idoines qui sont nécessaires pour établir la connexion à partir d’une liste ou d’une base de données, tandis que tous les certificats sont hébergés sur une seule adresse IP.
Avec une SNI, le nom d’hôte du serveur est inclus dans le handshake TLS, ce qui permet aux sites en HTTPS d’avoir des certificats TLS uniques, même sur une adresse IP partagée.
Pourquoi est-ce si important ? Quel intérêt y a-t-il à prendre en charge des certificats uniques pour des IP partagées ?
Pénurie d’adresses IPv4, un véritable dilemme
La version 4 du protocole Internet (IPv4) avait tablé sur près de 4 milliards d’adresses IP disponibles. Mais aujourd’hui, avec plus de 4 milliards d’ordinateurs déjà connectés à Internet dans le monde, nous sommes en situation de pénurie d’adresses IPv4. L’IPv6 devrait résoudre le problème, avec plusieurs trillions d’adresses disponibles, mais certains équipements réseau ne prennent pas encore en charge l’IPv6. On estime que 90 % des principaux systèmes d’exploitation pour mobiles, PC et serveurs prennent en charge l’IPv6. Si l’on s’approche d’une prise en charge totale de l’IPv6, pour les quelques systèmes qui ont encore besoin d’adresses IP partagées, une approche mixte devra parfois être envisagée – SNI pour l’IPv4 dans les quelques navigateurs d’ancienne génération, et IP uniques pour tous les domaines via l’IPv6 pour le reste.
SNI : des atouts face à la pénurie d’adresses IPv4
L’Indication de nom de serveur permet au serveur d’héberger en toute sécurité plusieurs certificats TLS pour plusieurs sites, le tout sous une seule adresse IP.
Le fait d’utiliser moins d’adresses IP permet de renflouer le stock d’adresses IP disponibles. Même si l’issue reste la même — une carence d’adresses IPv4 — ce coup de frein offre un répit salvateur pour se mettre à jour ou migrer vers les versions plus récentes et compatibles des navigateurs, routeurs et serveurs.
La SNI simplifie aussi les choses lorsque l’on doit configurer et gérer plusieurs sites Web, dans la mesure où tous peuvent pointer vers la même adresse IP. Autre avantage : l’analyse d’une adresse IP ne dévoile pas le certificat, ce qui, du point de vue de la sécurité, n’est pas négligeable.
SNI : y a-t-il des inconvénients ?
Si la SNI offre une excellente solution pour les IP partagées, un léger inconvénient subsiste : la technologie ne concerne qu’un très faible pourcentage d’internautes, à savoir les utilisateurs de navigateurs ou de systèmes d’exploitation d’ancienne génération.
Or, la SNI n’est pas prise en charge par ces anciens navigateurs et serveurs Web. Les navigateurs récents (de moins de 6 ans en général) savent tous gérer l’Indication de nom de serveur. Mais deux anciens navigateurs bien connus ont du mal avec la SNI. Il s’agit d’une part d’Internet Explorer sous Windows XP (ou ses versions antérieures, qui auraient encore été utilisées par 3,18 % des internautes en avril 2018) et d’Android. Parmi les utilisateurs d’Android 2.3 et de ses versions antérieures, ce chiffre tombe alors à 0,3 %. Or, si le navigateur ou le système d’exploitation d’ancienne génération ne prend pas en charge la SNI, le handshake choisit le certificat par défaut, avec les risques d’erreur de correspondance des noms communs que cela peut entraîner.
Au vu de la baisse continue du nombre d’utilisateurs de Windows XP et de versions antérieures à Android 2.3, les questions de compatibilité ne seront bientôt plus un problème. N’oublions pas que Windows XP ne prend en charge ni le TLS 1.1 ni le TLS 1.2. et avec les prochaines exigences PCI, les utilisateurs ne pourront, de toute façon, plus consulter beaucoup de sites.
Ces navigateurs délaissés ne sont pas près de voir la tendance s’inverser... Il n’en reste pas moins qu’une partie des internautes continue à rencontrer des difficultés lorsque les pages HTTPS des sites Web lui sont transmises via SNI.
Vous trouverez ici une liste complète des navigateurs et de leurs versions précisant, le cas échéant, leur capacité à prendre en charge, ou pas, la SNI.
L’une des solutions de contournement au problème consiste à utiliser le TLS multidomaine comme certificat par défaut pour pouvoir lister dans un seul certificat tous les domaines sur l’adresse IP partagée (plus d’informations à ce sujet ci-dessous).
Autre point à souligner au sujet de la SNI : lorsque la connexion commence en TLS 1.2, elle n’est pas chiffrée, ce qui expose les clients à la censure et à la surveillance. Le TLS 1.3 apporte une réponse, mais n’est pas encore totalement pris en charge. Tenez-vous prêt à adopter le TLS 1.3 dès que son usage se sera suffisamment répandu.
Toutes ces difficultés n’ôtent rien à ce qui fait l’attrait de la SNI. Nous vous recommandons d’utiliser l’Indication de nom de serveur où vous pouvez.
SNI et SAN : quelles différences ?
Dans un contexte de pénurie d’IPv4, le certificat multidomaine (parfois appelé certificat SAN) constitue une alternative. Contrairement à la SNI, les certificats TLS multidomaines ne sont pas concernés par les questions de compatibilité avec les navigateurs ou les serveurs. Ils fonctionnent comme n’importe quel autre certificat TLS et couvrent jusqu’à 200 domaines sur un seul certificat. En revanche, la SNI peut facilement héberger des millions de domaines sur la même adresse IP.
Pourquoi ne pas simplement utiliser des certificats multidomaines ?
Sur un certificat multidomaines, tous les domaines doivent être ajoutés à un seul certificat. Ces domaines sont répertoriés en tant que noms de domaines supplémentaires ou SAN (Subject Alternative Names). S’il faut ajouter ou supprimer un SAN, ou si un certificat doit être révoqué ou renouvelé, le certificat doit alors être remplacé et redéployé pour tous les domaines. Autre point, les personnes physiques ou morales qui partagent un même certificat sont visibles. Certaines entreprises, dont les certificats proviennent d’un hébergeur qui utilise, par exemple, des certificats multidomaines pour ses clients, risquent de ne pas apprécier le fait que leur certificat soit partagé avec un concurrent.
Sans parler du fait que plus l’on ajoute de noms à un certificat, plus celui-ci grossit et s’alourdit. Même si cela ne représente que quelques kilo-octets, cette information doit être téléchargée avant tout autre téléchargement sur les sites. Ces quelques kilo-octets empêchent donc le site de se charger pendant une ou plusieurs millisecondes en fonction de la connexion Internet. Certes l’impact sur le temps de chargement n’est pas énorme, mais dans un domaine aussi sensible et concurrentiel que le référencement sur Google, quelques millisecondes sur le temps de chargement d’une page peuvent avoir leur importance.
Autre inconvénient de taille : les certificats multidomaines ne peuvent pas prendre en charge les SAN avec validation par l’organisation (OV) ou à validation étendue (EV) lorsqu’ils sont partagés entre plusieurs organisations. Ainsi, dans le scénario précédent de l’hébergeur qui liste les domaines de plusieurs entreprises en tant que SAN sur un seul certificat, il s’agirait d’une validation de niveau DV (validation de domaine). Ces niveaux de validation font référence à la quantité d’informations vérifiées avant l’émission du certificat. Une validation DV signifie que le propriétaire du site est bien celui qui exerce un contrôle administratif sur le domaine, tandis que les validations OV et EV vont un cran plus loin en vérifiant les informations sur l’identité du propriétaire du site (ex. : son existence juridique et opérationnelle).
Parmi les utilisateurs bien connus de certificats multidomaines, on retrouve Cloudflare et Google. Google ne les utilise que pour certains anciens clients qui ne prennent pas en charge la SNI.
Vaut-il mieux que j’utilise la SNI ou les certificats multidomaines ?
Globalement, si la SNI et les certificats multidomaines atteignent le même résultat — à savoir réduire le nombre d’adresses IPv4 nécessaires — ils procèdent de façon radicalement opposée.
La SNI vous permet d’avoir des certificats uniques pour chaque domaine (c’est-à-dire plusieurs certificats) alors que ces domaines partagent la même adresse IP. D’un autre côté, avec les certificats multidomaines, il suffit d’utiliser un certificat pour plusieurs domaines, ce qui en contrepartie se traduit aussi par une adresse IP pour plusieurs domaines.
Il semble désormais évident que SNI et certificats multidomaines ont tous deux leur place — soit seuls, soit combinés. Avec ces solutions, vous pouvez continuer à héberger des certificats pour vos clients sans vous préoccuper des questions d’adresses IP dédiées ou de compatibilité.
Pour discuter avec un conseiller GlobalSign sur les solutions qui vous conviendraient, contactez-nous dès aujourd’hui.
