A continuación se muestra una captura de pantalla del artículo "Prudent Engineering Practice for Cryptographic Protocols" de Martin Abadi y Roger Needham. No puedo ver qué está mal con el protocolo y qué logra la solución. ¿Ayuda por favor? Me está volviendo loco.
Deje que C sea el atacante. C ejecuta otro servidor, con su propio nombre ( C ), con su propia clave pública Kc . De vez en cuando, A se conecta a C (a sabiendas, pero sin saber que C es el mal, o creer que la maldad de C no se extenderá más allá de C en sí). El ataque va así:
Y, ¡voilá! C ha ejecutado exitosamente el protocolo con B , enviando un certificado y firma adecuados desde A , calculados sobre el valor de desafío que B enviado a C . Por lo tanto, C se autentica como A con respecto al servidor B . El A genuino no se dio cuenta de nada y no sabe que se hizo algo relacionado con el servidor B en absoluto.
La corrección descrita en el artículo soluciona el problema, que es que en el protocolo original, la firma de A es recargable: en el ataque, A firma un desafío recibido del servidor C , pero la firma también funciona como una respuesta para el mismo desafío del servidor B . Incluir el nombre de B en lo que está firmado evita la manipulación: ahora, una respuesta a un desafío de un servidor dado no puede usarse como respuesta al mismo desafío de otro servidor distinto.
Hay otros ataques similares que también obligan a incluir el nombre de A en lo que está firmado. En SSL / TLS como está definido actualmente, la firma del cliente (en el mensaje ClientKeyExchange ) se calcula sobre un hash de todos los mensajes de intercambio anteriores (enviados y recibidos), que incluye los nombres del cliente y del servidor (como parte de sus respectivos mensajes Certificate ).
Lea otras preguntas en las etiquetas authentication tls client