Como um servidor da Web sabe qual par de chaves usar para descriptografia SSL?

Entendo que, quando o Apache recebe uma solicitação para uma das portas TCP em que está ouvindo (por exemplo, 80, 443), ele decide qual host está sendo solicitado olhando o cabeçalho HTTP Host. O servidor saberá para qual host virtual ele deve redirecionar a solicitação.

Mas como funciona para HTTP sobre SSL / TLS? Como toda a solicitação HTTP está sendo criptografada (pelo menos é o que acredito ter lido em algum lugar), as informações do cabeçalho só podem ser lidas após o servidor descriptografar os dados. Mas, para descriptografar, ele precisa saber qual par de chaves usar, pois você pode ter vários certificados SSL instalados em um servidor da web.

Então, como o servidor sabe qual chave precisa para descriptografar?

Eu poderia imaginar que o handshake TLS fornece as informações necessárias.

Em relação ao sinalizador "possível duplicado" :

Embora eu concorde que as respostas para a pergunta vinculada e a minha são semelhantes, devo dizer que a pergunta é diferente. Está em dúvida se é possível ou não a hospedagem de vários sites com certificados SSL independentes. Em vez disso, minha pergunta aborda o aspecto técnico subjacente.

Originalmente, o servidor web não sabia. Esse foi o motivo pelo qual você precisava de um endereço IP separado para cada vhost SSL que desejasse hospedar no servidor. Dessa forma, o servidor sabia que quando uma conexão chegava no IP X, ele precisava usar a configuração (incluindo certificados) para o vhost associado.

Isso mudou com a Indicação do nome do servidor , uma extensão TLS que realmente permite que um cliente indique o nome do host necessário no processo de handshake. Essa extensão é usada em todos os sistemas operacionais modernos, mas navegadores ou servidores antigos não a suportam; portanto, se você espera que os clientes ainda usem o IE 6 no WinXP, não terá sorte.

Parece que você tem alguns conceitos errados sobre TLS / SSL. A solicitação HTTP não é criptografada pela chave pública do servidor. Ele é criptografado por uma cifra simétrica usando uma chave negociada no handshake anterior.

Breve descrição do handshake TLS: Servidor e cliente negociam alguns códigos cifras, chaves simétricas e alguns outros detalhes. Para impedir o MITM, o servidor geralmente envia seu certificado (cadeia) para o cliente e autentica o handshake usando a chave no certificado. (Também existem outras variantes, por exemplo, autenticação de cliente ou TLS-PSK, mas elas não são muito usadas com HTTP.) O cliente pode validar o certificado (da maneira usual) ou ignorá-lo.

Embora o SNI seja importante ao usar vários certificados TLS em um IP, não é essencial que o servidor possa descriptografar a solicitação. Sem o SNI, o servidor não sabe qual cadeia de certificados deve ser enviada; portanto, o servidor geralmente escolhe uma (por exemplo, o primeiro vhost), que poderia, obviamente, ser uma incorreta. Se o servidor escolher uma cadeia de certificados incorreta, o cliente deve recusá-la (para que não continue enviando a solicitação HTTP). No entanto, se o cliente ignorar o certificado (ou se o certificado inválido estiver marcado como confiável para este site), ele poderá continuar com êxito. Como a chave simétrica usada para criptografia não depende do certificado (o TLS foi projetado para funcionar também sem certificados), o servidor pode descriptografá-lo.

Apenas uma pequena observação do motivo pelo qual estou escrevendo sobre TLS, enquanto você pergunta sobre SSL: TLS é uma nova versão do SSL. Todas as versões do SSL são consideradas inseguras para uso geral, por isso estamos usando TLS (1.0, 1.1, 1.2) agora.