Resumen

  • En un handshake completo, False Start dejaba que el cliente enviara datos bajo las claves nuevas después de su Finished mientras la prueba Finished del servidor aún volvía.
  • El protocolo ordinario seguía siendo obligatorio; adelantar la liberación exigía opt-in de la aplicación, listas criptográficas estrictas, protocolo seleccionado y una política para el fallo posterior.

El primer registro adelantó a la última prueba

El orden de RFC 5246 hace que el cliente procese certificado e intercambio de claves del servidor, envíe ChangeCipherSpec y Finished, y espere los mensajes equivalentes del servidor. Solo al verificar el Finished remoto considera completo el handshake y entrega datos de aplicación.

False Start superpuso esa espera con el primer registro. El cliente ya poseía las claves frescas y había enviado su propia prueba. El registro cifrado viajaba hacia el servidor mientras la confirmación final venía en sentido contrario.

RFC 7918 llama retroactiva a la validación exitosa. Cuando ambos Finished coinciden, el handshake final es ordinario; ha cambiado el momento del dato. La optimización no borró una ida y vuelta, sino que utilizó su tiempo antes de cobrar la prueba pendiente.

Había cifrado antes de haber confirmación final

Al decidir, el cliente ya conoce ServerHello, la suite, el certificado y los parámetros que necesita para producir el secreto. El dato viaja bajo el Cipher Spec recién acordado. No es texto claro ni una petición enviada a ciegas junto a ClientHello.

Sin embargo, el Finished servidor todavía debe confirmar que el otro extremo comparte secretos y transcript. Si falta o falla, el handshake nunca queda validado. Con el orden normal, el dato se habría retenido; con False Start ya salió.

Por eso la pregunta correcta no era solo si había cifrado, sino qué información podía revelarse antes de terminar la autenticación del transcript.

El servidor toleraba; no concedía una extensión

False Start fue un cambio opcional del cliente, no una extensión nueva con la que el servidor otorgaba permiso. El servidor compatible toleraba registros protegidos antes del punto en que su máquina de estados solía procesarlos.

La compatibilidad podía venir de un perfil de aplicación o conocimiento externo. El silencio no era consentimiento. Un reset de un intermediario o servidor mostraba una expectativa de orden, no que las nuevas claves fueran débiles.

La aplicación tenía que solicitar la opción. Solo ella podía comparar la latencia con el valor del primer mensaje. La biblioteca no sabía si se trataba de una lectura inocua, una credencial o una orden irreversible.

Las listas blancas limitaban la apuesta

RFC 7918 exige limitar versión, cifrado simétrico, intercambio de claves, parámetros y tipo de certificado de cliente. Sus intercambios recomendados son familias efímeras DHE y ECDHE con secreto hacia adelante. Ante duda, la conexión no debe usar False Start.

La versión y la suite importan porque un atacante puede intentar degradar la negociación. El registro ya habrá cruzado si la prueba restante falla. La lista, por tanto, no puede crecer automáticamente con cada nueva opción de una dependencia.

Aquí aparece el coste de ciclo de vida: actualización de biblioteca, fallback o nuevo valor por defecto puede cambiar qué conexión habla pronto. La política debe versionarse y revisarse como una superficie de publicación de datos.

La gramática debía fijarse antes del primer dato

RFC 7301 negocia ALPN dentro de los hello. El cliente propone protocolos en ClientHello y conoce la elección del servidor en ServerHello. Esa decisión llega antes de False Start.

ALPN no autoriza la optimización, pero evita enviar bytes sin saber qué protocolo los interpretará. Opt-in, protocolo seleccionado y combinación criptográfica deben apuntar al mismo perfil. El cifrado no hace seguro un mensaje que recibe la gramática equivocada.

El fallo no podía retirar lo enviado

Si el Finished servidor verifica, la sesión continúa. Si no llega o es incorrecto, el cliente debe terminar y presentar un error de autenticación. No debe convertirlo en timeout corriente ni repetir automáticamente una operación con efectos.

Cerrar detiene el futuro, pero no recupera el registro que alcanzó al par o a un endpoint activo. Esa es la irreversibilidad de False Start. Confidencialidad en tránsito y autorización para revelar ahora son decisiones diferentes.

False Start no fue 0-RTT

RFC 8446 diseñó TLS 1.3 con menos esperas y un mecanismo 0-RTT distinto. En una reanudación, 0-RTT puede salir tras ClientHello con claves derivadas de un PSK anterior. No tiene secreto hacia adelante ni garantía de no repetición entre conexiones.

False Start actúa en un handshake completo, usa claves frescas y espera hasta después del Finished del cliente. Su riesgo es el Finished servidor aún no verificado, no la repetición de datos PSK.

RFC 8470 añadió a HTTP Early-Data y 425 Too Early para manejar replay de 0-RTT. No son una reparación de False Start. RFC 9325 exige especificación de aplicación para 0-RTT y controles explícitos de ALPN y configuración uniforme. La disciplina de alcance se comparte; las propiedades no.

Fuentes y límites

El análisis usa RFC 5246, RFC 7301, RFC 7918, RFC 8446, RFC 8470 y RFC 9325. No mide despliegue actual. False Start no enviaba texto claro, no saltaba el certificado, no reanudaba una sesión ni requería una extensión del servidor.