Comment un serveur Web sait-il quelle paire de clés utiliser pour le déchiffrement SSL?

Je crois comprendre que lorsque Apache recevra une demande sur l'un des ports TCP sur lesquels il écoute (par exemple 80, 443), il décidera quel hôte est demandé en regardant l'en-tête HTTP Host. Le serveur saura alors vers quel hôte virtuel il doit rediriger la demande.

Mais comment ça marche pour HTTP sur SSL / TLS? Étant donné que toute la requête HTTP est cryptée (du moins c'est ce que je crois avoir lu quelque part), les informations d'en-tête ne peuvent être lues qu'après que le serveur a décrypté les données. Mais pour décrypter, il doit savoir quelle paire de clés utiliser car vous pouvez avoir plusieurs certificats SSL installés sur un serveur Web.

Alors, comment le serveur sait-il de quelle clé il a besoin pour le déchiffrement?

Je pourrais imaginer que la prise de contact TLS fournit les informations nécessaires.

Concernant le drapeau "doublon possible" :

Bien que je convienne que les réponses à la fois à la question liée et à la mienne sont similaires, je dois dire que la question est différente. Il n'est pas question de savoir si ou comment l'hébergement de plusieurs sites avec des certificats SSL indépendants est possible. Au lieu de cela, ma question porte sur l'aspect technique sous-jacent.

À l'origine, le serveur Web ne savait pas. C'est la raison pour laquelle vous aviez besoin d'une adresse IP distincte pour chaque vhost SSL que vous vouliez héberger sur le serveur. De cette façon, le serveur savait que lorsqu'une connexion était établie sur IP X, il devait utiliser la configuration (y compris les certificats) pour le vhost associé.

Cela a changé avec Server Name Indication , une extension TLS qui permet en effet à un client d'indiquer le nom d'hôte requis dans le processus de prise de contact. Cette extension est utilisée dans tous les systèmes d'exploitation modernes, mais les anciens navigateurs ou serveurs ne la prennent pas en charge, donc si vous vous attendez à ce que les clients utilisent toujours IE 6 sur WinXP, vous n'auriez pas de chance.

Il semble que vous ayez des idées fausses sur TLS / SSL. La demande HTTP n'est pas chiffrée par la clé publique du serveur. Il est chiffré par un chiffrement symétrique à l'aide d'une clé négociée lors de la négociation précédente.

Brève description de la négociation TLS: le serveur et le client négocient une suite de chiffrement, des clés symétriques et d'autres détails. Afin d'empêcher MITM, le serveur envoie généralement son certificat (chaîne) au client et authentifie la prise de contact à l'aide de la clé dans le certificat. (Il existe également d'autres variantes, par exemple l'authentification client ou TLS-PSK, mais elles ne sont pas très utilisées avec HTTP.) Le client peut soit valider le certificat (de la manière habituelle), soit l'ignorer.

Bien que SNI soit important lors de l'utilisation de plusieurs certificats TLS sur une IP, il n'est pas essentiel que le serveur puisse décrypter la demande. Sans SNI, le serveur ne sait pas quelle chaîne de certificats doit être envoyée, donc le serveur en choisit généralement un (par exemple le premier vhost), qui pourrait bien sûr être un mauvais. Si le serveur choisit une chaîne de certificats incorrecte, le client doit la refuser (afin qu'il ne poursuive pas l'envoi de la requête HTTP). Cependant, si le client ignore le certificat (ou si le certificat non valide est marqué comme approuvé pour ce site), il peut continuer avec succès. Étant donné que la clé symétrique utilisée pour le chiffrement ne dépend pas du certificat (TLS est conçu pour fonctionner également sans certificats), le serveur peut le déchiffrer.

Juste une petite note pourquoi j'écris sur TLS, alors que vous avez posé une question sur SSL: TLS est une nouvelle version de SSL. Toutes les versions de SSL sont considérées comme non sécurisées pour une utilisation générale, nous utilisons donc principalement TLS (1.0, 1.1, 1.2) maintenant.