DTLS ( Datagram transport Layer Security, por sus siglas en inglés) proporciona privacidad en las comunicaciones UDP. Para entender DTLS bien, lo primero que hay que hacer es entender UDP.

UDP (User Datagram Protocol) es un protocolo del nivel de transporte basado en el intercambio de datagramas (encapsulado de capa 4 o de transporte del modelo OSI). Permite enviarlos a través de la red sin que se haya establecido previamente una conexión, dado que los propios datagramas incorporan suficiente información de direccionamiento en su cabecera. Al no tener confirmación ni control de flujo, los paquetes pueden adelantarse unos a otros. Es más, tampoco se sabe si el envío se ha realizado correctamente, ya que no hay confirmación de entrega o recepción.

Además de proporcionar privacidad a protocolos de datagrama, el protocolo DTLS permite a las aplicaciones cliente/servidor comunicarse sin escuchas no deseadas (eavesdropping), accesos no permitidos, modificaciones en los mensajes.

El protocolo DTLS está basado en el protocolo TLS (Transport Layer Security) y proporciona garantías de seguridad equivalentes. La semántica de los datagramas de los protocolos subyacentes no cambia al utilizar DTLS.

El motivo para no utilizar directamente TLS sobre UDP es que en UDP puede perderse o reordenarse paquetes y TLS no tiene herramientas para hacer frente a estos inconvenientes. La falta de fiabilidad genera los siguientes problemas:

• TLS no permite el descifrado independiente de paquetes, puesto que la verificación de integridad depende del número de secuencia. TLS utiliza números de secuencia implícitos, mientras que el protocolo DTLS utiliza números de secuencia explícitos para resolver este problema.
•  La capa de enlace de TLS permite que los mensajes se reciban de forma fiable, rompiéndose la conexión si se pierden estos mensajes. DTLS resuelve este problema utilizando un timer de retransmisión para los paquetes.

Existe, sin embargo, un problema de seguridad en DTLS, heartbleed, resultado de una mala implementación de la funcionalidad conocida como heartbeat. Aunque esta vulnerabilidad ya ha sido solventada, lo cierto es que presentaba un problema de seguridad bastante grave.

En febrero de 2012, la funcionalidad heartbeat se presentó como parte de la RFC para los protocolos TLS y DTLS. Su principal ventaja es que permite mantener una conexión abierta sin la necesidad de renegociar. La implementación con el fallo de seguridad fue añadida en la versión 1.0.1f de OpenSSL.

Para explotar el fallo de seguridad se siguen los siguientes pasos:

1. Un equipo envía un mensaje de “heartbeat request”, que suele ser una cadena de texto, junto con la longitud exacta de dicha carga útil.
2. El equipo receptor debe enviar, entonces, la misma cadena exacta de vuelta al remitente.
3. Las versiones afectadas de OpenSSL asignan un búfer de memoria para el mensaje a devolver basado en el campo de longitud del mensaje de solicitud, sin tener en cuenta el tamaño real de su carga útil. Al no comprobarse la longitud, el mensaje se devuelve junto con cualquier cosa que haya sido asignada en el buffer de memoria.

Al leer un bloque de memoria arbitrario del servidor, los atacantes pueden recibir datos importantes, lo que compromete la seguridad del servidor, sus comunicaciones y sus usuarios. Entre los datos que se pueden obtener está la clave maestra del propio servidor, que permitiría a los ciberdelincuentes descifrar el tráfico actual o almacenado mediante un ataque pasivo “man-in-the-middle”, si no se utiliza perfect forward secrecy para las comunicaciones; o activo, en caso de que se utilice perfect forward secrecy.

La corrección del fallo de seguridad se incluyó en la versión 1.0.1g de OpenSSL.

En definitiva, DTLS presenta una solución de seguridad para UDP bastante potente. Sin embargo, si se quiere utilizar la funcionalidad de heartbeat, hay que tener en cuenta el problema de seguridad, y utilizar la versión adecuada de OpenSSL en la cual el fallo haya sido resuelto (1.0.1g o subsiguientes).