Plusieurs domaines SSL sur la même adresse IP et le même port?


109

C’est une question canonique sur l’hébergement de plusieurs sites Web SSL sur la même adresse IP.

J'avais l'impression que chaque certificat SSL nécessitait sa propre combinaison unique adresse IP / port. Mais la réponse à une question précédente que j’ai posée va à l’encontre de cette affirmation.

En utilisant les informations de cette question, j’ai pu faire fonctionner plusieurs certificats SSL sur la même adresse IP et sur le port 443. Je suis très confus quant à la raison pour laquelle cela fonctionne compte tenu de la supposition ci-dessus et renforcé par d’autres que chaque site Web de domaine SSL sur le le même serveur nécessite son propre IP / Port.

Je soupçonne que j'ai fait quelque chose de mal. Peut-on utiliser plusieurs certificats SSL de cette façon?


Ce corps Q dit plusieurs certificats et les réponses sont correctes pour cela. Mais le titre indique plusieurs domaines et vous pouvez avoir plusieurs domaines avec un seul certificat (et aucun SNI), voir serverfault.com/questions/126072/… et serverfault.com/questions/279722/… également sur security.SX.
dave_thompson_085

Réponses:


68

Pour obtenir les informations les plus récentes sur Apache et SNI, y compris des RFC spécifiques à HTTP, consultez le wiki d'Apache.


FYsI: "Plusieurs certificats SSL (différents) sur une IP" vous est présenté par la magie de la mise à niveau TLS. Cela fonctionne avec les nouveaux serveurs Apache (2.2.x) et les navigateurs raisonnablement récents (je ne connais pas les versions par cœur).

La RFC 2817 (mise à niveau vers TLS dans HTTP / 1.1) contient les détails sanglants, mais elle fonctionne pour beaucoup de personnes (si ce n’est la majorité).
Vous pouvez cependant reproduire l'ancien comportement funky à l'aide de la s_clientcommande openssl (ou de tout navigateur "assez ancien").

Modifier pour ajouter: apparemment, curlpeut vous montrer ce qui se passe ici mieux que openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

2
C'est très utile - Merci! Des informations sur la façon de configurer Apache pour TLS au lieu de SSL?
Josh

2
Je pense qu’Apache 2.2 doit simplement activer les bits TLS dans sa liste de chiffrement. J'admets que je n'ai jamais vu l'intégralité du bit "Mise à niveau de SSL vers TLS" avant ces deux sites. D'après ce que je comprends de la documentation TLS, la négociation de ce type de mise à niveau est une situation acceptable (mais inhabituelle) ...
voretaq7

C'est la première fois que je vois ça et j'essaie toujours de me tirer la mâchoire ...
Josh

1
OK, ma réponse vient de tripler de longueur - Apparemment, curl peut faire les négociations SSLv3 et TLSv1 afin que je puisse montrer l'échec et le succès. J'aimerais avoir un débogueur de protocole à portée de main pour montrer la partie magique cependant. (Également testé et heureux de signaler que le serveur de johnlai2004 nie correctement les connexions SSLv2 :-)
voretaq7

C'est extrêmement utile et j'espère que johnlai2004 accepte votre réponse. Merci beaucoup!
Josh

97

Oui, mais il y a des mises en garde.

Ceci est accompli par l’intermédiaire de l’indication du nom du serveur, une extension de Transport Layer Security.

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

Indication du nom du serveur ( RFC 6066 ; RFC 4366 , RFC 3546 obsolète ) est une extension de Transport Layer Security qui permet au client d'indiquer au serveur le nom de l'hôte qu'il tente d'atteindre.

SNI est compatible avec TLS 1.0 et supérieur selon les spécifications, mais les implémentations peuvent varier (voir ci-dessous). Il ne peut pas être utilisé avec SSL. Par conséquent, une connexion doit négocier le protocole TLS (voir l’ annexe E du RFC 4346 ) pour que le SNI soit utilisé. Cela se produit généralement automatiquement avec les logiciels pris en charge.

Pourquoi le SNI est-il nécessaire?

Dans une connexion HTTP normale , le navigateur informe le serveur du nom d'hôte du serveur auquel il tente de parvenir à l'aide de l'en- Host:tête. Cela permet à un serveur Web sur une seule adresse IP de servir du contenu pour plusieurs noms d'hôte, généralement appelé hébergement virtuel basé sur un nom .

L'alternative consiste à attribuer des adresses IP uniques à chaque nom d'hôte Web à desservir. Cela se faisait généralement au tout début du Web, avant que l’on sache généralement que les adresses IP s’épuiseraient et que les mesures de conservation seraient mises en place. C’est toujours le cas pour les hôtes virtuels SSL (n’utilisant pas SNI).

Comme cette méthode de transmission du nom d'hôte nécessite que la connexion soit déjà établie, elle ne fonctionne pas avec les connexions SSL / TLS. Au moment de la configuration de la connexion sécurisée, le serveur Web doit déjà savoir quel nom d’hôte il servira au client, car le serveur Web lui-même est en train de configurer la connexion sécurisée.

SNI résout ce problème en demandant au client de transmettre le nom d'hôte dans le cadre de la négociation TLS, de sorte que le serveur sache déjà quel hôte virtuel doit être utilisé pour desservir la connexion. Le serveur peut ensuite utiliser le certificat et la configuration pour le bon hôte virtuel.

Pourquoi ne pas utiliser différentes adresses IP?

L'en- Host:tête HTTP a été défini pour permettre à plusieurs hôtes Web d'être desservis à 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 90. Dans les environnements d'hébergement Web partagés, des centaines de sites Web uniques et non liés peuvent être servis à l'aide d'une seule adresse IP de cette manière, en économisant l'espace d'adressage.

Les environnements d'hébergement partagé ont alors découvert que le plus gros consommateur d'espace d'adressage IP était la nécessité pour les sites Web sécurisés de disposer d'adresses IP uniques, d'où la nécessité de SNI en tant que mesure décisive sur la voie du protocole IPv6. Aujourd'hui, il est parfois difficile d'obtenir aussi peu que 5 adresses IP (/ 29) sans justification significative, ce qui entraîne souvent des retards de déploiement.

Avec l'avènement de l'IPv6, de telles techniques de conservation des adresses ne sont plus nécessaires, puisqu'un seul hôte peut se voir attribuer plus d'adresses IPv6 que tout l'Internet actuel, mais ces techniques seront probablement encore utilisées dans le futur pour la maintenance des anciens services IPv4. les liaisons.

Mises en garde

Certaines combinaisons système d'exploitation / navigateur ne supportant pas SNI (voir ci-dessous), l'utilisation de SNI ne convient donc pas à toutes les situations. Les sites ciblant de telles combinaisons système / navigateur devraient renoncer à SNI et continuer à utiliser des adresses IP uniques pour chaque hôte virtuel.

Il convient de noter qu'aucune version d'Internet Explorer sur Windows XP ne prend en charge SNI. Comme cette combinaison représente toujours une portion significative (mais en diminution constante: environ 16% du trafic Internet en décembre 2012 selon NetMarketShare), le SNI serait inapproprié pour un site ciblant ces populations d'utilisateurs.

Soutien

De nombreux progiciels couramment utilisés prennent en charge SNI.

(Omission de cette liste ne signifie pas nécessairement un manque de support; cela signifie qu'il y avait une limite à la quantité que je pouvais taper, ou je ne pouvais pas trouver rapidement les informations dans une recherche. Si votre progiciel n'est pas répertorié, la recherche pour son nom, plus snidevrait révéler si le support existe et comment le configurer.)

Soutien de la bibliothèque

La plupart des packages dépendent d'une bibliothèque externe pour assurer la prise en charge de SSL / TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 ou supérieur, uniquement en tant que client
  • libcurl 7.18.1 ou supérieur
  • NSS 3.1.1 ou supérieur
  • OpenSSL 0.9.8j ou supérieur
    • OpenSSL 0.9.8f ou supérieur, avec les drapeaux configure
  • Qt 4.8 ou supérieur

Support serveur

La plupart des versions actuelles des logiciels de serveur courants prennent en charge SNI. Les instructions d'installation sont disponibles pour la plupart d'entre elles:

Support client

La plupart des navigateurs Web et des agents utilisateurs de ligne de commande actuels prennent en charge SNI.

Bureau

  • Chrome 5 ou supérieur
    • Chrome 6 ou supérieur sur Windows XP
  • Firefox 2 ou supérieur
  • Internet Explorer 7 ou supérieur, fonctionnant sous Windows Vista / Server 2008 ou supérieur
    • Internet Explorer sous Windows XP ne prend pas en charge SNI, quelle que soit la version d'IE
  • Konqueror 4.7 ou supérieur
  • Opera 8 ou supérieur (peut nécessiter que TLS 1.1 soit activé pour fonctionner)
  • Safari 3.0 sur Windows Vista / Server 2008 ou version ultérieure ou Mac OS X 10.5.6 ou version ultérieure

Mobile

  • Navigateur Android sur 3.0 Honeycomb ou supérieur
  • iOS Safari sur iOS 4 ou supérieur
  • Windows Phone 7 ou supérieur

Ligne de commande

  • curl 7.18.1 ou supérieur
  • wget 1.14 ou supérieur (les distributions peuvent avoir rétroporté un correctif pour le support SNI)

Pas de support

  • Navigateur BlackBerry
  • Internet Explorer (toute version) sur Windows XP

(Remarque: certaines informations pour cette réponse ont été obtenues à partir de Wikipedia .)


1
Bien mieux :-) J'espère que cela finira par donner un score plus élevé que celui actuellement accepté, qui, hormis le dernier montage en haut, est malheureusement généralement erroné.
Bruno

1
@Bruno Je ne me plaindrai certainement pas si vous trouvez quelques centaines de personnes pour le faire passer au vote. :)
Michael Hampton

La dernière version de BlackBerry Browser (10?) Utilise une version récente de WebKit. Il est donc très probable qu’elle prenne en charge SNI maintenant.
dave1010

37

Le problème:

Lorsqu'un client Web et un serveur Web se parlent via HTTPS, la première chose à faire est la négociation sécurisée.

Voici un exemple simplifié d'une telle poignée de main:

tls poignée de main

S'il s'agissait de HTTP et non 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 rendu possible plusieurs hôtes virtuels sur une seule adresse IP, car le serveur sait exactement à quel domaine le client veut accéder, à savoir exemple.com.

HTTPS est différent. Comme je l'ai dit plus tôt, la poignée de main vient avant tout le reste. Si vous examinez la troisième étape de la négociation illustrée ci-dessus (Certificat), le serveur doit présenter un certificat au client dans le cadre de la négociation, mais n'a aucune idée du nom de domaine auquel le client tente 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 enverra toujours le même certificat à chaque client. Si vous tentez d'héberger les sites Web exemple.com et exemple.org sur votre serveur, celui-ci enverra toujours le certificat à exemple.com lorsqu'un client demande une connexion HTTPS. Ainsi, lorsqu'un client demande example.org via une connexion HTTPS établie, ceci se produit:

entrez la description de l'image ici

Ce problème limite effectivement le nombre de domaines que vous pouvez serveur via HTTPS à un par adresse IP.

La solution:

Le moyen le plus simple de résoudre ce problème consiste pour le client à indiquer au serveur le domaine auquel il souhaite accéder au cours de la négociation . De cette façon, le serveur peut servir le bon certificat.

C’est exactement ce que fait SNI ou Indication du nom du serveur.

Avec SNI, le client envoie le nom du serveur auquel il souhaite accéder dans le cadre du premier message, l’étape "Client Hello" dans le schéma de négociation ci-dessus.

Certains navigateurs Web plus anciens ne prennent pas en charge SNI. Par exemple, sous Windows XP, aucune version d'Internet Explorer ne prend en charge SNI. Lors de l'accès à une ressource via HTTPS sur un serveur utilisant des hôtes virtuels SNI, un certificat générique vous sera présenté, ce qui peut amener le navigateur à afficher un avertissement ou une erreur.

entrez la description de l'image ici

J'ai simplifié les choses ici pour expliquer le principe du problème et de sa solution. Si vous souhaitez une explication plus technique, la page wikipedia ou RFC 6066 peut constituer un bon point de départ. Vous pouvez également trouver une liste actualisée des serveurs et navigateurs prenant en charge SNI sur wikipedia.


16

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

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

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

6

L'extension TLS d'indication de nom de serveur (RFC6066) est requise pour que les hôtes virtuels basés sur des noms fonctionnent sur HTTPS.

L'extension est largement mis en œuvre et je dois encore rencontrer des problèmes avec les logiciels actuels, mais il y a une chance que certains clients (ceux qui ne le supporte pas) seront acheminés vers votre site par défaut si vous dépendez SNI.


En plus de la réponse de Falcon, IIS requiert également certaines modifications spéciales pour que plusieurs sites IIS puissent fonctionner sur la même adresse IP. Vous devez modifier manuellement le fichier de configuration du serveur ou utiliser un outil CLI pour apporter les modifications de liaison, mais l'interface graphique ne peut pas le faire. Dans IIS, il est fait référence à l'attribution de certificats SSL aux en-têtes d'hôte. Apache n'a pas eu le problème depuis un moment.
Brent Pabst

Ah ok, ça éclaircit certains. Comment savoir si un client (navigateur) supporte cela? Par exemple, si je veux vérifier MSIE6, comment puis-je tester cela sans avoir à installer une machine XP virtuelle ou autre?
Luc


1
@ Falcon SNI ne fonctionne pas avec IE sur XP; qui représente encore près du quart des utilisateurs d’Internet de bureau. Je n'appellerais pas cela "largement mis en œuvre" lorsqu'un quart des visiteurs potentiels ne travaillent pas.
Chris S

1
@MichaelHampton IE utilise la pile de cryptage Windows native pour SSL. XP ne prend pas en charge SNI, donc aucune version d’IE fonctionnant sous XP ne le fait également. IE ne prend en charge que SNI dans Vista et les systèmes d'exploitation plus récents.
Chris S
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.