La esencia de "inicio falso TLS" es que, al final de un protocolo de enlace TLS normal, cada parte envía un mensaje Finished al interlocutor, y debe esperar del Finished de ese interlocutor antes de enviar los datos de la aplicación. . "Inicio falso" elimina que "debería esperar". Cada parte puede enviar los datos de la aplicación de inmediato. Esto implica una menor latencia 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, los apretones de manos "completos" y los "abreviados". 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 solo utiliza 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 primero su mensaje Finished , mientras que en un apretón de manos abreviado, el servidor envía primero su mensaje Finished .
En el contexto de HTTPS y sitios web, el cliente (un navegador web) normalmente inicia un solo saludo de TLS completo. Luego, el cliente también puede abrir algunas otras conexiones paralelas, esta vez utilizando apretones de manos abreviados. Cada conexión se utilizará para enviar varias solicitudes HTTP. Si se agota el tiempo de espera de una conexión, el navegador abrirá uno nuevo utilizando una vez más un apretón de manos abreviado. Como HTTPS es HTTP-within-TLS y HTTP comienza con una solicitud del cliente , la optimización de "inicio falso" produce cualquier mejora solo para la primera solicitud HTTP dentro de la primera conexión TLS con el servidor . Esto no es realmente un almuerzo gratis, sino un aperitivo gratis, como máximo.
Hablando criptográficamente, lo que sucede con un 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 verdadero servidor: en ese punto, 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 usó la clave pública del servidor autenticado (la del certificado del servidor), por lo que no existe ningún riesgo real de que un atacante suplantador pueda obtener información de esa manera, al menos mientras El algoritmo de intercambio de claves y el algoritmo de cifrado simétrico son seguros. Sin embargo, cuando el cliente envía una solicitud, el cliente no tiene ninguna prueba de que el servidor deseado esté realmente al tanto del intento de conexión. Esto es inofensivo en el contexto de HTTPS . Sería audaz suponer que no hay daño en él genéricamente .