Oui, mais il y a quelques réserves.

Cela est accompli grâce à l'indication du nom du serveur, une extension à la sécurité de la couche de transport.

Qu'est-ce que l'indication du nom du serveur ?

Indication de nom de serveur (RFC 6066 ; obsolète RFC 4366 , RFC 3546) est une extension de la sécurité de la couche de transport qui permet au client de dire au serveur le nom de l'hôte qu'il essaie d'atteindre.

L'ISN est compatible avec TLS 1.0 et supérieur selon la spécification, mais les implémentations peuvent varier (voir ci-dessous). Il ne peut pas être utilisé avec SSL, donc une connexion doit négocier TLS (voir RFC 4346 annexe E) pour que l'ISN soit utilisé. Cela se fait généralement automatiquement avec les logiciels pris en charge.

Pourquoi l'ISN est-il nécessaire ?

Dans une connexion HTTP normale, le navigateur informe le serveur du nom d'hôte du serveur qu'il essaie d'atteindre en utilisant l'en-tête Host:. Cela permet à un serveur Web sur une seule adresse IP de servir du contenu pour plusieurs noms d'hôte, ce qui est communément appelé l'hébergement virtuel basé sur le nom.

L'alternative consiste à attribuer des adresses IP uniques à chaque nom d'hôte Web à servir. Cela était couramment pratiqué au tout début du Web, avant qu'il ne soit largement connu que les adresses IP seraient épuisées et que des mesures de conservation aient commencé, et se fait toujours ainsi pour les hôtes virtuels SSL (sans utiliser l'ISN).

Parce que cette méthode de transmettre le nom d'hôte nécessite que la connexion soit déjà établie, elle ne fonctionne pas avec les connexions SSL/TLS. Au moment où la connexion sécurisée est établie, le serveur Web doit déjà savoir quel nom d'hôte il va servir au client, car le serveur Web lui-même met en place la connexion sécurisée.

L'ISN résout ce problème en permettant au client de transmettre le nom d'hôte dans le cadre de la négociation TLS, de sorte que le serveur soit déjà conscient de quel hôte virtuel doit être utilisé pour répondre à la connexion. Le serveur peut alors utiliser le certificat et la configuration du bon hôte virtuel.

Pourquoi ne pas utiliser des adresses IP différentes ?

L'en-tête HTTP Host: a été défini pour permettre à plus d'un hôte Web d'être servi à partir d'une seule adresse IP en raison de la pénurie d'adresses IPv4, reconnue comme un problème dès le milieu des années 1990. Dans les environnements d'hébergement Web partagés, des centaines de sites We

......

(Note : Certaines informations pour cette réponse ont été obtenues sur Wikipédia.)

Le problème :

Lorsqu'un client web et un serveur web communiquent entre eux via HTTPS, la première chose qui doit se produire est l'authentification sécurisée.

Voici un exemple simplifié d'une telle authentification :

S'il s'agissait de HTTP et non pas de HTTPS, la première chose que le client aurait envoyée aurait été quelque chose comme ceci :

GET /index.html HTTP/1.1
Host: example.com

Cela a permis aux hôtes virtuels multiples sur une seule adresse IP, car le serveur sait exactement quel domaine le client souhaite accéder, à savoir example.com.

HTTPS est différent. Comme je l'ai mentionné précédemment, l'authentification se produit avant tout le reste. Si vous regardez la troisième étape de l'authentification illustrée ci-dessus (Certificat), le serveur doit présenter un certificat au client dans le cadre de l'authentification, mais n'a aucune idée du nom de domaine auquel le client essaie d'accéder. La seule option dont dispose le serveur est d'envoyer le même certificat à chaque fois, son certificat par défaut.

Vous pouvez toujours configurer des hôtes virtuels sur votre serveur web, mais le serveur enverrait toujours le même certificat à chaque client. Si vous essayiez d'héberger à la fois les sites example.com et example.org sur votre serveur, le serveur enverrait toujours le certificat pour example.com lorsque qu'un client demande une connexion HTTPS. Donc, lorsque qu'un client demande example.org sur une connexion HTTPS établie, cela arriverait :

Ce problème limite efficacement le nombre de domaines que vous pouvez héberger via HTTPS à un par adresse IP.

La solution :

La manière la plus simple de résoudre ce problème est pour le client d'indiquer au serveur quel domaine il souhaite accéder pendant l'authentification. De cette façon, le serveur peut fournir le certificat correct.

C'est exactement ce que SNI, ou Server Name Indication fait.

Avec SNI, le client envoie le nom de serveur qu'il veut accéder dans le premier message, l'étape "Client Hello" dans le diagramme d'authentification ci-dessus.

Certains anciens navigateurs web ne supportent pas SNI. Par exemple, sur Windows XP, il n'existe pas une seule version d'Internet Explorer qui prend en charge SNI. Lors de l'accès à une ressource via HTTPS sur un serveur qui utilise des hôtes virtuels SNI, vous verrez un certificat générique, ce qui peut entraîner l'affichage d'un avertissement ou d'une erreur par le navigateur.

J'ai simplifié les choses ici pour expliquer simplement le principe du problème et de la solution. Si vous souhaitez une explication plus technique, la page wikipedia ou RFC 6066 pourraient être de bons points de départ. Vous pouvez également trouver une liste à jour des serveurs et navigateurs prenant en charge SNI sur wikipedia

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Le navigateur client doit également prendre en charge SNI. Voici quelques navigateurs qui le font:

* Mozilla Firefox 2.0 ou ultérieur
* Opera 8.0 ou ultérieur (avec TLS 1.1 activé)
* Internet Explorer 7.0 ou ultérieur (sur Vista, pas sur XP)
* Google Chrome
* Safari 3.2.1 sur Mac OS X 10.5.6

L'extension TLS Server Name Indication (RFC6066) est requise pour que les hôtes virtuels basés sur des noms fonctionnent via HTTPS.

L'extension est largement mise en œuvre et je n'ai pas encore rencontré de problèmes avec les logiciels actuels, mais il existe une possibilité que certains clients (ceux ne la prenant pas en charge) soient dirigés vers votre site par défaut si vous dépendez du SNI.