¿Una clave pública o una huella digital de código rígido protegería contra MITM?

Potencialmente sí, sí protege del hombre en los ataques medios, pero hay 2 problemas con él

1. ¿Cómo llevar el software al usuario? Esta conexión también debe ser segura.
2. ¿Qué sucede si se revela la clave privada? No hay forma de revocar el certificado.

HSTS (HTTP Strict Transport Security) funciona al tener las huellas dactilares de los certificados codificadas en los navegadores. Esto supone que la cadena para obtener su navegador era segura o que usaba HSTS (por ejemplo, obtiene un disco de solo lectura de Windows 10 de una fuente confiable que tiene IE11 y Edge que son compatibles con HSTS; los usa para descargar Chrome desde enlace que usa HSTS) Para mitigar 2, agrega dos huellas digitales de certificado, solo use una y luego si ese certificado ya no es seguro, comience a usar la otra y revocar el primero.

¿Por qué esto es potencialmente excesivo? Esto solo agrega protección contra ataques MITM activos, los intercambios de certificados normales funcionan para protegerlo de MITM pasivo. Los ataques MITM activos son muy costosos porque necesita una CA para otorgarle un certificado para un dominio que no tiene (esto debería ser imposible pero ha ocurrido en más de una ocasión) o poner su propio certificado de CA en la PC de la víctima.

El intercambio de claves TLS no permite no detectado MITM

Los protocolos existentes, por ejemplo. HTTPS / TLS no ofrece realmente una oportunidad para MITM, el intercambio de claves es seguro. Las autoridades de firma de certificados pueden verse comprometidas, pero las técnicas existentes, como la fijación de claves, lo impiden, puede pensar en el estándar HPKP como la implementación recomendada de "una clave pública o una huella digital codificada".

Los inconvenientes son simples: primero, si una clave pública en particular está codificada en el cliente, se vuelve muy difícil para el propietario legítimo cambiar su clave pública cuando sea necesario, por ejemplo. rotarlo periódicamente, o revocar una clave comprometida; y segundo, aún necesita obtener la clave inicial de cada servidor al cliente, lo que le permite volver a todos los problemas de distribución / intercambio de claves.

Así es como funcionó en los viejos tiempos de las computadoras:

1. Alicia envía datos NO ENCRITADOS a un servidor, a través de un ROUTER

2. El servidor envía de vuelta a Alicia

Bob puede, si su tarjeta de red es lo suficientemente buena, diga "Ahora soy el enrutador" y lea fácilmente TODOS LOS DATOS que Alicia envía al servidor

Entonces un hombre en el ataque central puede ocurrir fácilmente.

Así es como era antes de que se implementara la seguridad

Así es como está ahora:

1. Alice envía DATOS CIFRADOS a un servidor a través del enrutador
2. El servidor luego descifra los datos, con una clave VERIFICADA, FIRMADA.
3. Los datos encriptados se envían de vuelta a Alice.

Un hombre en el medio ahora es bastante difícil de hacer, pero luego alguien puede establecer esa primera conexión con la autoridad de seguridad y cambiarla por otra.

Todo lo que está haciendo es cambiar la segunda parte a otro paso de verificación. El uso del reconocimiento facial es probablemente la mejor manera de cifrar esos datos.

Puede consultar Seguridad de red de Computerphile si esto no funciona.