Manténgalo cifrado, manténgalo seguro: trabajar con ESNI, DoH y DoT

Los últimos desarrollos en la protección de la privacidad en Internet incluyen la indicación de nombre de servidor TLS cifrado (ESNI) y el DNS cifrado en forma de DNS sobre HTTPS (DoH), los cuales son considerados muy controvertidos por los recolectores de datos.

Así que aquí hay un vistazo rápido a las razones por las que existen, los detalles sobre lo que son y la tecnología detrás de su funcionamiento.

DNS necesita funcionar correctamente

Las conexiones de red privada virtual (VPN) de túnel dividido, el protocolo de detección automática de proxy web (WPAD), el DNS de multidifusión de configuración cero (mDNS), las listas negras en tiempo real (RBL) y muchas otras tecnologías ampliamente implementadas se rompen cuando el DNS no funciona. t operar correctamente.

Romper Internet para obtener ganancias y fama

Ya en 2003, los usuarios de Internet aprendieron sobre la importancia del DNS a escala mundial cuando la empresa que entonces administraba el dominio de nivel superior (TLD) .com decidió dejar de emitir respuestas NXDOMAIN . En cambio, se hicieron pasar por cualquier dominio inexistente en un intento de publicar más anuncios, vender más dominios y, en última instancia, generar más ingresos. El efecto colateral inesperado resultó en un debate público y un informe condenatorio del Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN. De hecho, este proyecto se cerró, pero desde un punto de vista técnico, la vulnerabilidad persistió.

Más tarde, en 2008, se hizo público otro intento de manipular el DNS con fines de lucro cuando algunos de los ISP más grandes terminaron introduciendo varias vías para ataques de secuencias de comandos entre sitios contra literalmente cualquier sitio web. Debido a la naturaleza de las vulnerabilidades, incluso los sitios web alojados en una red privada y a los que no se puede acceder desde Internet pueden ser explotados.

El problema encontrado no está relacionado con los protocolos básicos de Internet, sino que es un problema exacerbado por la monetización inapropiada de ciertas funciones de DNS.

Paul Vixie, Consorcio de Sistemas de Internet (ISC)

Si bien es cierto que los protocolos en sí mismos no son realmente la causa del problema, también es cierto que estos protocolos no evitan que los malhechores abusen del sistema. Entonces, desde un punto de vista técnico, la vulnerabilidad persistió.

Rompiendo Internet para Vigilancia y Censura

En 2016, se observó que los ISP en Irán estaban manipulando el DNS. Esta vez, en lugar de inyectar anuncios, estaban bloqueando el acceso a los servidores de correo electrónico de 139 de los 10 000 dominios principales en Internet. No está claro si se trata de una política intencional de denegación de servicio contra estos dominios específicos, similar a la censura de renombre mundial en China, o tal vez solo un ejemplo de una mala implementación técnica de cualquier sistema que esté interceptando las consultas de DNS.

Es importante no saber por qué se intercepta el DNS: incluso si dejamos de lado las cuestiones morales y legales sobre la vigilancia y la censura generalizadas, la tecnología utilizada para hacer esto, por su propia naturaleza, no cumple con los estándares y podría muy bien estar interfiriendo con su uso normal, diario, razonable y legal de Internet.

Sin embargo, desde un punto de vista técnico, la vulnerabilidad persistió.

Romper Internet con fines nefastos

Por supuesto, no son solo las entidades comerciales y los gobiernos los que intentan interceptar el tráfico de Internet para sus propios medios. Hay muchos ejemplos de delincuentes que intentan secuestrar conexiones, generalmente con el fin de robar datos de usuarios o engañar a los usuarios para que revelen importantes credenciales de acceso. De manera más destacada, el envenenamiento de caché de DNS se ha utilizado para dirigir a los usuarios a sitios de phishing, implementar ransomware, implementar botnets, denegar el servicio a sitios web específicos y mucho más.

TLS filtra quién se conecta con quién

Transport Layer Security (TLS) es la tecnología detrás de HTTPS, la versión segura de HTTP en la que todos confiamos todos los días. Establecer una conexión TLS requiere una serie de pasos, durante los cuales el servidor prueba su identidad presentando un certificado y se intercambian nuevas claves de cifrado.

Hacer que el servidor use un certificado para probar su identidad es un paso muy importante, ya que una parte del certificado es una clave de cifrado pública asimétrica.

Cuando el cliente envía un mensaje utilizando esta clave, solo el servidor que posee la clave privada asociada puede leer el mensaje. Como resultado, cualquier persona que intercepte o escuche la conexión queda bloqueada y no puede leer el contenido.

Sin embargo, ese intercambio inicial aún se realiza sin cifrado, lo que significa que un observador siempre conocerá la identidad del servidor.

Frente de dominio

Algunas herramientas de tipo anticensura solucionaron esta fuga en TLS durante un período de tiempo utilizando una técnica conocida como fachada de dominio. Esto aprovecha el hecho de que una vez que se establece una conexión HTTPS, la mayoría de los grandes proveedores de alojamiento no verifican si el nombre de host presentado en cada solicitud HTTP coincide con el utilizado en el protocolo de enlace TLS. En términos de herramientas de privacidad, esto se consideró una función útil que permitía la comunicación secreta con un sitio oculto. Para los proveedores de alojamiento y los recopiladores de datos, esto fue visto como un abuso de la forma en que se implementó la especificación.

Esto es en sí mismo una vulnerabilidad y, como tal, ha sido corregido por varios de los principales proveedores de alojamiento, incluido AWS.

Resolviendo el problema cambiando el estándar: SNI cifrado (ESNI)

La idea detrás de ESNI es evitar que TLS filtre datos cifrando todos los mensajes, incluido el mensaje inicial de saludo del Client Hello . Esto deja a cualquier observador completamente a oscuras sobre qué certificado de servidor está presentando el servidor.

Para ello, el cliente necesita una clave de cifrado antes de realizar la conexión. Por lo tanto, ESNI requiere que se coloque un conjunto específico de claves de cifrado ESNI en un registro SRV en DNS.

Sin embargo, los detalles exactos de esto aún están cambiando, ya que la especificación aún no se ha finalizado. A pesar de esto, Mozilla Firefox y Cloudflare ya han puesto en producción una implementación de ESNI.

Protección y cifrado de DNS

Para que las claves ESNI se entreguen sin ser interceptadas, es importante protegerse contra la manipulación del DNS.

Desde 1993, la comunidad de Internet ha estado tratando de proteger el DNS. El IETF señala que las primeras reuniones de resolución de problemas discutieron:

1. Protección contra la divulgación de datos DNS a terceros no autorizados
2. Garantizar la integridad de los datos
3. Autenticación de origen de datos

Estas reuniones dieron como resultado el estándar de extensiones de seguridad del sistema de nombres de dominio (DNSSEC) en 1997. El estándar eligió abordar dos de tres de estas preocupaciones, ya que el equipo de diseño tomó la decisión explícita de descartar todas las amenazas de divulgación de datos explícitamente fuera del alcance.

Como tal, DNSSEC significa que los usuarios pueden confiar en que las respuestas a sus consultas de DNS son las que los propietarios de dominio pretenden que sean. En el contexto de ESNI, esto significa que sabemos que la clave que recibimos no ha sido manipulada y, afortunadamente, muchas de las vulnerabilidades mencionadas anteriormente desaparecen cuando se usa DNSSEC. Sin embargo, no garantiza la privacidad y, por lo tanto, sigue siendo vulnerable a los problemas introducidos por los sistemas de vigilancia y censura.

Desafortunadamente, como es totalmente compatible con versiones anteriores del "DNS inseguro" y bastante difícil de implementar correctamente, la adopción de DNSSEC es muy baja. Muchos propietarios de dominios se dan por vencidos a la mitad del intento de configurarlo, como lo demuestran numerosas configuraciones inválidas y medio configuradas que se ven en la naturaleza.

DNS sobre HTTPS (DoH)

Para que las claves ESNI se entreguen sin que los observadores sepan qué sitio intentan visitar los usuarios, es importante protegerse contra las escuchas de DNS. Como tal, es bastante lógico y comprensible decir que el DNS encriptado (como con DoH) es algo bueno. Sin embargo, tal como está hoy, el DNS no está encriptado.

Hay movimientos de Mozilla, Google, APNIC, Cloudflare, Microsoft y otros para cambiar esto.

La experiencia de usuario cifrada ideal

Un usuario que desee aprovechar las tecnologías anteriores puede tener una lista bastante larga de requisitos en lo que respecta a los detalles prácticos de UX de trabajar con cifrado. Probablemente, querrían evitar cosas como:

• Verse obligado a utilizar un proveedor de servicios de DNS específico (no importa lo bueno que sea) o que la elección sea invisible o difícil de encontrar
• Cada aplicación en un dispositivo maneja el DNS de manera diferente (por ejemplo, Firefox puede encontrar cosas que Safari no puede)
• Todas las aplicaciones en un dispositivo que tienen que crear su propia implementación de DNS seguro dentro de sí mismo
• Tener que configurar DNS manualmente varias veces
• Tener que optar por la privacidad y la seguridad
• Aplicaciones que recurren a un funcionamiento inseguro sin el consentimiento del usuario

En cambio, los usuarios conscientes de la privacidad querrían:

• Privacidad de la vigilancia injustificada por cualquier persona
• Protección contra publicidad dirigida a la que no han dado su consentimiento.
• Protección de su propio contenido publicado (p. ej., en un sitio web personal) para que no sea modificado o manipulado en el camino hacia otros espectadores
• Garantía de que los espectadores de su propio contenido publicado no tendrán problemas simplemente por acceder a él.
• Seguir teniendo la opción de controlar el DNS en sus propias redes (porque, a veces, el DNS de horizonte dividido es bueno para mantener los recursos internos limitados a los usuarios internos)
• La capacidad de participar, o al menos optar por no participar, en el filtrado a nivel de DNS (p. ej., Quad9, CleanBrowsing y OpenDNS Family Shield)
• Configuración sencilla y sin complicaciones (es decir, DHCP)
• Que se le solicite su consentimiento para usar DNS sin encriptación
• Protección no solo para el tráfico del navegador, sino para todo tipo de tráfico, por ejemplo, correo electrónico, Slack, VoIP, SSH, VPN, etc.

Esfuerzos actuales de cifrado

¿Qué opciones hay para los usuarios con los objetivos anteriores?

La solución de Mozilla es un comienzo, pero está lejos de ser ideal. Solo están asegurando Firefox; el valor predeterminado es anular la configuración de su sistema operativo a favor de su elección de proveedor (Cloudflare) sin decirlo, y silenciosamente vuelve a ser inseguro (en casos de bloqueo de DNS encriptado, etc.)

La solución de Google es un mejor enfoque. Están asegurando Android 9+, que se aplica a todas las aplicaciones. (No estoy seguro de sus planes para Chrome OS, pero sospecho que está en proceso). También están asegurando Chrome en todas las plataformas, pero solo activa la seguridad cuando la plataforma host está configurada para usar un proveedor que admita seguridad. Esto es bueno en términos de elección del usuario, pero no es ideal porque silenciosamente vuelve a ser inseguro.

Todos los demás navegadores principales también están implementando soporte.

En la situación ideal para los usuarios, la comunidad más amplia de desarrolladores de software y sistemas operativos:

1. Deje de implementar nuevas funciones de seguridad de DNS a nivel de aplicación
2. Comience a implementarlos a nivel del sistema operativo
3. Respete la configuración a nivel del sistema operativo u obtenga el consentimiento del usuario

Al implementar el DNS encriptado a nivel del sistema operativo, podríamos continuar siguiendo el mismo modelo distribuido que tenemos actualmente para los resolutores de DNS. Ejecutar el propio servidor DNS en su propia red y poder hacer que ese resolutor sea seguro, tiene sentido seguir siendo una opción, al igual que usar un proveedor centralizado.

Linux y BSD ya tienen esta funcionalidad con una variedad de opciones disponibles. Desafortunadamente, ninguna distribución habilita ninguno de ellos de forma predeterminada, que yo sepa. Echa un vistazo a nss-tls si quieres algo que simplemente se conecte a glibc.

La implementación de DNS sobre TLS de Google en Android 9+ también hace esto. Funciona probando el servidor DNS para soporte de encriptación. Si lo tiene, lo usará. Si no es así, entonces, al igual que con Chrome, continúa de manera insegura, sin solicitar el consentimiento.

Vale la pena señalar que la mayoría de las redes están configuradas para usar servidores DNS que no admiten el cifrado, por lo que la solución integrada en Android aún no cambia nada para la mayoría de los usuarios. Tal vez sería mejor ofrecer recurrir a un DNS cifrado centralizado en los casos en que el descentralizado no admita el cifrado.

Para los dispositivos tipo Apple y Microsoft, el soporte para DNS encriptado aún no ha llegado oficialmente al momento de escribir este artículo. Dado que Microsoft anunció en noviembre de 2019 sus intenciones de admitir DNS encriptado, es de esperar que Apple lo siga pronto.

Soluciones alternativas de DNS cifrado

Existen algunas soluciones alternativas en forma de proxies que se pueden ejecutar localmente. Con estos, la computadora de un usuario habla DNS no encriptado para sí mismo, que luego habla DNS encriptado a cualquier proveedor que esté configurado para usar. Esta no es una solución ideal, pero a medida que avanzan las soluciones, es decente.

La inspiración para escribir este artículo es el proxy DNSCrypt, que es muy estable, tiene muchos accesorios y es multiplataforma. Es compatible con el antiguo protocolo DNSCrypt, así como con los nuevos protocolos DNS sobre TLS (DoT) y DNS sobre HTTPS (DoH).

Para los usuarios de Windows, hay un instalador y una GUI llamados Simple DNSCrypt, que tiene todas las funciones y es muy fácil de usar.

Lo recomiendo, pero tenga en cuenta que el mundo probablemente aún no esté listo para usted y es posible que deba desactivarlo de vez en cuando (por ejemplo, cuando tenga que usar un portal cautivo en su café favorito o en una LAN). fiesta).

Otras opciones

Además, está el servidor Technitium DNS, que admite DNS encriptado, es multiplataforma (Windows, MacOS, Linux en ARM/Raspberry Pi) y cuenta con una interfaz web elegante. Está bajo "otro" porque es más una herramienta integral que una solución específica para este problema. (Probablemente sería una buena opción si desea ejecutar su servidor DNS Raspberry Pi en casa. Me interesaría escuchar los comentarios de las personas que lo prueban en los comentarios a continuación).

Para sus dispositivos Android o iOS (iPhone, iPad, etc.), también existe la aplicación 1.1.1.1, que forzará todas sus consultas de DNS a través del servicio de DNS cifrado de Cloudflare. Escuché que también hay aplicaciones más flexibles, como Intra, pero aún no he dedicado tiempo a probarlas.

Por supuesto, también puede habilitar el DNS encriptado tanto en Firefox como en Chrome, solo tenga en cuenta todas las advertencias mencionadas anteriormente.

Confiabilidad de DNS: trabajo número uno

Hay mucha controversia con la tecnología de privacidad en Internet. Sin embargo, cuando se trata de implementar medidas de seguridad y privacidad, la tecnología en cuestión no se trata principalmente de guardar secretos. Se trata de asegurar la confiabilidad y garantizar que la tecnología siga funcionando correctamente a pesar del comportamiento de los demás. Sin embargo, debemos tener en cuenta que, así como la tecnología sin garantías de privacidad es mala, las garantías que se implementan de manera deficiente solo pueden empeorar la situación.