Cifrado de DNS explicado

Con Windows 11, Microsoft ha habilitado la función DOH nuevamente, y los usuarios pueden comenzar a probarlo nuevamente si actualmente están utilizando servidores DNS de Cloudflare, Google o Quad9.

Descripción general del DNS

El sistema de nombres de dominio es la ‘portada de Internet’. DNS traduce los nombres de dominio a las direcciones IP para que los navegadores y otros servicios puedan cargar recursos de Internet, a través de una red descentralizada de servidores.

Que es DNS ?¶

Cuando visita un sitio web, se devuelve una dirección numérica. Por ejemplo, cuando visita PrivacyGuides.org, la dirección 192.98.54.105 se devuelve.

DNS ha existido desde los primeros días de Internet. Las solicitudes DNS hechas hacia y desde los servidores DNS son no generalmente encriptado. En un entorno residencial, el ISP le da servidores a un cliente a través de DHCP.

Las solicitudes de DNS no encriptadas pueden ser fácilmente vigilado y modificado En tránsito. En algunas partes del mundo, se ordena que los ISP se filtren DNS primitivo. Cuando solicita la dirección IP de un dominio bloqueado, el servidor no puede responder o puede responder con una dirección IP diferente. Como el protocolo DNS no está encriptado, el ISP (o cualquier operador de red) puede usar DPI para monitorear las solicitudes. Los ISP también pueden bloquear las solicitudes basadas en características comunes, independientemente de qué servidor DNS se utilice. DNS sin cifrar siempre usa el puerto 53 y siempre usa UDP .

A continuación, discutimos y proporcionamos un tutorial para demostrar lo que un observador externo puede ver utilizando DNS sin cifrar regularmente y DNS cifrados .

DNS sin cifrar ¶

1. Usando Tshark (parte del proyecto Wireshark) podemos monitorear y registrar el flujo de paquetes de Internet. Este comando registra paquetes que cumplen con las reglas especificadas:

Tshark -W /TMP /DNS.puerto UDP PCAP 53 y anfitrión 1.1.1.1 o anfitrión 8.8.8.8 

Linux, MacOS Windows

DIG +NOALL +Respuesta PrivacyGuides.org @1.1.1.1 Dig +Noall +Respuesta PrivacyGuides.org @8.8.8.8 

nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 

Wireshark Tshark

wireshark -r /tmp /dns.PCAP 

tshark -r /tmp /dns.PCAP 

Si ejecuta el comando wireshark anterior, el panel superior muestra los “marcos”, y el panel inferior muestra todos los datos sobre el marco seleccionado. Las soluciones de filtrado y monitoreo empresarial (como las compradas por los gobiernos) pueden hacer el proceso automáticamente, sin interacción humana, y pueden agregar esos cuadros para producir datos estadísticos útiles para el observador de la red.

No.	Tiempo	Fuente	Destino	Protocolo	Longitud	Información
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Consulta estándar 0x58ba A privacyguides.organizar
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Respuesta de consulta estándar 0x58BA A PrivacyGuides.org a 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Consulta estándar 0xf1a9 A privacyguides.organizar
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Respuesta de consulta estándar 0xf1a9 A PrivacyGuides.org a 198.98.54.105 OPT

Un observador podría modificar cualquiera de estos paquetes.

¿Qué es “DNS cifrado”??¶

DNS cifrado puede referirse a uno de varios protocolos, los más comunes son:

Dnsncrypt¶

Dnscrypt fue uno de los primeros métodos para encriptar las consultas DNS. DNSCRYPT funciona en el puerto 443 y funciona con los protocolos de transporte TCP o UDP. DNSCRYPT nunca se ha enviado a la Fuerza de Tarea de Ingeniería de Internet (IETF) ni ha pasado por el proceso de Solicitud de Comentarios (RFC), por lo que no se ha utilizado ampliamente fuera de algunas implementaciones. Como resultado, ha sido reemplazado en gran medida por el DNS más popular sobre HTTPS .

DNS sobre TLS (DOT) ¶

DNS sobre TLS es otro método para encriptar la comunicación DNS que se define en RFC 7858. El soporte se implementó por primera vez en Android 9, iOS 14 y en Linux en DOT a DOH en los últimos años, ya que DOT es un protocolo complejo y tiene un cumplimiento variable para el RFC en las implementaciones que existen. Dot también funciona en un puerto dedicado 853 que puede bloquearse fácilmente por firewalls restrictivos.

DNS sobre https (doh) ¶

DNS sobre https Como se define en las consultas de paquetes RFC 8484 en el protocolo HTTP /2 y proporciona seguridad HTTPS . El soporte se agregó por primera vez en navegadores web como Firefox 60 y Chrome 83.

La implementación nativa de DOH apareció en iOS 14, MacOS 11, Microsoft Windows y Android 13 (sin embargo, no se habilitará de forma predeterminada). El soporte general de escritorio de Linux está esperando la implementación de Systemd, por lo que aún se requiere instalar software de terceros.

¿Qué puede ver una fiesta externa??¶

En este ejemplo, grabaremos lo que sucede cuando realicemos una solicitud de DOH:

Primero, comienza Tshark:

Tshark -W /TMP /DNS_DOH.PCAP -F "Puerto TCP HTTPS y Host 1.1.1.1 " 

curl -vi --doh -url https: // 1.1.1.1/dns-query https: // privacyguides.organizar 

wireshark -r /tmp /dns_doh.PCAP 

Podemos ver el establecimiento de conexión y el apretón de manos TLS que ocurre con cualquier conexión cifrada. Al observar los paquetes de “datos de la aplicación” que siguen, ninguno de ellos contiene el dominio que solicitamos o devuelve la dirección IP.

Por qué no debería Yo uso DNS cifrado ?¶

En ubicaciones donde hay filtrado de Internet (o censura), visitar los recursos prohibidos puede tener sus propias consecuencias que debe considerar en su modelo de amenaza. Hacemos no Sugerir el uso de DNS cifrados para este propósito. Use Tor o una VPN en su lugar. Si está utilizando una VPN, debe usar los servidores DNS de su VPN. Al usar una VPN, ya está confiando en ellos con toda su actividad de red.

Cuando hacemos una búsqueda DNS, generalmente es porque queremos acceder a un recurso. A continuación, discutiremos algunos de los métodos que pueden revelar sus actividades de navegación incluso cuando se use DNS cifrado:

Dirección IP¶

La forma más sencilla de determinar la actividad de navegación podría ser ver las direcciones IP a sus dispositivos están accediendo. Por ejemplo, si el observador sabe que privacyguides.org está en 198.98.54.105, y su dispositivo solicita datos de 198.98.54.105, hay una buena posibilidad de que visite guías de privacidad.

Este método solo es útil cuando la dirección IP pertenece a un servidor que solo aloja pocos sitios web. Tampoco es muy útil si el sitio está alojado en una plataforma compartida (e.gramo. Páginas de Github, Páginas de CloudFlare, Netlify, WordPress, Blogger, etc.). Tampoco es muy útil si el servidor está alojado detrás de un proxy inverso, que es muy común en la Internet moderna.

Indicación del nombre del servidor (SNI) ¶

La indicación del nombre del servidor generalmente se usa cuando una dirección IP aloja muchos sitios web. Este podría ser un servicio como CloudFlare, o algún otro ataque de ataque de denegación de servicio.

Empiece a capturar nuevamente con Tshark . Hemos agregado un filtro con nuestra dirección IP para que no capture muchos paquetes:

Tshark -W /TMP /PG.puerto de PCAP 443 y anfitrión 198.98.54.105 

Wireshark -R /TMP /PG.PCAP 

▸ Seguridad de la capa de transporte ▸ TLSV1.3 Capa de registro: Protocolo de apretón de manos: Hello cliente ▸ Protocolo de apretón de manos: Hello cliente ▸ Extensión: server_name (len = 22) ▸ Nombre del servidor Indicación Extensión de extensión 

tshark -r /tmp /pg.PCAP -TFIELDS -Y TLS.apretón de manos.extensions_server_name -e TLS.apretón de manos.extensiones_server_name 

Esto significa que incluso si estamos utilizando servidores “DNS cifrados”, el dominio probablemente se revelará a través de SNI . El TLS V1.3 Protocolo trae consigo Hello de cliente cifrado, lo que evita este tipo de fuga.

Los gobiernos, en particular China y Rusia, ya han comenzado a bloquearlo o expresaron el deseo de hacerlo. Recientemente, Rusia ha comenzado a bloquear sitios web extranjeros que usan el estándar HTTP /3. Esto se debe a que el protocolo QUIC que forma parte de http /3 requiere que el cliente también se encripte.

Protocolo de estado del certificado en línea (OCSP) ¶

Otra forma en que su navegador puede revelar sus actividades de navegación es con el protocolo de estado del certificado en línea. Al visitar un sitio web HTTPS, el navegador podría verificar si el certificado del sitio web ha sido revocado. Esto generalmente se hace a través del protocolo HTTP, lo que significa que es no encriptado.

La solicitud OCSP contiene el “número de serie” del certificado, que es único. Se envía al “respondedor OCSP” para verificar su estado.

Podemos simular lo que haría un navegador usando el comando OpenSSL.

Obtenga el certificado del servidor y use SED para mantener solo la parte importante y escríbelo en un archivo:

openssl s_client -connect privacyguides.org: 443 /dev /null 2>Y1 | SED -N '/^-*begin/,/^-*end/p' > /tmp /pg_server.certificado 

openssl s_client -showcerts -connect privacyguides.org: 443 /dev /null 2>Y1 | SED -N '/^-*begin/,/^-*end/p' > /tmp /pg_and_intermediate.certificado 

SED -N '/^-*Certificado final-*$/!d;: a n; p; ba ' \ /tmp/pg_and_intermediate.cert> /tmp /intermediate_chain.certificado 

OPENSSL X509 -NOOUT -OCSP_URI -IN /TMP /PG_SERVER.certificado 

Nuestro certificado muestra el respondedor del certificado de encrypt. Si queremos ver todos los detalles del certificado que podemos usar:

OpenSSL x509 -Text -NOOUT -In /TMP /PG_SERVER.certificado 

Tshark -W /TMP /PG_OCSP.PCAP -F "Puerto TCP HTTP" 

OpenSSL OCSP -Issuer /TMP /Intermediate_Chain.certificado \ -CERT /TMP /PG_SERVER.certificado \ -texto \ -url http: // r3.O.lencr.organizar 

wireshark -r /tmp /pg_ocsp.PCAP 

Habrá dos paquetes con el protocolo “OCSP”: una “solicitud” y una “respuesta”. Para la “solicitud” podemos ver el “número de serie” expandiendo el triángulo ▸ al lado de cada campo:

▸ Protocolo de estado del certificado en línea ▸ 1 Artículo ▸ Solicitud ▸ ReqCert SerialNumber 

Para la “respuesta” también podemos ver el “número de serie”:

▸ Protocolo de estado del certificado en línea ▸ Respuesta Bytes ▸ BASICOCSPRESENSE ▸ TBBSRESSEDATA ▸ Respuestas: 1 Artículo ▸ SinglerEponse ▸ Certid SerialNumber 

tshark -r /tmp /pg_ocsp.PCAP -TFIELDS -Y OCSP.SerialNumber -E OCSP.número de serie 

Si el observador de la red tiene el certificado público, que está disponible públicamente, puede igualar el número de serie con ese certificado y, por lo tanto, determinar el sitio que está visitando desde eso. El proceso puede ser automatizado y puede asociar direcciones IP con números de serie. También es posible verificar los registros de transparencia del certificado para el número de serie.

¿Debo usar DNS cifrado? ?¶

Hicimos este diagrama de flujo para describir cuando debería Use DNS cifrado:

Graph TB Start [inicio] -> Anónimo Anónimo?> Anónimo-> | SÍ | tor (use tor) Anónimo -> | No | censura de censura?> Censura -> | SÍ | VPNORTOR (use 
VPN o tor) Censura -> | No | privacidad de ISP?> Privacidad -> | SÍ | VPNORTOR Privacidad -> | No | desagradable desagradable 
redireccionamiento?> desagradable -> | SÍ | cifrado en cifrado (use 
DNS encriptado 
con un tercero) desagradable -> | No | ISPDNS DNS cifrado?> ISPDNS -> | SÍ | useisp (use 
DNS encriptado 
con isp) ispdns -> | No | nada (no hacer nada)

DNS cifrado con un tercero solo debe usarse para redirigir y bloquear DNS básicos cuando puede estar seguro de que no habrá ninguna consecuencia o está interesado en un proveedor que realice un filtrado rudimentario.

Que es dnssec ?¶

Extensiones de seguridad del sistema de nombre de dominio (DNSSEC) es una característica de DNS que autentica las respuestas a las búsquedas de nombres de dominio. No proporciona protecciones de privacidad para esas búsquedas, sino que evita que los atacantes manipulen o envenenen las respuestas a las solicitudes de DNS.

En otras palabras, DNSSEC firma datos digitalmente para ayudar a garantizar su validez. Para garantizar una búsqueda segura, la firma ocurre en todos los niveles del proceso de búsqueda DNS. Como resultado, se pueden confiar en todas las respuestas de DNS.

El proceso de firma de DNSSEC es similar a que alguien firme un documento legal con un bolígrafo; Esa persona firma con una firma única que nadie más puede crear, y un experto en la corte puede ver esa firma y verificar que el documento fue firmado por esa persona. Estas firmas digitales aseguran que los datos no hayan sido manipulados.

DNSSEC implementa una política de firma digital jerárquica en todas las capas de DNS . Por ejemplo, en el caso de una privacidad de guías.Buscar en la búsqueda, un servidor DNS raíz firmaría una clave para el .org de nombres servidores, y el .Org NamesServer firmaría una clave para PrivacyGuides.El servidor de nombres autorizado de Org.

¿Qué es la minimización de Qname??¶

Un Qname es un “nombre calificado”, por ejemplo, PrivacyGuides.organizar . La minimización de QName reduce la cantidad de información enviada desde el servidor DNS al servidor de nombres autorizados.

En lugar de enviar las guías de privacidad de dominio completa.org, Qname Minimization significa que el servidor DNS solicitará todos los registros que terminan en .organizar . Se define una descripción técnica adicional en RFC 7816.

¿Qué es la subred de cliente EDNS (ECS)??¶

La subred de cliente EDNS es un método para un resolución de DNS recursivo para especificar una subred para el host o el cliente que está haciendo la consulta DNS.

Tiene la intención de “acelerar” la entrega de datos al darle al cliente una respuesta que pertenece a un servidor que está cerca de ellos, como una red de entrega de contenido, que a menudo se usa en la transmisión de video y el servicio de aplicaciones web de JavaScript.

Esta característica tiene un costo de privacidad, ya que le dice al servidor DNS información sobre la ubicación del cliente.

Guías de privacidad es un sitio web sin fines de lucro y motivado socialmente que proporciona información para proteger su seguridad y privacidad de datos.
No ganamos dinero recomendando ciertos productos, y no utilizamos enlaces de afiliados.
© 2019 – 2023 Guías de privacidad y contribuyentes.

Cifrado de DNS explicado

El sistema de nombres de dominio (DNS) es la libreta de direcciones de Internet. Cuando visita Cloudflare.com o cualquier otro sitio, su navegador le pedirá a un resolución de DNS la dirección IP donde se puede encontrar el sitio web. Desafortunadamente, estas consultas y respuestas DNS generalmente no están protegidas. Cifrar DNS mejoraría la privacidad y la seguridad del usuario. En esta publicación, analizaremos dos mecanismos para encriptar DNS, conocido como DNS sobre TLS (DOT) y DNS sobre HTTPS (DOH), y explicar cómo funcionan.

Las aplicaciones que desean resolver un nombre de dominio en una dirección IP generalmente usan DNS. Esto generalmente no lo hace explícitamente por el programador que escribió la aplicación. En cambio, el programador escribe algo como Fetch (“https: // ejemplo.com/News “) y espera que una biblioteca de software maneje la traducción de” Ejemplo.com ”a una dirección IP.

Detrás de escena, la biblioteca de software es responsable de descubrir y conectarse al resolutor DNS recursivo externo y hablar el protocolo DNS (consulte la figura a continuación) para resolver el nombre solicitado por la aplicación. La elección del resolución DNS externo y si se proporciona privacidad y seguridad está fuera del control de la aplicación. Depende de la biblioteca de software en uso y las políticas proporcionadas por el sistema operativo del dispositivo que ejecuta el software.

El resolución DNS externo

El sistema operativo generalmente aprende la dirección de resolución de la red local utilizando el Protocolo de configuración de host dinámico (DHCP). En las redes domésticas y móviles, generalmente termina utilizando el resolución del proveedor de servicios de Internet (ISP). En las redes corporativas, el resolución seleccionado suele ser controlado por el administrador de la red. Si lo desea, los usuarios con control sobre sus dispositivos pueden anular el resolución con una dirección específica, como la dirección de un resolutor público como los 8 de Google.8.8.8 o Cloudflare 1.1.1.1, pero la mayoría de los usuarios probablemente no se molesten en cambiarlo cuando se conectan a un punto de acceso Wi-Fi público en una cafetería o aeropuerto.

La elección del resolución externa tiene un impacto directo en la experiencia del usuario final. La mayoría de los usuarios no cambian su configuración de resolución y probablemente terminarán utilizando el resolución de DNS desde su proveedor de red. La propiedad observable más obvia es la velocidad y precisión de la resolución de nombre. Las características que mejoran la privacidad o la seguridad pueden no ser visibles de inmediato, pero ayudarán a evitar que otros se perfilen o interfieran con su actividad de navegación. Esto es especialmente importante en las redes de Wi-Fi públicas donde cualquier persona en proximidad física puede capturar y descifrar el tráfico de la red inalámbrica.

DNS sin cifrar

Desde que se creó DNS en 1987, ha sido en gran medida sin cifrar. Todos entre su dispositivo y el resolutor pueden husmear o incluso modificar sus consultas y respuestas DNS. Esto incluye a cualquier persona en su red Wi-Fi local, su proveedor de servicios de Internet (ISP) y proveedores de tránsito. Esto puede afectar su privacidad revelando los nombres de dominio que están visitando.

Que pueden ver? Bueno, considere esta captura de paquetes de red tomada de una computadora portátil conectada a una red doméstica:

Se pueden hacer las siguientes observaciones:

• El puerto de origen UDP es 53, que es el número de puerto estándar para DNS sin cifrar. Por lo tanto, es probable que la carga útil de UDP sea una respuesta DNS.
• Eso sugiere que la dirección IP de origen 192.168.2.254 es un resolución de DNS, mientras que el destino IP 192.168.2.14 es el cliente DNS.
• La carga útil de UDP podría analizarse como una respuesta DNS y revela que el usuario estaba tratando de visitar Twitter.comunicarse.
• Si hay conexiones futuras con 104.244.42.129 o 104.244.42.1, entonces probablemente sea el tráfico que se dirige a “Twitter.com “.
• Si hay más tráfico HTTPS cifrado a esta IP, que tiene éxito por más consultas DNS, podría indicar que un navegador web cargó recursos adicionales de esa página. Eso podría revelar las páginas que un usuario estaba mirando mientras visitaba Twitter.comunicarse.

Dado que los mensajes DNS no están protegidos, otros ataques son posibles:

• Las consultas podrían dirigirse a un resolución que realiza secuestro de DNS. Por ejemplo, en el Reino Unido, Virgin Media y BT devuelven una respuesta falsa para los dominios que no existen, redirigiendo a los usuarios a una página de búsqueda. Esta redirección es posible porque la computadora/teléfono confía ciegamente en el resolución DNS que fue anunciado usando DHCP por el enrutador de puerta de enlace proporcionado por ISP.
• Los firewalls pueden interceptar, bloquear o modificar fácilmente cualquier tráfico DNS sin cifrar en función del número de puerto solo. Vale la pena señalar que la inspección de texto sin formato no es una bala de plata para lograr los objetivos de visibilidad, porque el resolutor del DNS se puede pasar por alto.

DNS encriptando

Cifrar DNS hace que sea mucho más difícil para los fisoteros examinar sus mensajes DNS o corromperlos en tránsito. Al igual que la web pasó de HTTP sin cifrar a HTTP encriptados, ahora hay actualizaciones al protocolo DNS que cifra DNS en sí mismo. Cifrar la web ha hecho posible que florezcan las comunicaciones y el comercio privados y seguros. Cifrar DNS mejorará aún más la privacidad del usuario.

Existen dos mecanismos estandarizados para asegurar el transporte de DNS entre usted y el resolución, DNS sobre TLS (2016) y consultas DNS sobre HTTPS (2018). Ambos se basan en la seguridad de la capa de transporte (TLS) que también se utiliza para asegurar la comunicación entre usted y un sitio web utilizando HTTPS. En TLS, el servidor (ya sea un servidor web o resolución de DNS) se autentica al cliente (su dispositivo) utilizando un certificado. Esto asegura que ninguna otra parte pueda hacerse pasar por el servidor (el resolución).

Con DNS sobre TLS (DOT), el mensaje DNS original está directamente integrado en el canal TLS seguro. Desde el exterior, uno no puede aprender el nombre que se estaba consultando ni modificarlo. La aplicación cliente prevista podrá descifrar TLS, se ve así:

En el rastreo de paquetes para DNS no encriptado, estaba claro que el cliente puede enviar directamente una solicitud DNS, seguida de una respuesta DNS desde el resolución. Sin embargo, en el caso DOT cifrado, algunos mensajes de apretón de manos TLS se intercambian antes de enviar mensajes DNS cifrados:

• El cliente envía a un cliente hola, anunciando sus capacidades TLS compatibles.
• El servidor responde con un servidor hola, de acuerdo en los parámetros TLS que se utilizarán para asegurar la conexión. El mensaje de certificado contiene la identidad del servidor, mientras que el mensaje de verificación del certificado contendrá una firma digital que el cliente puede verificar el certificado del servidor. El cliente generalmente verifica este certificado en su lista local de autoridades de certificado de confianza, pero la especificación del DOT menciona mecanismos de confianza alternativos, como la fijación de clave pública.
• Una vez que el cliente y el servidor finalizan el TLS Handshake, finalmente puede comenzar a intercambiar mensajes encriptados.
• Mientras que la imagen de arriba contiene una consulta y respuesta DNS, en la práctica la conexión TLS segura permanecerá abierta y se reutilizará para futuras consultas DNS.

Asegurar protocolos no certificados al abofetear TLS sobre un nuevo puerto se ha realizado antes:

• Tráfico web: http (TCP/80) -> https (TCP/443)
• Envío de correo electrónico: SMTP (TCP/25) -> SMTPS (TCP/465)
• Correo electrónico de recepción: IMAP (TCP/143) -> IMAPS (TCP/993)
• Ahora: DNS (TCP/53 o UDP/53) -> DOT (TCP/853)

Un problema con la introducción de un nuevo puerto es que los firewalls existentes pueden bloquearlo. Ya sea porque emplean un enfoque de la lista de algodines donde los nuevos servicios deben estar habilitados explícitamente, o un enfoque de lista de bloques donde un administrador de red bloquea explícitamente un servicio. Si es menos probable que la opción segura (DOT) esté disponible que su opción insegura, entonces los usuarios y las aplicaciones pueden verse tentados a tratar de volver a recurrir a DNS sin cifrar. Posteriormente, esto podría permitir a los atacantes obligar a los usuarios a una versión insegura.

Tales ataques de respuesta no son teóricos. La extracción de SSL se ha utilizado previamente para rebajar los sitios web de HTTPS a HTTP, lo que permite a los atacantes robar contraseñas o cuentas de secuestro.

Otro enfoque, DNS consultas sobre HTTPS (DOH), fue diseñado para admitir dos casos de uso principales:

• Prevenir el problema anterior donde interfieren los dispositivos en vía con DNS. Esto incluye el problema de bloqueo de puertos arriba.
• Habilite las aplicaciones web para acceder a DNS a través de las API existentes del navegador.
  DOH es esencialmente HTTPS, el mismo estándar encriptado que usa la web y reutiliza el mismo número de puerto (TCP/443). Los navegadores web ya tienen HTTP no seguro a favor de HTTPS. Eso hace que HTTPS sea una excelente opción para transportar de forma segura los mensajes DNS. Se puede encontrar un ejemplo de dicha solicitud de DOH aquí.

A algunos usuarios les ha preocupado el uso de HTTPS podría debilitar la privacidad debido al uso potencial de cookies para el seguimiento de. Los diseñadores de protocolo DOH consideraron varios aspectos de privacidad y el uso explícitamente desanimado de las cookies HTTP para evitar el seguimiento, una recomendación ampliamente respetada. La reanudación de la sesión de TLS mejora el TLS 1.2 rendimiento del apretón de manos, pero potencialmente se puede usar para correlacionar las conexiones TLS. Afortunadamente, el uso de TLS 1.3 obvia la necesidad de la reanudación de la sesión de TLS reduciendo el número de viajes redondos de forma predeterminada, abordando efectivamente su preocupación de privacidad asociada.

El uso de HTTPS significa que las mejoras en el protocolo HTTP también pueden beneficiar a DOH. Por ejemplo, el protocolo HTTP/3 en desarrollo, basado en la CASC, podría ofrecer mejoras de rendimiento adicionales en presencia de pérdida de paquetes debido a la falta de bloqueo del cabecera de línea. Esto significa que múltiples consultas DNS podrían enviarse simultáneamente a través del canal seguro sin bloquearse cuando se pierde un paquete.

También existe un borrador para DNS sobre Quic (DNS/Quic) y es similar al DOT, pero sin el problema de bloqueo del Jefe de línea debido al uso de Quic. Sin embargo, tanto HTTP/3 como DNS/Quic requieren que sea accesible un puerto UDP. En teoría, ambos podrían recurrir a DOH sobre HTTP/2 y DOT respectivamente.

Despliegue de DOT y DOH

Como DOT y DOH son relativamente nuevos, aún no se implementan universalmente. En el lado del servidor, los principales resueltos públicos, incluido el 1 de Cloudflare.1.1.1 y Google DNS lo admiten. Sin embargo, muchos resolventes de ISP aún carecen de soporte para ello. Se puede encontrar una pequeña lista de resolentes públicos que apoyan el DOH en las fuentes del servidor DNS, se puede encontrar otra lista de resueltos públicos que apoyan DOT y DOH en DNS Privacy Public Resolvers.

Hay dos métodos para habilitar DOT o DOH en dispositivos de usuario final:

• Agregue soporte a las aplicaciones, evitando el servicio de resolución desde el sistema operativo.
• Agregar soporte al sistema operativo, proporcionando transparentemente soporte a las aplicaciones.

Generalmente hay tres modos de configuración para DOT o DOH en el lado del cliente:

• APAGADO: DNS no estará encriptado.
• Modo oportunista: trate de usar un transporte seguro para DNS, pero el DNS de retroceso a no encriptado si el primero no está disponible. Este modo es vulnerable a los ataques de degradación donde un atacante puede obligar a un dispositivo a usar DNS sin cifrar. Su objetivo es ofrecer privacidad cuando no hay atacantes activos en la ruta.
• Modo estricto: intente usar DNS a través de un transporte seguro. Si no está disponible, falla duro y muestra un error al usuario.

El estado actual para la configuración de DNS en todo el sistema a través de un transporte seguro:

• Android 9: Admite DOT a través de su función “DNS privado”. Modos:
  • El modo oportunista (“automático”) se usa de forma predeterminada. Se utilizará el resolución de la configuración de red (típicamente DHCP).
  • El modo estricto se puede configurar configurando un nombre de host explícito. No se permite la dirección IP, el nombre de host se resuelve utilizando el resolución predeterminado y también se usa para validar el certificado. (Código fuente relevante)

  Los navegadores web admiten DOH en lugar de DOT:

  • Firefox 62 admite DOH y proporciona varias configuraciones de resolución recursiva (TRR) de confianza. Por defecto, DOH está deshabilitado, pero Mozilla está ejecutando un experimento para habilitar DOH para algunos usuarios en los EE. UU. Este experimento utiliza actualmente el 1 de Cloudflare.1.1.1 resolución, ya que somos el único proveedor que actualmente satisface la política de resolución estricta requerida por Mozilla. Dado que muchos resonedores de DNS aún no admiten un transporte DNS cifrado, el enfoque de Mozilla asegurará que más usuarios estén protegidos utilizando DOH.
    • Cuando se habilita a través del experimento, o a través de la opción “Habilitar DNS sobre HTTPS” en la configuración de red, Firefox utilizará el modo oportunista (red.TRR.modo = 2 en aproximadamente: config).
    • El modo estricto se puede habilitar con la red.TRR.MODE = 3, pero requiere que se especifique una IP de resolución explícita (por ejemplo, red.TRR.bootstrapaddress = 1.1.1.1).
    • Mientras que Firefox ignora el resolución predeterminado del sistema, se puede configurar con resoluciones alternativas. Además, las implementaciones empresariales que usan un resolución que no admite DOH tiene la opción de deshabilitar DOH.

    La página DNS sobre HTTPS del proyecto CURL tiene una lista completa de proveedores de DOH e implementaciones adicionales.

    Como alternativa para encriptar la ruta de red completa entre el dispositivo y el resolutor DNS externo, uno puede tomar un término medio: use DNS sin cifrar entre dispositivos y la puerta de enlace de la red local, pero cifre todo el tráfico de DNS entre el enrutador de la puerta de enlace y el externo Resolución de DNS. Suponiendo una red segura de cable o inalámbrica, esto protegería todos los dispositivos en la red local contra un ISP fiseo u otros adversarios en Internet. Como los puntos de acceso Wi-Fi público no se consideran seguros, este enfoque no sería seguro en las redes de Wi-Fi abiertas. Incluso si está protegido con contraseña con WPA2-PSK, otros aún podrán husmear y modificar DNS sin cifrar.

    Otras consideraciones de seguridad

    Las secciones anteriores describieron transportes DNS seguros, DOH y DOT. Estos solo asegurarán que su cliente reciba la respuesta no modificada del resolución DNS. Sin embargo, no protege al cliente contra el resolutor que devuelve la respuesta incorrecta (a través del secuestro de DNS o los ataques de envenenamiento de caché DNS). La respuesta “verdadera” está determinada por el propietario de un dominio o zona según lo informado por el servidor de nombres autorizados. DNSSEC permite a los clientes verificar la integridad de la respuesta DNS devuelta y atrapar cualquier manipulación no autorizada a lo largo de la ruta entre el cliente y el servidor de nombres autorizados.

    Sin embargo, el despliegue de DNSSEC se ve obstaculizado por las cajas de mediana. Un informe de 2016 encontró que solo el 26% de los usuarios usan resoluciones de validación DNSSEC.

    Doh y dot protegen el transporte entre el cliente y el resolutor público. El resolutor público puede tener que comunicarse con servidores de nombres autorizados adicionales para resolver un nombre. Tradicionalmente, la ruta entre cualquier resolución y el servidor de nombres autorizados utiliza DNS sin cifrar. Para proteger estos mensajes DNS también, hicimos un experimento con Facebook, usando DOT entre 1.1.1.1 y los servidores de nombres autorizados de Facebook. Si bien la configuración de un canal seguro que usa TLS aumenta la latencia, se puede amortizarse en muchas consultas.

    El cifrado de transporte asegura que los resultados y los metadatos del resolución estén protegidos. Por ejemplo, la información de la subred del cliente EDNS (ECS) incluida con las consultas DNS podría revelar la dirección del cliente original que inició la consulta DNS. Ocultar esa información a lo largo del camino mejora la privacidad. También evitará que las cajas intermedias rotas rompan DNSSEC debido a problemas en el reenvío de DNS.

    Problemas operativos con cifrado DNS

    El cifrado de DNS puede traer desafíos a las personas u organizaciones que dependen de monitorear o modificar el tráfico de DNS. Los aparatos de seguridad que dependen del monitoreo pasivo observan todo el tráfico de la red entrante y saliente en una máquina o en el borde de una red. Basado en consultas DNS no entrelazadas, podrían identificar máquinas que están infectadas con malware, por ejemplo,. Si la consulta DNS está encriptada, entonces las soluciones de monitoreo pasivo no podrán monitorear los nombres de dominio.

    Algunas partes esperan que los resonedores de DNS apliquen el filtrado de contenido para fines como:

    • Dominios de bloqueo utilizados para la distribución de malware.
    • Bloqueo de anuncios.
    • Realizar los dominios de filtrado de control de los padres, bloqueando los dominios asociados con el contenido de adultos.
    • Bloquear el acceso a dominios que sirven contenido ilegal de acuerdo con las regulaciones locales.
    • Ofrezca un DNS de horizonte dividido para proporcionar diferentes respuestas dependiendo de la red de origen.

    Una ventaja de bloquear el acceso a los dominios a través del resolución DNS es que se puede hacer centralmente, sin reimplementarlo en cada aplicación. Desafortunadamente, también es bastante grueso. Supongamos que un sitio web aloja contenido para múltiples usuarios con ejemplo.com/videos/for-kids/y ejemplo.com/videos/for-adults/. El resolución de DNS solo podrá ver “Ejemplo.com ”y puede elegir bloquearlo o no. En este caso, los controles específicos de la aplicación, como las extensiones del navegador, serían más efectivos, ya que en realidad pueden investigar las URL y evitar que sea accesible el contenido.

    El monitoreo de DNS no es integral. El malware podría omitir las direcciones IP DNS y Hardcode, o usar métodos alternativos para consultar una dirección IP. Sin embargo, no todo el malware es tan complicado, por lo que el monitoreo de DNS puede servir como una herramienta de defensa en profundidad.

    Todos estos casos de uso de monitoreo no pasivo o de bloqueo del DNS requieren soporte del resolutor DNS. Las implementaciones que dependen de las actualizaciones oportunistas de DOH/DOT del resolución actual mantendrán la misma característica establecida que generalmente se proporciona sobre DNS sin cifrar. Desafortunadamente, esto es vulnerable a las rebajas, como se mencionó anteriormente. Para resolver esto, los administradores del sistema pueden apuntar puntos finales a un resolutor DOH/DOT en modo estricto. Idealmente, esto se hace a través de soluciones seguras de administración de dispositivos (MDM, política de grupo en Windows, etc.).

    Conclusión

    Una de las piedras angulares de Internet es mapear los nombres para una dirección utilizando DNS. DNS ha utilizado tradicionalmente transportes inseguros y sin cifrar. Esto ha sido abusado por los ISP en el pasado por inyectar anuncios, pero también causa una fuga de privacidad. Los visitantes entrometidos en la cafetería pueden usar DNS sin cifrar para seguir su actividad. Todos estos problemas se pueden resolver utilizando DNS sobre TLS (DOT) o DNS sobre HTTPS (DOH). Estas técnicas para proteger al usuario son relativamente nuevas y están viendo una adopción creciente.

    Desde una perspectiva técnica, DOH es muy similar a HTTPS y sigue la tendencia general de la industria para desaprobar las opciones no seguras. DOT es un modo de transporte más simple que DOH a medida que se elimina la capa HTTP, pero eso también facilita ser bloqueado, ya sea deliberadamente o por accidente.

    Secundario a habilitar un transporte seguro es la elección de un resolución DNS. Algunos proveedores utilizarán el resolución DNS configurado localmente, pero intentan actualizar de manera oportunista el transporte no cifrado a un transporte más seguro (ya sea DOT o DOH). Desafortunadamente, el resolutor DNS generalmente es predeterminado a uno proporcionado por el ISP que puede no admitir transportes seguros.

    Mozilla ha adoptado un enfoque diferente. En lugar de confiar en los resolutores locales que pueden ni siquiera admitir DOH, permiten al usuario seleccionar explícitamente un resolución. Los solucionadores recomendados por Mozilla tienen que satisfacer altos estándares para proteger la privacidad del usuario. Para garantizar que las características de control de los padres basadas en DNS permanezcan funcionales y para admitir el caso de uso de Horizon dividido, Mozilla ha agregado un mecanismo que permite a los resonedores privados deshabilitar DOH.

    Los protocolos de transporte DOT y DOH están listos para que nos mudemos a un Internet más seguro. Como se puede ver en trazas de paquetes anteriores, estos protocolos son similares a los mecanismos existentes para asegurar el tráfico de aplicaciones. Una vez que se cierre este agujero de seguridad y privacidad, habrá muchos más que abordar.

    

    Visite 1.1.1.1 de cualquier dispositivo para comenzar con nuestra aplicación gratuita que hace que su Internet sea más rápido y seguro.

    Para obtener más información sobre nuestra misión para ayudar a construir un mejor Internet, comience aquí. Si está buscando una nueva dirección de carrera, consulte nuestras posiciones abiertas.

    Windows 11 incluye la función de privacidad DNS-Over-HTTPS: cómo usar

    

    Microsoft ha agregado una función de privacidad a Windows 11 llamada DNS-Over-HTTPS, lo que permite a los usuarios realizar búsquedas DNS cifradas para evitar la censura y la actividad de Internet.

    Al conectarse a un sitio web u otro host en Internet, su computadora primero debe consultar un servidor del sistema de nombre de dominio (DNS) para la dirección IP asociada con el nombre de host.

    DNS-Over-HTTPS (DOH) permite que su computadora realice estas búsquedas DNS a través de una conexión HTTPS cifrada en lugar de a través de las búsquedas de DNS de texto sin formato normal, que los ISP y los gobiernos pueden husmear.

    A medida que algunos gobiernos e ISP bloquean las conexiones a los sitios al monitorear el tráfico DNS de un usuario, DOH permitirá a los usuarios evitar la censura, evitar ataques de falsificación y aumentar la privacidad ya que sus solicitudes DNS no pueden ser monitoreadas tan fácilmente.

    Los navegadores basados ​​en el cromo, como Google Chrome y Microsoft Edge, y Mozilla Firefox, ya han agregado soporte para DOH. Aún así, solo se usa en el navegador y no por otras aplicaciones que se ejecutan en la computadora.

    Es por eso que es útil que un sistema operativo admite la función, ya que todas las búsquedas DNS en el dispositivo estarán encriptadas.

    Windows 11 obtiene DNS-Over-HTTPS

    Microsoft lanzó por primera vez DNS-Over-HTTPS a Windows Insiders para probar en Windows 10 Preview Build 20185, pero lo deshabilitaron algunas compilaciones más tarde.

    Con Windows 11, Microsoft ha habilitado la función DOH nuevamente, y los usuarios pueden comenzar a probarlo nuevamente si actualmente están utilizando servidores DNS de Cloudflare, Google o Quad9.

    Si el dispositivo está configurado actualmente para usar un servidor DNS de CloudFlare, Google o Quad9, puede configurar DNS-Over-HTTPS utilizando los siguientes pasos:

    1. Abra la aplicación de configuración de Windows 10 y vaya a Red e Internet.
    2. En la página de red e internet, haga clic en Éternet o Inalámbrico dependiendo de la conexión de red que tenga.

    

    

    

    La opción de cifrado DNS preferida ofrece las siguientes opciones:

    • Solo no certificado: use DNS estándar sin cifrar.
    • Solo encriptado (DNS sobre HTTPS): solo use servidores DOH.
    • Comercio preferido, preferido, sin cifrar solo: intente usar servidores DOH, pero si no está disponible, recurra a DNS estándar sin cifrar.

    En este momento, Microsoft afirma que se sabe que los siguientes servidores DNS admiten DOH y pueden ser utilizados automáticamente mediante la función DNS-Over-HTTPS de Windows 11.

    • Cloudflare: 1.1.1.1 y 1.0.0.1 servidores DNS
    • Google: 8.8.8.8 y 8.8.8.4 servidores DNS
    • Quad9: 9.9.9.9 y 149.112.112.112 servidores DNS

    Para ver las definiciones DNS-Over-HTTPS configuradas ya configuradas en Windows 11, puede usar los siguientes comandos:

    Uso de NetSh: NetSH DNS muestra cifrado usando PowerShell: get-dnsclientdohserveraddress 

    Microsoft también permite a los administradores crear sus propias definiciones del servidor DOH utilizando los siguientes comandos:

    Uso de NetSh: NetSH DNS Agregar servidor de cifrado = [resolver-ip-dress] dohtemplate = [resolver-doh-template] autoupgrade = sí udpfallback = no usando powershell: add-dnsclientDohserverAddress -serverAddress '[resolver -doh -template]' -AllowfallbackToudp $ false -auToupGrade $ true 

    Microsoft dice que sería mejor si el servidor DOH para un servidor DNS configurado pudiera determinarse automáticamente, pero causaría un riesgo de privacidad.

    “Sería más fácil para los usuarios y administradores si permitiéramos que un servidor DOH se determine su dirección IP resolviendo su nombre de dominio. Sin embargo, hemos elegido no permitir que. Apoyar esto significaría que antes de una conexión de DOH podríamos establecer, primero tendríamos que enviar una consulta DNS de texto simple para arrancarlo “, dice Tommy Jensen, un administrador de programas en el equipo de redes de Windows Core, en una nueva publicación de blog.

    “Esto significa que un nodo en la ruta de la red podría modificar o bloquear maliciosamente la consulta de nombre del servidor DOH. En este momento, la única forma en que podemos evitar esto es hacer que Windows sepa de antemano la asignación entre direcciones IP y plantillas DOH.”

    En el futuro, Microsoft espera aprender sobre las nuevas configuraciones del servidor DOH de un servidor DNS utilizando el descubrimiento de resolvers designados (DDR) y el descubrimiento de resolvers designados por la red (DNR), que han propuesto para agregar WG.

    Administrar DOH a través de políticas grupales

    Microsoft también ha agregado la capacidad de administrar la configuración DNS-Over-HTTPS de Windows 11 a través de políticas de grupo.

    Con Windows 11, Microsoft ha introducido un ‘Configurar DNS sobre resolución de nombre HTTPS (DOH)‘Política en Configuración de la computadora> Plantillas administrativas> Red> Cliente DNS.

    

    Esta política le permite configurar la máquina para usar DNS estándar sin cifrar, prefirir DOH o requerir DOH.