¿El Cliente puede enviar los datos de la Aplicación en TLS 1.2 o anterior antes de recibir el mensaje Finalizado del servidor?

Question

¿El Cliente puede enviar los datos de la Aplicación en TLS 1.2 o anterior antes de recibir el mensaje Finalizado del servidor?

#1 de Steffen Ullrich (3 votos)

3

He leído Ivan Ristic, SSL y TLS a prueba de balas. No se ha dicho después de 2 RTT, el cliente comienza a enviar datos de la aplicación como, por ejemplo, Solicitud GET.

Pero al analizar paquetes a través de Wirehark, he visto que en algunos sitios los clientes comienzan a enviar la aplicación junto con el mensaje ClientFinished, es decir, después de 1 RTT, mientras que en algunos casos no lo hace y comienza a enviar los datos de la aplicación después de 2 RTT, es decir, después de recibir ServerFinished mensaje.

Creo que no es necesario esperar hasta que ServerFinished envíe los datos de la aplicación ya que el cliente ya tiene una clave, por lo que puede comenzar a enviar los datos de la aplicación.

¿En qué casos envía el cliente los datos de la aplicación antes del mensaje ServerFinished y en qué casos después del mensaje ServerFinished?

Si 1 RTT ya estaba allí en TLS 1.2, entonces ¿por qué hay tanta confusión sobre 1 RTT en TLS 1.3? Por cierto, esta no es mi pregunta principal, responda si lo desea.

Copiado desde RFC

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

web-browser tls

pregunta prakharjain 06.05.2017 - 09:43

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-browser tls

¿Permitiría este enfoque el manejo de contraseñas seguro y malicioso? pregunta sobre IDS e IPS

score 3 · Accepted Answer

Aunque no sé qué es exactamente lo que has visto, el TLS 1.2 indica explícitamente que los datos de la aplicación solo deben enviarse una vez que se haya completado el protocolo de enlace. Esto significa que ambas partes han recibido y verificado el mensaje Finalizado de la otra parte. Esto se indica en varias partes de la RFC 5246 , como

7.4.9. Acabado
...
Una vez que un lado ha enviado su mensaje Finalizado y recibido y validado el Mensaje terminado de su par, puede comenzar a enviar y recibir Datos de la aplicación a través de la conexión.

En un apretón de manos completo, el mensaje finalizado es enviado primero por el cliente y luego por el servidor. Esto significa que el cliente tiene que esperar a que el servidor reciba y verifique el mensaje finalizado del cliente y luego envíe su propio mensaje finalizado. Y solo después de que el cliente haya recibido y verificado este mensaje finalizado desde el servidor, puede enviar los datos de la aplicación.

Pero, dentro de una sesión exitosa, el servidor finaliza primero el mensaje Finalizado y luego el cliente. Y, en este caso, los datos de aplicación del cliente pueden, por supuesto, seguir directamente el mensaje Finalizado del cliente. De la página 37 de RFC 5246:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

      Figure 2.  Message flow for an abbreviated handshake

... que en algunos sitios, los clientes comienzan a enviar la aplicación junto con el mensaje ClientFinished, es decir, después de 1 RTT, mientras que en algunos casos no lo hace y comienza a enviar los datos de la aplicación después de 2 RTT

Una posibilidad es que solo haya notado que los datos de la aplicación del cliente siguieron directamente el mensaje Finalizado, pero que no se dio cuenta de que esto sucedió porque se produjo una reanudación de la sesión y, por lo tanto, ya se recibió y verificó el Finalizado del servidor. por el cliente.

Pero, después de haber editado la pregunta e incluir una imagen, es obvio que este no es el caso y se realizó un saludo completo con el envío temprano de los datos de la aplicación. Esto se llama TLS False Start y se define en RFC 7918 . De acuerdo con este RFC, se puede realizar un inicio falso si el cliente tiene conocimiento previo de que el servidor es compatible con un inicio falso y si se usan cifrados fuertes en la lista blanca para usar con el inicio falso. Para una breve introducción a TLS False Start, vea High Performance Red de navegadores .

Si 1 RTT ya estaba allí en TLS 1.2, entonces ¿por qué hay tanta confusión sobre 1 RTT en TLS 1.3?

TLS 1.3 cambió mucho el protocolo. El resultado de esto fue 1-RTT en lugar de 2-RTT para el apretón de manos completo y, opcionalmente, 0-RTT en lugar de 1-RTT en las conexiones posteriores (es decir, qué se reanudó la sesión en TLS 1.2).