¿Por qué TLS requiere TCP?

TLS requiere un transporte confiable. En Internet, esto deja solo TCP, ya que UDP no ofrece confiabilidad.

TLS requiere un transporte confiable porque (de acuerdo con la arquitectura en capas del modelo de referencia ISO / OSI) no maneja errores de transporte, paquetes perdidos u otras perturbaciones que puedan ocurrir con la IP.

TLS está diseñado para ofrecer un canal seguro además de un transporte confiable y lo hace bastante bien. DTLS realiza (asumo) el manejo necesario de errores dentro del protocolo.

Si se realizara TLS a través de UDP, las conexiones y los protocolos podrían fallar solo porque un paquete se perdió en el tránsito y nadie lo notó.

La mitigación de tales problemas es (según el modelo de referencia ISO / OSI) la tarea designada de un transporte confiable. Cualquier transporte confiable funciona en teoría, pero para todos los propósitos prácticos de las redes IP, esto generalmente implica TCP.

TLS no requiere TCP, solo requiere un transporte confiable. Incluso hay un estándar para TLS sobre SCTP que es otro protocolo de transporte confiable.

Pero, si tomas el internet de hoy, por lo general solo tienes UDP y TCP como protocolos de transporte sobre IP y de estos dos TCP es el único confiable. Lo que significa que, si solo tiene disponible esta selección limitada de protocolos de transporte, TLS requiere TCP porque no funciona con UDP. Para trabajar con UDP, existe un protocolo similar DTLS que está diseñado para funcionar en transportes no confiables.

Además de lo que otros ya han dicho, TLS requiere un protocolo de capa de transporte confiable porque requiere que todos los paquetes de datos se reciban, se reciban en orden y se reciban sin corromper. Hay varias razones para esto:

• Si un paquete se eliminara o se corrompiera, TLS no tendría forma de recuperar los datos de ese paquete para presentarlos a la capa de aplicación y, por lo tanto, se perdería el supuesto de confiabilidad presentado a la capa de aplicación.

• Si un paquete se corrompiera, incluso por un solo bit, es probable que esté completamente confuso debido al cifrado, especialmente si se está utilizando un cifrado de bloque.

• Si un paquete se perdió, se corrompió o se procesó fuera de orden, cualquier esquema de cifrado basado en Cipher El Encadenamiento de bloques no solo no podrá descifrar el bloque actual, sino que también fallará para cada bloque posterior, ya que cada bloque depende del bloque anterior (y, por lo tanto, de todos los bloques anteriores). Por lo tanto, cualquier paquete un error en la red en absoluto requeriría que la conexión TLS se interrumpa y se renegocie. El bloque de cifrado encadena XOR el texto sin formato para un bloque de cifrado con el texto cifrado del bloque anterior antes de cifrarlo para evitar que alguien que supervise el texto cifrado pueda detectar patrones de texto duplicado del texto cifrado.

• Si un registro estuviera dañado, incluso por un solo bit, el Código de autenticación del mensaje no coincidirá, haciendo que TLS piense (correctamente) que el mensaje se había alterado durante el tránsito, lo que provocaría que la conexión TLS se interrumpiera.

• Si se recibiera un registro fuera de orden mientras un cifrado de flujo estaba en uso, la parte del mensaje en ese registro se descifraría incorrectamente (utilizando la parte incorrecta del flujo) y, por lo tanto, la La comprobación de MAC fallaría y la conexión TLS se rompería.

Por supuesto, el propio TLS funcionará bien siempre y cuando el protocolo de transporte subyacente proporcione la garantía de confiabilidad. No hay nada dentro de TLS que requiera que el protocolo de transporte subyacente sea TCP. Por supuesto, TCP es generalmente el protocolo confiable de elección cuando se trata de Internet.

TLS no requiere TCP. Por ejemplo, uso una clave de autenticación TLS con OpenVPN que (según mi configuración para reducir los gastos generales) pasa por una interfaz TUN que funciona en UDP . El TLS se puede usar en ambos, y probablemente sobre otras cosas que no conozco.