¿Por qué TLS no firma ciphersuite?

1

TLS negocia una versión de Ciphersuite y TLS para usar durante el protocolo de enlace. Confirma que el apretón de manos no fue manipulado y que la versión del conjunto de cifrado y TLS no se degradó utilizando los cifrados negociados, como se explica aquí . Sin embargo, esta verificación se basa en los cifrados negociados en el apretón de manos, por lo tanto, si los cifrados que el atacante eligió fueron lo suficientemente débiles para romperse rápidamente, también podrá enviar estos mensajes de confirmación.

Mi pregunta es, ¿por qué el servidor no usa su clave privada para firmar su versión de Ciphersuite y TLS (y la marca de tiempo de validUntil) para que el cliente pueda detectar los ataques de downgrade? Si bien el cliente no tiene la clave pública en ese momento, el cliente puede conservar la firma hasta que el certificado se valide y luego se verifique. ¿Por qué no lo hace el protocolo TLS?

    
pregunta Peter Harmann 27.04.2018 - 13:53
fuente

1 respuesta

2

El servidor firma el conjunto de cifrado. Se firma toda la negociación del protocolo (que abarca el conjunto de claves, las claves, etc.). Eso es lo último en el saludo: el mensaje Finished . Consulte ¿Qué ¿Evita que un atacante manipule los datos enviados durante el protocolo SSL / TLS? y ¿Cómo funciona SSL / TLS? para más detalles.

Usted nota:

  

esta verificación se basa en los cifrados negociados en el apretón de manos, por lo tanto, si los cifrados que el atacante eligió fueron lo suficientemente débiles para romperse rápidamente, también puede enviar estos mensajes de confirmación.

y pregunta:

  

¿por qué el servidor no utiliza su clave privada para firmar su versión de Ciphersuite y TLS (y la marca de tiempo de validUntil) para que el cliente pueda detectar ataques de baja calificación?

Una vez más, el servidor hace utiliza su clave privada para firmar el conjunto de cifrado y el cliente lo verifica. Sucede al final del protocolo de enlace porque no puede suceder hasta que el cliente y el servidor hayan acordado cuál es la clave del servidor y por qué debe ser confiable.

Le preocupa que un atacante convenza al cliente de usar un conjunto de cifrado débil para el cual pueden falsificar una firma. Bueno, hay dos casos.

  • El cliente sabe que el conjunto de cifrado es débil y se niega a usarlo. Entonces no hay problema. El cliente cerrará la conexión.
  • El cliente no sabe que el conjunto de cifrado es débil. Entonces no hay nada que hacer. Toda la conversación pasa con el atacante. El servidor legítimo no está involucrado en absoluto. No hay forma de que el servidor legítimo pueda proteger al cliente contra un ataque cuando el servidor legítimo ni siquiera participa en el protocolo.
respondido por el Gilles 28.04.2018 - 23:37
fuente

Lea otras preguntas en las etiquetas