¿Por qué no se puede hacer el protocolo SSL en un solo paso?

Navega tus respuestas
5

Estoy seguro de que hay muchas razones obvias para esto, pero ¿por qué no se puede iniciar una sesión SSL con un viaje de ida y vuelta?

Parece que esto sería suficiente:

  1. El cliente envía su clave pública
  2. El servidor responde con:
    • Su certificado (clave pública + lo que sea necesario para verificarlo)
    • Una clave simétrica para usar (cifrada con la clave pública del cliente / firmada con la clave privada del servidor)

Los problemas que se me ocurren son:

  1. Es posible que debas saber la versión del protocolo de antemano.

    • Parece que el protocolo podría diseñarse para que el cliente envíe primero una versión, luego su clave pública, y si el servidor no lo entiende, envía un mensaje de "intente esta versión", que sería más rápido en el mejor de los casos (el cliente y el servidor entienden el mismo protocolo), y tan rápido como SSL en el peor de los casos ("versión 2 ... mi clave pública", "No entiendo, use la versión 1", " versión 1 ... mi clave pública "," mi certificado ... clave cifrada).
    • Para hacer que el protocolo sea más compatible con versiones anteriores, podría tener dos versiones, una para intercambiar las claves públicas y otra para todo lo demás. Solo la versión de clave pública rompería la compatibilidad y requeriría el segundo viaje de ida y vuelta.
    • Obviamente, esto no sería compatible con SSL ahora, pero ¿por qué no estaba allí en primer lugar?

  2. Tal vez haya más trabajo para el servidor, ya que necesita (1) generar una clave simétrica criptográficamente segura, (2) cifrar esa clave usando cifrado de clave pública, (3) firmar el resultado de eso utilizando cifrado de clave pública . ¿El problema es que sería demasiado fácil sobrecargar el servidor?

  3. ¿Me falta algo?

Esto me ha estado molestando todo el día, ya que parece tan obvio, pero tiene que haber un defecto evidente que me falta (y por eso no soy un investigador de seguridad).

EDITAR:

Un enlace publicado por @lour tiene esta cita:

  

En un protocolo de enlace TLS, los mensajes "Finalizados" sirven para validar todo el protocolo. Estos mensajes se basan en un hash del protocolo de enlace procesado hasta ahora por un PRF ingresado con el nuevo secreto maestro (que funciona como MAC), y también se envían bajo la nueva especificación de cifrado con su MAC codificado, donde se deriva la clave MAC Del secreto maestro. El diseño del protocolo se basa en la suposición de que cualquier autenticación de servidor y / o cliente realizada durante el protocolo de enlace se traslada a esto. Si bien un atacante podría, por ejemplo, haber cambiado la lista de conjuntos de cifrado enviada por el cliente al servidor y, por lo tanto, haber influido en la selección del conjunto de cifrados (probablemente hacia una opción menos segura) o haber realizado otras modificaciones a los mensajes de intercambio de información en transmisión, el atacante debería no podrá redondear el protocolo de enlace modificado con un mensaje "Finalizado" válido: se presume que cada conjunto de cifrado TLS ingresa la PRF de manera apropiada para garantizar la impunidad. Una vez que se haya validado el protocolo de enlace mediante la verificación de los mensajes "Finalizados", esto confirma que no se ha modificado el protocolo de enlace, por lo que se está realizando un encriptado seguro (usando los algoritmos negociados) de la autenticación segura.

Entonces, ¿por qué no hacer que el servidor y el cliente firmen sus mensajes de negociación de cifrado con sus claves privadas? Lo sé, más trabajo, pero aún más rápido que un RTT, ¿verdad?

    
pregunta Brendan Long 21.09.2011 - 04:49
fuente

3 respuestas

15

Si entiendo su propuesta correctamente, hay al menos dos vulnerabilidades en ella:

Repetir ataque

Un atacante puede detectar una comunicación cifrada, grabarla y reproducirla más tarde.

Hay dos enfoques comunes para evitarlo: uso de sellos de tiempo, que solo funciona en un entorno controlado en el que puede estar seguro de que los relojes están sincronizados. Por lo tanto, el enfoque común Para evitar esto, ambas partes tienen que enviar un número aleatorio y requieren que la otra parte demuestre que obtuvo este número, ya sea devolviéndolo o usándolo en alguna operación matemática.

Hombre en el ataque central

El navegador envía su clave pública a un atacante. El atacante contacta con el servidor real y envía su propia clave pública.

El servidor responde con su certificado y la clave de sesión firmada con la clave privada del servidor y encriptada con la clave pública del atacante.

El atacante descifra la información y la vuelve a cifrar con la clave pública del cliente. La firma sigue siendo válida porque el atacante no modifica el certificado o la clave de sesión. Almacena la clave de sesión para su uso posterior.

El cliente verifica el certificado y la firma del servidor real, y está feliz.

Otros enfoques

Hay otro enfoque de Google llamado SSL False Start , que no tiene estas cuestiones.

    
respondido por el Hendrik Brummermann 21.09.2011 - 09:08
fuente
4

Teóricamente es posible hacerlo más rápido de lo que se hace. Gran parte de la razón por la que funciona de la forma en que lo hace se debe a la historia: Netscape esencialmente inventó SSL por su cuenta en 1994, y también fue en gran parte responsable de las revisiones que se convirtieron en SSL 3.0. IETF hasta después de ese tiempo, y el IETF esencialmente volvió a emitir la especificación SSL 3.0 como TLS 1.0, para fomentar la compatibilidad con versiones anteriores. Por lo tanto, muchas de las decisiones se tomaron en ese momento.

Algunas razones por las que no puede hacerse más rápidamente son los resultados de la flexibilidad incluida en el sistema. Por ejemplo, el servidor puede decidir si solicitar o no un certificado de cliente al usuario, y la conexión puede admitir el cambio de conjuntos de cifrado según sea necesario. La renegociación es compatible en una variedad de casos.

Al final, no importa mucho: la mayoría de las implementaciones hacen uso de la reanudación, donde el cliente especifica un ID de sesión establecido en una nueva conexión y el servidor simplemente retoma lo que dejó. En la práctica, los navegadores harán un saludo completo una vez y luego reanudarán la sesión una y otra vez. Cuando combinas eso con HTTP keepalive (el estado de cosas habitual en HTTP / 1.1), el resultado es que realmente no haces tantos apretones de manos completos como crees.

Si TLS fue rediseñado desde cero hoy, puede haberse hecho de manera diferente. Sin embargo, la imprudencia de TLS no es un problema práctico importante.

    
respondido por el Steve Dispensa 21.09.2011 - 15:49
fuente
2
  

3. ¿Algo me falta?

El problema más simple con su propuesta es que el servidor no tiene forma de autenticar la clave pública del cliente que se entrega en el primer tramo, por lo que usar esa clave para cifrar la clave simétrica deja la conexión completamente abierta a Man In The Middle.

Con el sistema actual, los muchos (clientes) deben buscar las pocas claves (servidor) para validar que están hablando con quienes creen que son (por ejemplo, "www.google.com"). Para revertir eso se requeriría un sistema de búsqueda relativamente masivo contra identificadores esencialmente arbitrarios y cambiantes ("dhcp123.dialup.bigisp.net").

Si desea guardar un salto, tome una página de Microsoft. Érase una vez que IE combinaría el ACK (tercer tramo del protocolo de enlace de tres vías) con la carga útil de datos de solicitud HTTP en un paquete. En general, solo los servidores IIS jugarían ese juego, por supuesto.

No estoy convencido de que la interrupción de estas cosas para guardar uno o dos paquetes valga la pena en cualquier caso, pero es un experimento digno de gedank.

    
respondido por el gowenfawr 21.09.2011 - 16:39
fuente

Lea otras preguntas en las etiquetas

Mis sitios han sido pirateados por cpamatik.com, pasan todas las comprobaciones de seguridad con Google y Sucuri, pero aún redireccionan, ¿alguna idea? [duplicar] ¿Puede el salt para PBKDF2 ser un hash de la contraseña ingresada por el usuario?