¿Cómo protege esto exactamente contra un enrutamiento de DNS malicioso?
En absoluto.
Si un tipo malvado tiene un certificado válido (por ejemplo, de un hacking de una CA) y luego se las arregla para que usted se convierta en usted, entonces su conexión es hackeada.
Estaba esperando una respuesta de desafío usando la clave pública del servidor, pero no puedo encontrarla.
Para hacer esto, primero deberías saber algunas cosas sobre el servidor. Y usualmente no tienes esa información. Pero la fijación de certificados es una forma de comunicar esa información:
Ayuda para la fijación de certificados
La fijación de certificados le permite dar a un cliente información adicional sobre sus certificados. Tales como: "Para mis certificados, solo se aceptan firmas de ACME-CA". O "Para mis certificados, solo acéptelos si contienen las siguientes claves públicas ...".
Otras lecturas para la fijación: Wikipedia: Fijación de clave pública HTTP
EDITAR: ¿Cómo se autentican los intercambios de claves?
De la sección de comentarios:
Estoy preguntando exactamente cómo el servidor demuestra que tiene la parte privada. Debe ser un desafío / respuesta iniciado por el cliente utilizando la clave pública del servidor (o utilizando la clave simétrica una vez que se establece). No puedo encontrar esto en los textos
De hecho, hay desafío / respuesta aquí.
Esto se detalla en una subsección del RFC TLS 1.2.
Hay tres opciones:
-
F.1.1.1. Intercambio de claves anónimas
No hay autenticación en absoluto.
-
F.1.1.2. RSA Key Exchange and Authentication
El cliente encripta (parte de) la clave de la sesión de encriptación masiva con la clave pública del servidor. La capacidad del servidor para descifrar es una prueba de posesión de la clave privada.
No "Reenviar secreto":
Si la clave privada del servidor NUNCA se expone, incluso años después, todas las claves de sesión antiguas se pueden descifrar retroactivamente.
-
F.1.1.3. Intercambio de claves Diffie-Hellman con autenticación
El cliente y el servidor utilizan un protocolo de acuerdo de clave diferente. El servidor luego firma la transcripción de las negociaciones con su clave privada. Si el cliente puede verificar esta firma con la clave pública del servidor, eso prueba que el servidor realmente conoce la clave privada.
Tiene "Secreto de reenvío":
La ventaja de este procedimiento es la "confidencialidad hacia adelante". Si la clave privada del servidor se expone años más tarde, las claves de sesión NO se pueden descifrar retroactivamente. (Porque, bueno, nunca se cifraron con la clave privada del servidor. Consulte clave Diffie-Hellman intercambio para más detalles.)