¿Cómo sabe un servidor web qué par de claves usar para el descifrado SSL?

Tengo entendido que cuando Apache recibe una solicitud a uno de los puertos TCP en los que está escuchando (por ejemplo, 80, 443), decidirá qué host se solicita al mirar el encabezado HTTP Host. El servidor sabrá a qué host virtual debe redirigir la solicitud.

Pero, ¿cómo funciona para HTTP sobre SSL / TLS? Como toda la solicitud HTTP está encriptada (al menos eso es lo que creo que he leído en alguna parte), la información del encabezado solo puede leerse después de que el servidor haya desencriptado los datos. Pero para descifrar, necesita saber qué par de claves usar, ya que puede tener múltiples certificados SSL instalados en un servidor web.

Entonces, ¿cómo sabe el servidor qué clave necesita para descifrar?

Me imagino que el apretón de manos TLS proporciona la información necesaria.

En cuanto a la bandera "posible duplicado" :

Si bien estoy de acuerdo en que las respuestas tanto a la pregunta vinculada como a la mía son similares, debo decir que la pregunta es diferente. Es incuestionable si es posible o no alojar múltiples sitios con certificados SSL independientes. En cambio, mi pregunta aborda el aspecto técnico subyacente.

Originalmente, el servidor web no lo sabía. Esta fue la razón por la que necesitaba una dirección IP separada para cada host SSL que deseaba alojar en el servidor. De esta manera, el servidor sabía que cuando entraba una conexión en IP X, tenía que usar la configuración (incluidos los certificados) para el vhost asociado.

Esto cambió con Server Name Indication , una extensión TLS que de hecho permite que un cliente indique el nombre de host requerido en el proceso de establecimiento de comunicación. Esta extensión se usa en todos los sistemas operativos modernos, pero los navegadores o servidores antiguos no la admiten, por lo que si espera que los clientes sigan usando IE 6 en WinXP, no tendrá suerte.

Parece que tiene algunas ideas falsas sobre TLS / SSL. La solicitud HTTP no está encriptada por la clave pública del servidor. Está cifrado por un cifrado simétrico utilizando una clave negociada en un apretón de manos anterior.

Breve descripción del protocolo de enlace TLS: el servidor y el cliente negocian algunos cifrados, claves simétricas y otros detalles. Para evitar MITM, el servidor generalmente envía su certificado (cadena) al cliente y autentica el protocolo de enlace utilizando la clave del certificado. (También hay algunas otras variantes, por ejemplo, autenticación de cliente o TLS-PSK, pero no se usan mucho con HTTP). El cliente puede validar el certificado (de la forma habitual) o ignorarlo.

Si bien SNI es importante cuando se utilizan múltiples certificados TLS en una IP, no es esencial que el servidor pueda descifrar la solicitud. Sin SNI, el servidor no sabe qué cadena de certificados debe enviarse, por lo que el servidor generalmente elige uno (por ejemplo, el primer vhost), que podría ser, por supuesto, uno incorrecto. Si el servidor elige una cadena de certificados incorrecta, el cliente debe rechazarla (para que no continúe enviando la solicitud HTTP). Sin embargo, si el cliente ignora el certificado (o si el certificado no válido está marcado como confiable para este sitio), puede continuar con éxito. Dado que la clave simétrica utilizada para el cifrado no depende del certificado (TLS está diseñado para funcionar también sin certificados), el servidor puede descifrarlo.

Solo una pequeña nota de por qué escribo sobre TLS, mientras preguntaba sobre SSL: TLS es una nueva versión de SSL. Todas las versiones de SSL se consideran inseguras para uso general, por lo que ahora usamos principalmente TLS (1.0, 1.1, 1.2).