Ir al contenido principal

DNS sobre TLS: privacidad en el DNS

Privacidad en el DNS


En el sistema de nombres de dominio (DNS) la información de preguntas y respuestas siempre ha viajado "en plano" por la red. Es decir, sin cifrar. Todo lo que se consulta vía DNS puede ser leído por quienes se encuentren en el camino entre un cliente y su "servidor DNS recursivo", por ejemplo los proveedores de Internet (ISPs) y gente que pueda analizar los paquetes de la red.

Desde hace un tiempo que esto se ha visto con preocupación. Siempre se ha dicho que "los datos del DNS son públicos", lo que es cierto, pero lo que alguien esté consultando debiera ser privado. El sitio de alcohólicos anónimos es público, pero debiera ser privado quiénes están consultando por el. Esa es la diferencia.

Se ha trabajado desde distintos lados las mejoras de privacidad, en especial desde IETF, el organismo que estandariza los protocolos en Internet. Hay avances en TLS (también conocido como SSL) y por supuesto también en DNS, donde hay varias técnicas en camino.

Una de estas técnicas se llama "DNS over TLS", que aprovecha la encriptación y autenticación que ofrece TLS para mezclarlo con el soporte de transporte TCP en DNS.

Con los mayores riesgos de invasión a la privacidad de los usuarios, se hace necesario comenzar a preocuparse y cuidarse de este abuso.


DNS sobre TLS

Se trata del clásico protocolo DNS pero esta vez utilizando exclusivamente TCP (recuerden que el DNS clásico utiliza UDP en su gran mayoría, pero TCP siempre ha estado disponible), a lo que se suma el cifrado de TLS (que es el mismo cifrado que hace HTTPS del protocolo en plano HTTP). Utiliza un puerto especial (853) y requiere que los clientes que lo utilizan autentiquen el certificado del servidor por medio de "pinning" o bien utilizando las clásicas autoridades de certificados x509.

DNS-over-TLS utiliza técnicas de optimización como el reuso del canal TCP y la mantención de la conexión abierta, para lograr tiempos de respuesta similares al DNS clásico sobre UDP. De todas formas esta técnica viene penalizada por el costo extra de establecer la conexión TCP la primera vez, además del intercambio durante el cifrado TLS, pero se espera que en un uso normal de un
stub resolver cada consulta sucesiva sea solo resuelta en 1 paquete de ida y vuelta, quedando similar a UDP. Además el tener una sesión abierta en TCP permitirá otras técnicas futuras, como pipelining y "server-push".


dnsotls.lab.nic.cl

NIC Chile dispone de un "servidor de prueba" puesto a disposición de los desarrolladores y primeros usuarios en adoptar y probar esta tecnología. Este servidor es completamente funcional, y se invita a la comunidad de .CL a utilizarlo consiguiendo tiempos de respuesta nacionales, sin necesidad de utilizar
servicios en el extranjero. Este servicio se entrega en forma gratuita pero en modo experimental, sin promesas de uptime ni su continuidad en el futuro. Existe registro de las queries con fines de investigación y control de abuso.

Para utilizarlo, los datos son:
  IPv4: 200.1.123.46
  IPv6: 2001:1398:1:0:200:1:123:46
  Ports: 853 y 443
  Hostname: dnsotls.lab.nic.cl (con "strict name TLS authentication")
  SPKI: pUd9cZpbm9H8ws0tB55m9BXW4TrD4GZfBAB0ppCziBg= (pin sha256)

Se agradecen los reportes de fallas y feedback técnico a través del correo dnsotls@lab.nic.cl.

Para alternativas de software en el lado del cliente se recomienda stubby.

Más información en el sitio de DNS Privacy Project (en inglés).


Comentarios

  1. Para dar soporte en Android fue necesario obtener un certificado en Let's Encrypt.
    El SPKI nuevo es pUd9cZpbm9H8ws0tB55m9BXW4TrD4GZfBAB0ppCziBg=

    ResponderEliminar

Publicar un comentario

Entradas más populares de este blog

El servicio más extraño de NIC Chile

Uno de los servicios más extraños que nos ha tocado entregar dentro de NIC Chile desde tiempos históricos, es el de "verificador de la Internet funcionando" ;)

Muchos administradores de red en sus organizaciones, cuando necesitan confirmar que su conexión a Internet está funcionando, hacen una prueba muy sencilla llamada "ping". Este test es básicamente enviar un paquete especial a un servidor determinado, que te responde con una copia del mismo paquete recibido. De hecho, el nombre original del servicio es "eco". Lo de ping es el nombre de una de sus primeras implementaciones, que hacía ese sonido por los parlantes del computador cada vez que tenía una respuesta, al estilo de los sonares de submarinos :) Se trata de  una herramienta sencilla y básica de cualquier administrador de red, que provee una primera prueba de que un sitio remoto es alcanzable.


¿Y hacia qué servidor puedo enviar mis ping? En teoría, ¡a cualquiera! El servicio "eco" es pr…

DNS Flag Day: el fin de los parches provisorios para EDNS

El próximo 1° de febrero de 2019, los cuatro principales proveedores de software para DNS recursivos -Bind, Unbound, PowerDNS y Knot- realizarán un lanzamiento conjunto de nuevas versiones de sus sistemas con una característica en común: el fin de parches provisorios históricos que perdonaban ciertas conductas desviadas del estándar en los servidores DNS autoritativos.

Estas conductas incorrectas según el estándar EDNS ("Extensiones al DNS", disponibles desde 1999 en los RFC2671, actualizado por RFC6891) incluyen la falta de respuesta, encendido de bits incorrectos, demoras en respuesta, etc.; y se suman a ciertos dispositivos en el camino (firewalls, IDS, middleboxes, etc.) que descartan algunos paquetes DNS porque no calzan con la implementacion de DNS que conocen.

Estos problemas fuerzan actualmente a los DNS "resolvers" a implementar una serie de trucos para poder lidiar con muchos casos de borde. Estos trucos ocasionaban un aumento de complejidad en el código …

Cómo aguantar ataques DoS sobre tu DNS usando DNSSEC

Durante el año 2014 estuvo de moda un ataque de denegación de servicio (DDoS) sobre servidores DNS autoritativos llamado "random subdomain attack", donde el atacante orquesta una gran cantidad de servidores DNS recursivos y envía solicitudes normales de resolución de una enorme cantidad de subdominios inexistentes del dominio víctima.

De esta manera, si lo que quiero es atacar el nombre de dominio "ejemplo.cl", envío una gran cantidad de solicitudes de resolución a cientos o miles de (open) resolvers DNS por los nombres "kePhu5ieHui5eaBa.ejemplo.cl", "ieGie4eoEeb9Iwae.ejemplo.cl", etc. Los resolvers, al no tener este nombre en sus cachés, envían la consulta a los autoritativos de "ejemplo.cl", el que al verse amplificado por la capacidad de estos resolvers y el número de ellos, se ve sobrecargado de consultas y tráfico.

En ese momento se tomaron diversos mecanismos para soportar este ataque, algunos fuera del DNS como inspectores de pa…