He estado leyendo varios RFC y no pude encontrar una respuesta definitiva a mi pregunta: ¿una extensión TLS negociada puede omitir algunos de los mensajes de saludo de TLS y seguir cumpliendo con la especificación TLS? Mi objetivo es desarrollar una nueva versión de TLS, a la vez que preferible, seguir siendo compatible con versiones anteriores.
Aquí, hablaré específicamente sobre TLS 1.2 , definido en RFC 5246 . A continuación se muestra un flujo de mensajes para el protocolo de enlace completo (tomado directamente de RFC 5246):
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent.
Ahora, sé que es perfecto para una extensión TLS modificar la estructura de algún mensaje o agregar un nuevo , pero no estoy seguro de si se puede omitir uno de los mensajes, no definido como opcional / dependiente de la situación .
Déjame darte un ejemplo concreto. Digamos que creo una nueva extensión llamada XYZ . El cliente y el servidor negocian esa extensión en sus mensajes de saludo extendidos. ¿Sería legal que la extensión XYZ obligue al servidor a no enviar el mensaje ServerHelloDone ? Por lo que he entendido, esto no es legal .
RFC 5245 Sección 4.4.1.4 indica que:
it would be technically possible to use extensions to change major aspects of the design of TLS; for example the design of cipher suite negotiation. This is not recommended; it would be more appropriate to define a new version of TLS -- particularly since the TLS handshake algorithms have specific protection against version rollback attacks based on the version number, and the possibility of version rollback should be a significant consideration in any major design change
Sin embargo, supongo que esos aspectos principales no incluyen omitir mensajes no marcados como opcionales / dependientes de la situación en la especificación.