Transport Layer Security (TLS) is a cryptographic protocol that encrypts and authenticates data between applications over networks, with TLS 1.3 offering enhanced security through removed legacy algorithms and forward secrecy. DNS over TLS, defined in RFC 7858, specifically encrypts DNS queries on TCP port 853 to prevent observation of user lookups, while poor TLS management including expired certificates, incomplete chains, and blocked ports causes outages and security exposure. Organizations must maintain certificate inventories, enforce automated renewal, set minimum protocol version policies, and ensure firewall rules allow DNS over TLS traffic to protect core network services and prevent unauthorized access or data tampering.
Cómo funciona TLS
TLS comienza con un «handshake» en el que el cliente y el servidor acuerdan los parámetros del protocolo, autentican el servidor y derivan claves de sesión compartidas. Tras el «handshake», los datos de la aplicación se envían en registros cifrados y protegidos contra la alteración.
- «Client hello»: el cliente abre una conexión TCP y envía las versiones de TLS, los conjuntos de cifrado y la información sobre el intercambio de claves que admite.
- «Server Hello» y certificado: el servidor selecciona los parámetros y envía su certificado para que el cliente pueda verificar su identidad.
- Validación del certificado: el cliente comprueba que el certificado forma parte de una cadena que conduce a una autoridad de certificación de confianza, que no ha caducado y que coincide con el nombre solicitado.
- Intercambio de claves: ambas partes utilizan un intercambio de claves efímeras para derivar las mismas claves de sesión sin enviarlas a través de la red.
- Datos de aplicación cifrados: los puntos finales cambian al cifrado negociado e intercambian datos de aplicación en registros protegidos.
TLS 1.3, definido en el RFC 8446, acorta el proceso de establecimiento de la conexión y elimina los algoritmos más antiguos y menos seguros. El TLS mutuo añade un certificado de cliente para que el servidor también pueda autenticar al cliente. Los pasos anteriores muestran el caso habitual de autenticación por parte del servidor.
Problemas habituales con TLS
Un certificado que caduca sin renovarse provoca advertencias en el navegador y fallos en las llamadas a la API, a menudo a horas inesperadas. Los servicios con muchos puntos de conexión, como los equilibradores de carga y las interfaces de gestión, son los que suelen pasarse por alto con mayor frecuencia.
Un servidor que envía únicamente su propio certificado y omite los certificados intermedios funciona en algunos navegadores, pero falla en herramientas de línea de comandos, clientes Java y dispositivos integrados. Las pruebas realizadas con varios tipos de clientes ponen de manifiesto esta deficiencia.
Los clientes rechazan un certificado cuando el nombre de host solicitado no figura en el campo «nombre alternativo del sujeto». Esto suele ocurrir cuando se accede a un servicio mediante una dirección IP o un nuevo alias que no está incluido en el certificado.
Los clientes más antiguos que solo admiten TLS 1.0 o 1.1, o los servidores que desactivan los algoritmos de cifrado que ofrece un cliente, fallan con errores de establecimiento de conexión. Las capturas de paquetes suelen mostrar una alerta justo después del «client hello».
Los clientes de DNS sobre TLS fallan o recurren al DNS sin cifrar cuando un cortafuegos bloquea el puerto TCP 853. El resultado es una resolución errónea o una pérdida silenciosa del cifrado, dependiendo de la configuración del cliente.