¿Por qué TLS necesita un protocolo explícito de latido?

Navega tus respuestas
22

La extensión de latido del protocolo TLS parece ser una idea útil para DTLS; De acuerdo con la especificación en sí, se puede usar para averiguar si un par aún está vivo (y evitar que los firewalls interrumpan la conexión) sin una renegociación y para el descubrimiento de MTU de ruta.

Sin embargo, no entiendo la motivación para especificarlo e implementarlo para un TLS regular basado en TCP. ¿El hecho de enviar fragmentos de datos de aplicaciones vacíos no resuelve el problema de que los firewalls con estado también eliminen conexiones inactivas?

El RFC para TLS permite explícitamente ese comportamiento:

  

Fragmentos de longitud cero de      Los datos de la aplicación PUEDEN enviarse, ya que son potencialmente útiles como      contramedidas de análisis de tráfico.

    
pregunta lxgr 09.04.2014 - 11:52
fuente

3 respuestas

15

El latido del corazón tiene dos propósitos: realizar alguna actividad a nivel de enlace (para evitar el cierre por los celosos cortafuegos) y para asegurarse de que el par esté vivo. Si desea hacer ambas cosas con fragmentos vacíos, entonces necesita alguna convención entre el cliente y el servidor, de modo que cuando envíe un fragmento vacío, el par responda con un fragmento vacío. Esto tiene potencial para bucles infinitos si no se realiza correctamente.

Además, cuando los fragmentos vacíos se utilizaron como una contramedida para el ataque BEAST, parecía que algunas implementaciones ampliamente desplegadas tenían problemas con ellos. Por eso hacemos una "división 1 / n-1", no una división "0 / n".

Por lo tanto, la extensión de latido es principalmente una formalización de esa convención similar a un ping, con su propia negociación y formato iniciales para que no surjan problemas de interoperabilidad.

    
respondido por el Tom Leek 09.04.2014 - 13:19
fuente
4

El principal beneficio para una implementación basada en TLS es que el mismo código de procesamiento de Registro SSL puede usarse para TLS y DTLS. De lo contrario, su código de procesamiento de registro SSL debe conocer el mecanismo de transporte subyacente.

El otro uso para esto es para protocolos de transporte confiables de transmisión múltiple, sobre los cuales tiene TLS. El ejemplo en el RFC es SCTP. En este caso, hay algún uso.

El uso práctico de esto sobre TCP es casi nulo.

    
respondido por el COL Wotohice 10.04.2014 - 15:05
fuente
-2

TCP ya tiene keepalives (y CADA conexión TCP debe estar protegida contra "cortafuegos celosos" si existe este requisito), por lo tanto, volver a mantener en SSL no sirve para nada.

    
respondido por el fidoman 10.04.2014 - 14:37
fuente

Lea otras preguntas en las etiquetas

¿Los certificados SSL / X.509 cubren todos los puertos para un host? Brute Forzar contraseña a un archivo cifrado de Truecrypt con conocimiento parcial