A lo largo de la existencia de Internet, la apertura ha sido una de sus características definitorias, y la mayor parte del tráfico actual todavía se transmite sin cifrado. La mayoría de las solicitudes de páginas HTML y contenido relacionado se hacen en texto plano, y las respuestas se devuelven de la misma manera, a pesar de que el protocolo HTTPS existe desde 1994.
Sin embargo, a veces hay una necesidad de seguridad y / o confidencialidad. Aunque el cifrado del tráfico de Internet se ha generalizado en áreas como la banca en línea y las compras, el problema de mantener la confidencialidad en muchos protocolos de Internet no se ha resuelto tan rápidamente. En particular, cuando se consulta la dirección IP de un sitio para un host, una consulta DNS casi siempre se transmite en texto claro, lo que permite a todas las computadoras y proveedores determinar qué sitio está visitando, incluso si usa HTTPS después de establecer una conexión.
La idea de que el cifrado también es necesario para las consultas DNS no es nueva, y los primeros intentos se hicieron en la década de 2000: DNSCrypt, DNS sobre TLS (DoT), etc. Mozilla, Google y otras grandes compañías de Internet están promoviendo un nuevo método de encriptación de consultas
DNS :
DNS sobre HTTPS (DoH).
DoH no solo cifra la consulta DNS, sino que también la transfiere al servidor web “normal”, no al servidor DNS, por lo que el tráfico DNS no puede distinguirse del HTTPS normal. Esta moneda tiene dos caras. Este procedimiento protege la consulta DNS en sí misma, como DNSCrypt o DoT, y también hace que sea imposible para los chicos de los servicios de seguridad de las grandes compañías rastrear la
suplantación de DNS , y transfiere la responsabilidad de las funciones críticas de la red desde el sistema operativo a la aplicación. Y tampoco ayuda de ninguna manera a ocultar la dirección IP del sitio web que acaba de solicitar; después de todo, debe acceder a ella de todos modos.
En comparación con DoT, DoH centraliza la información sobre los sitios que visitó en varias compañías: hoy es Cloudflare, que promete deshacerse de sus datos en 24 horas, y Google, que tiene la intención de guardar y monetizar todos los detalles de todo lo que ha planeado hacer.
El DNS y la privacidad son temas importantes, así que profundicemos en los detalles.
Servidor DNS y confianza
El concepto de un sistema de nombres de dominio se remonta a
ARPANET , cuando el único archivo de texto en cada nodo de ARPANET, bajo el nombre HOSTS.TXT, contenía toda la correspondencia entre los nombres de los sistemas conectados a ARPANET y sus direcciones digitales. Cuando rellenó este archivo usted mismo, fue fácil verificar que era correcto. Con el crecimiento de la red, se hizo poco realista mantener copias centrales y locales de estos archivos. A principios de la década de 1980, los intentos ya habían comenzado a crear un sistema de automatización para este proceso.
El primer servidor de nombres (Berkeley Internet Name Domain Server o BIND) fue escrito en 1984 por un grupo de estudiantes de la Universidad de California, Berkeley, basado en RFC 882 y RFC 883. En 1987, el estándar DNS fue revisado varias veces, lo que llevó al advenimiento de RFC 1034 y RFC 1035 que desde entonces en general no han cambiado.
La base de la estructura DNS es su estructura de árbol, donde los nodos y las hojas se dividen en zonas. La zona raíz DNS es el nivel superior, que consta de trece grupos de servidores raíz que forman los servidores DNS raíz oficiales. Cualquier servidor DNS nuevo (creado por un proveedor o empresa) recibe registros DNS de al menos uno de estos servidores primarios.
Cada zona DNS posterior agrega otro dominio al sistema de nombres. Por lo general, cada país mantiene sus propios dominios, y los dominios .org o .com que no están asociados con países se sirven por separado. Una consulta para un nombre de host a través de DNS comienza con un nombre de dominio (por ejemplo, .com), luego con un nombre (por ejemplo, google), seguido de posibles subdominios. Si los datos aún no se han almacenado en caché, es posible que deba realizar varias transiciones a través de las zonas DNS para resolver la solicitud.
DNSSEC: agregando confianza al sistema DNS
Antes de proceder al cifrado de las consultas DNS, debe asegurarse de que podamos confiar en el servidor DNS. Esta necesidad se hizo evidente en la década de 1990 y condujo a las primeras extensiones operativas del Estándar de Seguridad de DNS (DNSSEC), RFC 2353 y el RFC 4033 revisado (DNSSEC-bis).
Mapa de internet 2006DNSSEC funciona mediante la firma de registros de consultas DNS con una clave pública. La autenticidad del registro DNS se puede confirmar con las claves públicas de la zona raíz DNS, que es un tercero confiable en este escenario. Los propietarios de dominios generan sus claves, firmadas por operadores de zona y agregadas al DNS.
Aunque DNSSEC le permite estar relativamente seguro de que las respuestas del servidor DNS son reales, este protocolo debe incluirse en el sistema operativo. Desafortunadamente, pocos sistemas operativos implementan un servicio DNS que puede hacer más que simplemente "saber sobre DNSSEC", es decir, en realidad no confirman las respuestas DNS. Por lo tanto, hoy no puede estar seguro de que las respuestas que recibe de DNS son reales.
Problema con DoH
Supongamos que está utilizando DNSSEC. Está listo para cifrar mensajes para agregar privacidad a su transferencia de datos. Puede haber muchas razones para mantener en secreto las consultas DNS de miradas indiscretas. Entre los más inocentes se encuentran eludir los filtros de la corporación y los proveedores, prohibir el monitoreo de los hábitos de Internet y más. Entre los más serios están los intentos de evitar la persecución por parte del gobierno por expresar opiniones políticas en Internet. Naturalmente, el cifrado de consultas DNS no permite a las personas espiar estas consultas, pero como resultado, se ignoran los problemas más grandes con la seguridad de DNS y, por supuesto, todos los demás protocolos de comunicación.
Los principales competidores aquí son DoT usando TLS y DoH usando HTTPS. La diferencia más obvia entre los dos es el puerto: DoT se ejecuta en un puerto TCP dedicado 853, y DoH se mezcla con otro tráfico HTTPS en el puerto 443. Esto brinda la ventaja controvertida de hacer que las consultas DNS no se puedan distinguir de otro tráfico, lo que hace que sea imposible para los operadores de red (privados y corporativos) ) asegure su propia red, como Paul Vixie, uno de los arquitectos de DNS,
anunció en Twitter el año pasado.
La segunda de las principales diferencias es que si DoT simplemente envía consultas DNS a través de TLS, entonces DoH es esencialmente DNS sobre HTTP sobre TLS, requiere su propia aplicación de tipo de medios / mensaje dns y hace las cosas mucho más complicadas. La combinación de DoH con los protocolos existentes hace que cada consulta y respuesta DNS atraviese la pila HTTPS. Esto es una pesadilla para las aplicaciones integradas y también es incompatible con casi todos los tipos de equipos existentes.
DoT tiene otra ventaja: este protocolo ya se ha implementado y, mucho más tiempo que el DoH, lo utilizan compañías como Cloudflare, Google y proveedores locales de Internet; El software de servidor estándar como BIND utiliza DoT desde el primer momento. En Android Pie OS (versión 9), se
utilizará DNS sobre TLS
de forma predeterminada si el servidor DNS seleccionado admite DoT.
¿Por qué cambiar a DoH si DoT ya se está implementando? Si las aplicaciones no estándar como Firefox omiten el DNS del sistema basado en DoT y usan su propio sistema de recuperación de nombres de dominio a través de DoH, entonces esta situación se volverá muy difícil desde el punto de vista de la seguridad. Transferir DNS a aplicaciones individuales, lo que está sucediendo ahora, parece un paso atrás. ¿Sabes qué método DNS utiliza cada aplicación? ¿Sabes que combina este proceso con el tráfico TCP en el puerto 443?
El cifrado no interfiere con la inspección
Dos grandes empresas, Cloudflare y Mozilla, representan DNS a través de HTTPS, y esta última incluso lanzó una
pequeña tira cómica , donde trata de explicar el esquema DoH. Como era de esperar, no mencionan DNSSEC en absoluto (a pesar de que se llama "crítico" en RFC 8484), y en su lugar ofrecen algo llamado Trusted Recursive Resolver (TRR), que esencialmente representa el consejo "use Trusted Servidor DNS ”por el cual Mozilla significa Cloudflare.
Además de DoH, mencionan el estándar de minimización QNAME (
RFC 7816 ), que debería
reducir la cantidad de información no crítica enviada por el servidor DNS. Al mismo tiempo, este estándar no depende de DoH de ninguna manera y funcionará sin ningún cifrado DNS. Al igual que con DNSSEC, la seguridad y la privacidad se mejoran a través de la evolución del estándar DNS.
Lo más interesante se encuentra en la sección "¿Qué no soluciona TRR + DoH"? Como muchos expertos han dicho, el cifrado de DNS no evita la indagación. Cualquier solicitud posterior a la dirección IP que se recibió de una manera terriblemente secreta seguirá siendo claramente visible. De todos modos, sabrán que ha visitado Facebook.com o el sitio para disidentes. Ningún cifrado de DNS o tráfico de Internet ocultará información vital para el funcionamiento de una red como Internet.
¿El futuro Internet se convertirá en un único punto de falla?
Mozilla ofrece lidiar con el problema de la inspección de IP simplemente afirmando que esto no es un problema a través del uso de la nube. Cuanto más sitios web y redes de distribución de contenido (CDN) se cuelguen de una pequeña cantidad de servicios (Cloudflare, Azure, AWS, etc.), menos significa esta única dirección IP: solo necesita creer que la elegida su servicio en la nube no robará sus datos y no caerá por un día.
Este año, 24 de junio, hubo una caída masiva en los servicios, cuando un error de configuración cometido por el proveedor de Verizon hizo que Cloudflare, Amazon, Linode y muchos otros no estuvieran disponibles durante la mayor parte del día. El 2 de julio de este año
, Cloudflare cayó durante aproximadamente media hora, y con él muchos sitios web que dependen de sus servicios.
Casualmente, el servicio en la nube Office365 de Microsoft también permaneció durante varias horas ese día, por lo que muchos usuarios no pudieron usar sus servicios. El fin de semana anterior al Día del Trabajo [feriado nacional de los Estados Unidos celebrado el primer lunes de septiembre / aprox. trans.] falla de energía en el centro de datos AWS US-East-1 condujo a un terabyte de datos de clientes almacenados allí
cubiertos con una cuenca de cobre . Obviamente, todavía hay algunos inconvenientes en la idea de los beneficios de centralizar Internet.
Viejas canciones de una nueva manera
Sorprendentemente, no se menciona ninguna red privada virtual (VPN) en esta discusión sobre privacidad y seguimiento. Resuelven problemas con el cifrado de datos y las consultas DNS, ocultando la dirección IP y más, simplemente moviendo el punto en el que su PC u otro dispositivo conectado a Internet se conecta a Internet. Los disidentes dentro de los regímenes autoritarios han usado VPN durante décadas para eludir la censura de Internet; Las VPN, que incluyen características especiales como Tor, son un elemento crítico de la libertad de Internet.
¿Cómo funciona Tor?Si confía en una gran empresa comercial como Cloudflare en un esquema como DoH, entonces será fácil encontrar un proveedor de VPN confiable que no almacene ni venda sus datos. Y el navegador Opera generalmente tiene soporte proxy integrado gratuito, que ofrece
muchos beneficios de VPN .
Al final, podemos decir que DoH confirma su acrónimo, haciendo mal que DoT ya lo está haciendo bien ["Doh!" - una exclamación que indica la estupidez de una acción perfecta, especialmente la propia / aprox. transl.]. Necesitamos centrarnos más en la implementación ubicua de DNSSEC, junto con DoT y minimizar QNAME. Y si te importa la privacidad real, entonces debes recurrir a una VPN.