¿Quieres recibir una notificación por email cada vez que Thetechguy escriba una noticia?
La muerte de la neutralidad de la red y el aflojamiento de las regulaciones sobre cómo los proveedores de Internet manejan el tráfico de la red de los clientes han generado muchas preocupaciones sobre la privacidad
La muerte de la neutralidad de la red y el aflojamiento de las regulaciones sobre cómo los proveedores de Internet manejan el tráfico de la red de los clientes han generado muchas preocupaciones sobre la privacidad. Los expertos en seguridad de la información también comentan que los proveedores de Internet han tenido durante mucho tiempo una herramienta que les permite monitorear los hábitos de Internet de las personas con facilidad: sus servidores del Sistema de nombres de dominio (DNS).
Los servicios DNS son las guías telefónicas de Internet, que proporcionan la dirección de red del Protocolo de Internet (IP) real asociada con los nombres de dominio y host de los sitios web y otros servicios de Internet. Ellos convierten a arstechnica.com en 50.31.169.131, por ejemplo. Su proveedor de Internet ofrece DNS como parte de su servicio, pero su proveedor también puede registrar su tráfico DNS, en esencia, registrando todo el historial de navegación.
Los servicios DNS “abiertos” brindan una forma de eludir los servicios de los ISP por razones de privacidad y seguridad, y en algunos lugares, evadir el filtrado de contenido, la vigilancia y la censura. Y en abril, Cloudflare lanzó su propio servicio de DNS autoritativo de alto rendimiento, gratuito, diseñado para mejorar la privacidad de los usuarios en Internet. Esta nueva oferta también prometió una forma de ocultar el tráfico de DNS completamente de la encriptación de vista.
Nombrado por su dirección de Protocolo de Internet, 1.1.1.1 es el resultado de una asociación con el grupo de investigación de seguridad de la información de APNIC, el registro de Internet de Asia y el Pacífico. Si bien también está disponible como una resolución de DNS convencional “abierta”, Cloudflare admite dos protocolos DNS encriptados.
Mientras se ejecuta con un único destello de Cloudflare, 1.1.1.1 no es el primer servicio DNS cifrado de ninguna manera: Quad9, OpenDNS de Cisco, el servicio 8.8.8.8 de Google y un host de proveedores más pequeños admiten varios esquemas para encriptar por completo las solicitudes de DNS. Pero el cifrado no significa necesariamente que su tráfico sea invisible; algunos servicios DNS cifrados registran sus solicitudes para diversos fines.
Aprovechar los servicios de DNS encriptados de Cloudflare o cualquier otro servicio de DNS enfocado en la privacidad no es tan fácil como cambiar un número en la configuración de red. Actualmente, ningún sistema operativo admite directamente ninguno de los servicios de DNS encriptados sin la adición de algún software que no sea apto para el consumidor.
Los investigadores de seguridad de información prueban y diseccionan clientes para múltiples proveedores de DNS utilizando tres de los protocolos establecidos para encriptación DNS: DNSCrypt, DNS sobre TLS y DNS sobre HTTPS.
Si bien el tráfico web y otras comunicaciones pueden estar protegidos por protocolos criptográficos como Transport Layer Security (TLS), casi todo el tráfico DNS se transmite sin cifrar. Eso significa que su ISP puede registrar los sitios que visita incluso cuando usa otro servicio de DNS y utiliza esa información para varios propósitos, incluido el filtrado del acceso al contenido y la recopilación de datos con fines publicitarios.
El problema donde tenemos resolvedores de resguardo en varios sistemas operativos y realmente no tenemos forma de protegerlos. Solo el uso de un servicio de DNS no logging ayuda en cierto grado. Pero no impide que alguien filtre esas solicitudes en función del contenido o capture las direcciones dentro de ellas con la captura de paquetes o el equipo de inspección profunda de paquetes. Además de los simples y pasivos ataques de escuchas, también existe la amenaza de ataques más activos contra su tráfico de DNS, esfuerzos de un ISP o un gobierno en el cable para “falsificar” la identidad de un servidor DNS, enrutando el tráfico a su propio servidor para iniciar sesión o bloquear el tráfico.
Mientras que las VPN ocultan el contenido de su tráfico de Internet, la conexión a una VPN podría requerir primero una solicitud de DNS. Y una vez que haya iniciado una sesión de VPN, los navegadores web u otro software pueden enrutar ocasionalmente las solicitudes DNS fuera de su conexión VPN, creando “filtraciones de DNS” que exponen qué sitios está visitando.
El tráfico encriptado asegura que el tráfico no pueda ser rastreado o modificado y que las solicitudes no puedan ser leídas por alguien disfrazado como el servicio DNS, eliminando los ataques de los intermediarios y el espionaje. El uso de un proxy DNS para uno de estos servicios ayudará a evitar fugas de DNS de VPN.
Ninguno de estos protocolos es actualmente soportado de forma nativa por cualquier solucionador de DNS preenvasado con un sistema operativo. Todos ellos requieren la instalación de una aplicación cliente que actúa como un “servidor” DNS local, transmitiendo las solicitudes realizadas por los navegadores y otras aplicaciones en sentido ascendente al proveedor de DNS seguro de su elección.
Por lo tanto, si elige sumergirse en el DNS cifrado, es probable que desee utilizar una Raspberry Pi u otra pieza de hardware dedicada para ejecutarlo como un servidor DNS para su red doméstica.
DNSCrypt, it can be used as part of a privacy solution—particularly when paired with a non-logging DNS provider.
“DNSCrypt is a bit more than a protocol, ” DNSCrypt developer Frank Denis said. “At this point, the community and the projects being worked on define it better than my weekend project protocol.”
“We encourage everybody to run their own servers and make it very cheap and easy to do so. Now that we have privacy-aware resolvers, one thing I’m trying to address right now is privacy-aware content filtering.”
Para las pruebas, el experto en seguridad de la información utilizó OpenDNS de Cisco como servicio DNS remoto. El rendimiento de DNSCrypt fue un poco más lento que el DNS convencional en las solicitudes por primera vez, pero DNSCrypt Proxy almacena en caché los resultados después de eso. Las consultas más lentas se encontraban en el rango de 200 milisegundos, mientras que las respuestas promedio eran más en el rango de 30 milisegundos.
La principal ventaja de DNSCrypt es que actúa como DNS “normal”. Utiliza el puerto de tráfico UDP 443, el mismo puerto utilizado para conexiones web seguras. Para disminuir aún más la probabilidad de ser bloqueado, puede cambiar la configuración de su cliente para forzarlo a usar TCP / IP para consultas, lo que lo hace parecer tráfico HTTPS a la mayoría de los filtros de red.
DNSCrypt no confía en las autoridades de certificación confiables para su encriptación: el cliente debe confiar en la clave de firma pública emitida por el proveedor. Esa clave de firma se utiliza para verificar certificados que se recuperan a través de solicitudes de DNS convencionales (no encriptadas) y se usan para el intercambio de claves, utilizando el algoritmo de intercambio de claves X25519.
Las interesantes opciones de criptografía de DNSCrypt pueden asustar a algunos desarrolladores. El protocolo utiliza la criptografía Curve25519 (RFC 8032), X25519 (RFC 8031) y Chacha20Poly1305 (RFC 7539). Una implementación del algoritmo X24419 está etiquetada como “hazmat criptográfico” en las bibliotecas de criptografía Python Python porque es muy fácil de configurar mal. Pero el algoritmo criptográfico subyacente que utiliza DNSCrypt, Curve25519, es “una de las curvas elípticas más fáciles de usar con seguridad”, dijo Denis.
Si bien hay una serie de servicios DNS que usan DNSCrypt, los proveedores de DNS más nuevos enfocados en la privacidad han evitado DNSCrypt y han optado por los otros contendientes bendecidos por IETF: DNS sobre TLS y DNS sobre HTTPS. DNSCrypt Proxy ahora admite DNS sobre HTTPS e incluye Cloudflare, Google y Quad9 en sus valores predeterminados de configuración.
Si bien el tráfico web y otras comunicaciones pueden estar protegidos por protocolos criptográficos como (TLS), casi todo el tráfico DNS se transmite sin cifrar
El DNS sobre TLS (Transport Layer Security) tiene algunas ventajas sobre DNSCrypt. Por un lado, es un estándar IETF propuesto. También es bastante sencillo en su enfoque: toma solicitudes de DNS de formato estándar y las encapsula en tráfico TCP cifrado. Aparte del cifrado basado en TLS, es esencialmente lo mismo que ejecutar DNS sobre TCP / IP en lugar de UDP.
Hay pocos clientes que funcionen para DNS sobre TLS. La mejor opción que encontró el profesional de seguridad de la información, llamada Stubby, fue desarrollada por el Proyecto de Privacidad de DNS.
Si bien consiguió que Stubby funcionara de manera confiable después de luchar con algunos problemas de dependencia de código en Debian, falló regularmente en Windows 10 y tiene tendencia a depender de MacOS.
El archivo de configuración de Stubby, escrito en YAML, permite la configuración de múltiples servicios IPv4 e IPv6 e incluye configuraciones para SURFNet, Quad9 y otros servicios.
Los clientes DNS-over-TLS autentican el servicio al que se conectan usando Simple Public Key Infrastructure (SPKI). SPKI utiliza un hash criptográfico almacenado localmente del certificado del proveedor, generalmente basado en el algoritmo SHA256. En Stubby, ese hash se almacena como parte de la descripción YAML del servidor en el archivo de configuración.
Después de que el cliente establece una conexión TCP con el servidor a través del puerto 853, el servidor presenta su certificado y el cliente lo comprueba contra el hash. Luego, el cliente y el servidor hacen un saludo de TLS, pasan las teclas y comienzan una sesión encriptada.
Después de ejecutar Stubby y ejecutar, cambió la configuración de red para DNS para realizar solicitudes a 127.0.0.1 (localhost). El tráfico de DNS pasó de ser legible a invisible.
Parte del problema de rendimiento está en el lado del servidor debido al peso adicional de usar TCP. El DNS generalmente usa UDP debido a su naturaleza sin conexión, mientras que un mensaje TCP requiere la negociación de la conexión y la verificación del recibo.
DNS sobre HTTPS: DoH!
Google y Cloudflare parecen favorecer a DNS a través de HTTPS, como el futuro de DNS encriptado. Un borrador del estándar IETF, el protocolo DoH encapsula las solicitudes de DNS con solicitudes de DNS seguras de HTTP en tráfico web encriptado.
Las solicitudes se envían como HTTP POST o GET con consultas en formato de mensaje DNS o como una solicitud HTTP GET utilizando JSON. Y no hay problema aquí con la gestión de certificados.
A pesar de que los píxeles apenas se vuelven a encerrar en el RFC para DoH, ya hay una gran cantidad de clientes DNS-HTTPS listos para ejecutar, aunque algunos de ellos están diseñados específicamente para un proveedor de DNS.
Tomemos el cliente de túnel Argo de Cloudflare, por ejemplo. Argo es una herramienta de túnel multipropósito destinada principalmente a proporcionar un canal seguro para que los servidores web se conecten a la red de entrega de contenido de Cloudflare.
Si inicia Argo desde la línea de comando, Argo dirige las solicitudes de DNS a https://cloudflare-dns.com/dns-query. Eso causa un pequeño problema si no hay un servidor DNS convencional configurado.
Esto se puede solucionar de una de tres maneras. La primera opción es configurar su dispositivo con el host local (127.0.0.1 para IPv4 y :: 1 en IPv6) como servidor DNS primario para su configuración de red y luego agregar 1.1.1.1 como una resolución secundaria. Esto funcionará, pero no es ideal para la privacidad o el rendimiento. Una mejor opción es agregar la URL del servidor en la línea de comando al inicio:
$ sudo cloudflared proxy-dns –upstream https://1.0.0.1/dns-query
También puede configurarlo como un servicio en Linux, utilizando un archivo de configuración basado en YAML que contiene las direcciones IPv4 e IPv6 del servicio DNS de Cloudflare:
proxy-dns: verdadero
proxy-dns-upstream:
Para confirmar que se trataba de un problema de DoH, el profesional de seguridad de la información probó otros dos “apéndices” de DoH. El primero era un proxy basado en Go para el servicio de DNS de Google sobre HTTPS llamado Dingo. Dingo trabaja exclusivamente con la implementación de DoH de Google, pero puede ajustarse para usar la instanciación más cercana del servicio de DNS de Google.
Al verificar cómo se resolvió dns.google.com a partir de una solicitud DNS estándar, obtuvo una dirección alternativa a la dirección IP 8.8.8.8 predeterminada de Google.
$ sudo ./dingo-linux-amd64 -port = 53 -gdns: servidor = 172.216.8.14
Esto reduce los tiempos de respuesta en un 20 por ciento.
El mejor rendimiento de DoH provino de DNSCrypt Proxy 2. Con la reciente adición del servicio DoH de Cloudflare a la lista de servicios DNS públicos del comisón, DNSCrypt Proxy casi siempre se conecta a Cloudflare de manera predeterminada debido a la baja latencia del servidor.
Todas las consultas se resolvieron en menos de 45 milisegundos, más rápido que el servicio de Cloudflare por un amplio margen.
En general, el rendimiento de DoH de DNSCrypt Proxy era prácticamente indistinguible del de la resolución de DNS sobre TLS.
