Como um servidor da Web sabe qual par de chaves deve ser usado para descriptografia SSL?

Question

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

Mas como funciona para HTTP em 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 depois que o servidor tiver descriptografado os dados. Mas para descriptografar, é necessário saber qual par de chaves usar, já que você pode ter vários certificados SSL instalados em um servidor da Web.

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

Meu palpite :

Eu posso imaginar que o handshake TLS forneça as informações necessárias.

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

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

    

Answer 1

Originalmente, o servidor da web não sabia. Essa foi a razão pela qual você precisava de um endereço IP separado para cada vhost SSL que você queria 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 Indicação do nome do servidor , uma extensão do TLS que realmente permite que um cliente indique o nome do host necessário no handshaking processo. 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, você estará sem sorte.

    

Answer 2

Parece que você tem alguns equívocos sobre o 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 aperto de mão anterior.

Breve descrição do handshake TLS: O servidor e o cliente negociam algumas chaves simétricas do ciphersuite e alguns outros detalhes. Para evitar o MITM, o servidor geralmente envia seu certificado (cadeia) para o cliente e autentica o handshake usando a chave no certificado. (Há também algumas 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 um (por exemplo, o primeiro vhost), que pode ser obviamente um errado. Se o servidor selecionar cadeia de certificados incorreta, o cliente deverá 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 nota por que estou escrevendo sobre o TLS, enquanto você perguntava sobre o SSL: o TLS é a nova versão do SSL. Todas as versões do SSL são consideradas inseguras para uso geral, portanto estamos usando principalmente o TLS (1.0, 1.1, 1.2) agora.