Pregunta:
¿Existe algún problema de seguridad con el inicio falso de Google para TLS?
Rakkhi
2011-05-23 13:54:43 UTC
view on stackexchange narkive permalink

Google anunció recientemente un inicio en falso en los navegadores Chrome que aumentó el rendimiento de TLS en un 30% http://news.softpedia.com/news/Google-Chrome-s-SSL-False-Start-201253.shtml

Sé que TLS ha sido analizado y estudiado por muchas personas durante años, pero aún es posible que la implementación sea incorrecta. ¿Alguien está al tanto de investigaciones sobre debilidades de seguridad o posibles vulnerabilidades con respecto a cómo Google está logrando esta ganancia de rendimiento (incluso si aún no se ha escrito ningún código de explotación)? Sospecho de un almuerzo gratis cuando se trata de seguridad y criptografía en particular.

One responder:
Thomas Pornin
2011-05-23 17:42:29 UTC
view on stackexchange narkive permalink

La esencia del "inicio falso de TLS" es que, al final de un apretón de manos de TLS normal, cada parte envía un mensaje Finished al par y debe esperar desde el Finished de ese par antes de enviar datos de la aplicación. "Inicio en falso" elimina ese "debería esperar". Cada parte puede enviar los datos de la solicitud de inmediato. Esto implica una latencia más baja si la parte que envía el Finished primero es también la que enviaría los datos aplicativos primero.

Tenga en cuenta que hay dos tipos de apretones de manos TLS, el "completo" y el "abreviado". Este último se utiliza para "reanudar" una sesión TLS, es decir, para volver a calcular una nueva clave de sesión sobre una clave maestra ya intercambiada; el protocolo de enlace abreviado usa solo criptografía simétrica y requiere menos intercambios de red. Un punto que vale la pena señalar es que en un apretón de manos completo, el cliente envía su mensaje Finished primero, mientras que en un apretón de manos abreviado, el servidor envía su mensaje Finished primero.

En el contexto de HTTPS y sitios web, el cliente (un navegador web) normalmente inicia un solo protocolo de enlace TLS completo. Luego, el cliente también puede abrir algunas otras conexiones paralelas, esta vez usando apretones de manos abreviados. Cada conexión se utilizará para enviar varias solicitudes HTTP. Si una conexión se agota, el navegador abrirá una nueva usando una vez más un protocolo de enlace abreviado. Dado que HTTPS es HTTP dentro de TLS y HTTP comienza con una solicitud del cliente , la optimización del "inicio falso" produce una mejora solo para la primera solicitud HTTP dentro de la primera conexión TLS al servidor. . Esto no es realmente un almuerzo gratis, sino un aperitivo gratis, como mucho.

Criptográficamente hablando, lo que sucede con el inicio falso es que el cliente acepta enviar sus datos (la solicitud HTTP) antes de tener la confirmación de que realmente habló con el servidor verdadero: en ese momento, desde el punto de vista del cliente, el servidor está autenticado implícitamente . Los datos aplicativos se cifran con una clave de sesión derivada de un intercambio de claves que utilizó la clave pública del servidor autenticado (la del certificado del servidor) por lo que no existe un riesgo real de que un atacante que se hace pasar por suplantación pueda obtener información de esa manera, al menos siempre que el algoritmo de intercambio de claves y el algoritmo de cifrado simétrico son seguros. Sin embargo, el cliente no tiene ninguna prueba, cuando envía su solicitud, de que el servidor previsto realmente esté al tanto del intento de conexión. Esto es inofensivo en el contexto de HTTPS . Sería audaz asumir que no hay ningún daño en él genéricamente .

@Thomas-pornin ¡gran respuesta y no tan técnica que incluso yo podría seguirla! Entonces, ¿es esto correcto: el cliente ha verificado el certificado del servidor (o ha lanzado una advertencia), la clave de sesión está acordada y el cliente comienza a enviar datos antes de que los servidores envíen el "Finalizado"? Debido a que se ha verificado el certificado del servidor, no hay riesgo de que un hombre en el medio u otro ataque, por ejemplo Secuestro de DNS cuando el cliente envía terminado?
@Rakkhi: sí, eso es todo. Criptográficamente, los datos enviados por el cliente están seguros. Al usar el inicio falso, el cliente simplemente acepta enviar su solicitud antes de asegurarse de que el servidor está realmente allí; pero no importa, ya que el cliente esperará la respuesta HTTP, momento en el que el cliente tiene la confirmación de que el verdadero servidor está hablando.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...