DNS over TLS / HTTPS / QUIC y el futuro de la privacidad

DNS es el conocido y antiguo protocolo, que carece de todas las formas de ciberseguridad, y sin embargo, es uno de los protocolos más importantes y fundamentales de Internet. Por ello, últimamente estamos viviendo mejoras sobre el mismo, donde por ejemplo, DoT o DoH agregan una capa de ciberseguridad al transporte al protocolo DNS, reutilizar las mismas capas de ciberseguridad que usa HTTPS: TLS. Y es que, tanto DoT ( DNS over TLS ) como DoH ( DNS over HTTPS ) usan TLS.

DoH agrega HTTP/2 entre DNS y TLS para el encuadre. DoT también tiene una capa de tramas heredada de DNS sobre TCP, pero es ridículamente simple en comparación con HTTP/2. Ambos se ejecutan sobre TCP.

Y no solo eso, QUIC se sumó a la fiesta de la privacidad recientemente . QUIC es una "Stranger Things" que toma TCP, TLS y la capacidad de transmisión de HTTP/2 y los fusiona en un protocolo encriptado nativo implementado sobre UDP. A partir de este nuevo protocolo de transporte, obtenemos dos nuevas variantes: DoQ ( DNS over QUIC ) "tan reciente que no tiene ni entrada en la wikipedia", que es similar a DoT pero utiliza la capacidad de flujo de QUIC en lugar del marco DNS sobre TCP, y DoH3, que es DNS sobre HTTPS/3, siendo HTTP/3 mucho más rápido.

Cómo funciona DNS over HTTPS ( DoH )

El principal problema con el DNS convencional es que las consultas se envían completamente sin cifrar a través de la red, lo que facilita a los "fisgones" ver qué sitios se están visitando.

La siguiente captura de pantalla contiene algunos resultados de la popular herramienta de análisis de red WireShark, capturados mientras se navegaba.

Como podéis observar, el dominio CIBERSEGURIDAD .blog aparece en texto plano sin formato. Siendo los DNS de OpenDNS hacia mi laboratorio y viceversa.

La misma información estaría disponible para cualquier persona con un mínimo acceso a nuestra red . Esto podría incluir nuestro ISP, el gobierno o cualquier persona en la misma red Wi-Fi que ejecute un rastreador de paquetes como WireShark.

Sin embargo, con DoH, el tráfico de DNS se envía a través de un túnel encriptado usando HTTPS, la misma tecnología que se usa para encriptar el contenido real de nuestra sesiones de navegación. La siguiente captura muestra cómo se ven las comunicaciones DoH para los intrusos potenciales.

En la captura , podemos ver , en este caso, sobre el laboratorio Wifi ( 192.168.4.21 ) como apunta a los DNS de Quad9 configurados en Brave , donde las mismas peticiones al dominio CIBERSEGURIDAD .blog , aparecen como texto cifrado y totalmente ilegible.

Ventajas y diferencias DoT / DoH / DoQ

• DoT y DoQ usan puertos personalizados (tcp/853 y udp/8853 respectivamente) que los firewalls pueden bloquear fácilmente, mientras que DoH usa el mismo puerto y protocolo que se usa para todo el tráfico web HTTPS (tcp/443), lo que dificulta el bloqueo o incluso la detección. DoH3 usa udp/443, por lo que es más fácil de bloquear pero aún no se distingue de otro tráfico web que usa este protocolo ( Como es QUIC a secas ), y los clientes compatibles con HTTP/3 tienen la capacidad de recurrir a HTTP/2 cuando esto sucede.
• El protocolo HTTP/2 utilizado por DoH es significativamente más complejo que el marco básico empleado por DoT. La ventaja de DoH es que la mayoría de las implementaciones de HTTP/2 ofrecen un buen rendimiento, mientras que la mayoría de las implementaciones de DoT conduce a un rendimiento más bajo. Cuando se implementa correctamente, DoT ofrece una menor complejidad, lo que teóricamente puede tener un pequeño impacto positivo en el uso de la batería, pero podría ser una gota en el océano en comparación con TLS. Sin embargo, la diferencia en la latencia no debería ser perceptible.
  DoQ y DoH3, por otro lado, usan el mismo marco proporcionado por el protocolo QUIC, que está muy inspirado en el protocolo HTTP/2. La diferencia en complejidad entre DoQ y DoH3 es, por lo tanto, incluso menor que entre DoT y DoH.
• Como DoH usa HTTP, cuando se implementa en un navegador, existe la preocupación de tener las mismas capacidades de seguimiento que se usan en la web (user agent, cookies, etc.). Hasta la fecha, todos los clientes populares, incluidos los navegadores, no envían encabezados con fingerprints en la cabecera, se ejecutan sin cookies y ni siquiera envían un agente de usuario.
• DoQ y DoH3 son más resistentes a la pérdida de paquetes. DoT y DoH se ejecutan sobre una única conexión TCP, lo que significa que, en caso de pérdida de un paquete, todas las consultas o respuestas de DNS después de este paquete deben esperar a que se retransmita el paquete perdido (esto se denomina HoL o Head-of-line blocking). Gracias al diseño de secuencias de QUIC, una sola sesión de QUIC puede transportar varias secuencias individuales. Cada flujo es independiente y la pérdida de un paquete solo afecta al flujo al que está asociado. Tanto con DoQ como con DoH3, cada consulta/respuesta de DNS se aísla en su propio flujo, lo que elimina el problema de bloqueo de encabezado de línea descrito anteriormente. Por lo tanto, dichos protocolos son particularmente adecuados para redes móviles o altamente congestionadas, pero no harán ninguna diferencia sustancial en una red no congestionada. Un inconveniente es que QUIC está todo implementado en el espacio del usuario, y, por lo tanto, requiere más CPU y batería para funcionar que TCP. Esto puede ser un problema para las aplicaciones que hacen un uso intensivo del ancho de banda, pero como el DNS es bastante ligero, la diferencia debería ser insignificante con la mayoría de las implementaciones.

Adopción de DNS over QUIC ( DoQ )

Uno de los más interesantes y recientes estudios sobre DNS over Quic fue publicado hace unos días y el mismo nos revela importantes e interesantes conclusiones.

Para tratar la adopción de DoQ en Internet, los técnicos de la Universidad de Munich, comenzamos escaneando el espacio de direcciones IPv4 en busca de resolutores de DoQ, utilizando todos los puertos propuestos (UDP/784, /853 y /8853), en el transcurso de 29 semanas, desde el 5 de Julio de 2021 hasta finales de Marzo que fue la publicación. Para ello, fueron usaron, y apuntar para el repositorio, este conjunto de aplicaciones:

1. ZMap DoQ: ZMap packet for DoQ identification
2. Verify DoQ: Verification of DoQ services
3. Misc DNS Measurements: Registra DoQ negociado, así como la versión QUIC y el certificado X.509
4. DNSPerf: Biblioteca de medición de rendimiento para DoQ, DoUDP, DoTCP, DoT y DoH

Tras el escaneo, se intentó conectarse a las IPs identificadas, registrando las versiones QUIC y DoQ negociadas en el proceso, desde la versión draft-34 hasta la versión 1 de QUIC en la semana 43 de 2021 o las versiones DoQ draft-00 a draft-06. Además de las versiones QUIC y DoQ, también se registraron los certificados X.509 ofrecidos por los resolutores, sobre las cuales se usaron las direcciones IP para determinar geolocalizaciones.

Y este fue el resultado que obtuvieron:

Se puede observar que la cantidad de resolutores verificadas por DoQ aumenta constantemente semana tras semana, comenzando con 833 resolutores en la semana 27 de 2021, que termina en un aumento del 46,1 % a 1217 resolutores verificados en la semana 3 de 2022. Tras añadir por parte de estudio, soporte para la versión 1 de QUIC en la semana 43, se observa un uso constante de DoQ Draft 02/QUIC 1 (barras azul oscuro), lo que creo es muy esclarecedor del panorama que se nos viene.

DNS over QUIC promete mejorar los protocolos DNS cifrados establecidos al aprovechar el protocolo de transporte QUIC. En el estudio, se observa una adopción lenta pero constante de DoQ en los resolutores en todo el mundo, donde las fluctuaciones observadas semana tras semana reflejan el desarrollo continuo y el proceso de estandarización con implementaciones y servicios que cambian rápidamente.

Al analizar los tiempos de respuesta de DoQ, demostramos que los tiempos de negociación de DoQ utilizan completamente el potencial de QUIC en alrededor del 20 % de las mediciones. Sin embargo, aproximadamente el 40% de las mediciones muestran tiempos de negociación considerablemente más altos de lo esperado, lo que se remonta a la aplicación del límite de amplificación de tráfico a pesar de la validación exitosa de la dirección del cliente. Si bien esto muestra un potencial de optimización aún no utilizado, DoQ ya supera a DoT y DoH, lo que lo convierte en la mejor opción para DNS encriptado hasta la fecha. Si a esto le sumamos el empuje de Google de dicho protocolo, es muy probable, que estemos ante el inicio de una gran hegemonía.

Limitando el uso de DoH y DoT en nuestra red interna

Las organizaciones invierten mucho tiempo, dinero y esfuerzo en asegurar sus redes. Según la Unidad 42 de investigación de amenazas de Palo Alto Networks, aproximadamente el 85 % del malware utiliza DNS para establecer un canal de comando y control, lo que permite a los adversarios una ruta fácil para insertar malware en una red y extraer datos.

Los nuevos protocolos de DNS encriptados que tienen como objetivo mejorar la privacidad de DNS están comenzando a ganar apoyo entre los principales proveedores de navegadores. Con este aumento, las redes empresariales comenzarán a ver un aumento en el tráfico de DNS encriptado en la red.

El tráfico de DNS encriptado que no se inspecciona o prohíbe correctamente representa un riesgo de ciberseguridad para la empresa.

En el caso de los cortafuegos de Palo Alto, están equipados para prohibir o proteger el uso de DNS sobre TLS (DoT) y se pueden usar para prohibir ( ya veremos cómo ) el uso de DNS sobre HTTPS (DoH), lo que permite conservar la visibilidad y la seguridad sobre todo el tráfico DNS en su red.

Pero ojo, todo tienen un precio, como vimos ya hace 5 años en el post "Intercepción SSL , sacrificando la ética por la seguridad".

A menos que el tráfico HTTPS se identifique como consultas DoH, idealmente mediante el descifrado, las aplicaciones que ya están en uso dentro de su organización pueden omitir la configuración de DNS local, enrutando consultas a resolutores DoH de terceros, alrededor de todo el registro, monitorización, inspección y controles de DNS existentes.

Todos los proveedores de relevancia, Google, Mozilla e incluso y aunque renegado, el propio Microsoft, han implementado capacidades de DoH en la última versión de sus navegadores. Pero el problema no viene de dichos proveedores, si no que en el último año, los actores malintencionadas ya se han adaptado para comenzar a utilizar DoH como un medio para eludir la ciberseguridad en nuestro negocio.

En cualquier caso, tanto el tráfico DoH benigno como el malicioso pasarán desapercibidos, dejando a la organización ciega ante el uso malicioso de DoH y la filtración de datos.

Lo vemos con el caso de Palo Alto, pero todo confluye en un mismo punto. Como práctica recomendada para DoH, es imprescindible configurar el NGFW para descifrar el tráfico HTTPS y bloquear el tráfico DoH , en este caso en concreto, posteriormente configurando el ID de aplicación 'dns-over-https'. Pero independientemente de los pasos posteriores o clasificación de aplicación todo pasa por descifrar el trafico. Como veíamos al inicio del post DoT o DoQ podría llegar a ser relativamente más sencillo de cortar, y digo relativamente , por que pasaría por cortar el puerto, pudiendo limitar alguna aplicación interna. Por ejemplo, Google ha implementado DoT en su cliente Android 9 Pie y versiones posteriores , con la configuración habilitada de forma predeterminada para usar DoT automáticamente si está disponible. De forma habitual, en los NGFW está implícitamente bloqueado de manera predeterminada.

Como alternativa intermedia, si su organización no ha implementado por completo el descifrado de HTTPS o no puede por limitaciones de privacidad, el NGFW se puede configurar para denegar la App-ID "dns-over-https". Pero se lo que estáis pensando, si no descifro el tráfico .... exacto .... la regla "solo" se limitará a bloquear ciertos resolutores DoH conocidos por su nombre de dominio.

Bloquear el uso de DoH y DoT en nuestro negocio

Al igual que antes he indicado que la limitación de DoH y DoT pasa por la intercepción ssl en ambos casos. La única forma de bloquear su uso, pasa por bloquear la activación de los mismos en entornos empresariales. Y por ello, para poder bloquear la activación, debemos conocer como activarlos en los principales proveedores:

Activar DNS over HTTPS en Google Chrome o Brave

Brave (El cual yo uso y soy muy Fan 😆) esta basado en Chronium , por lo que aunque el ejemplo que os ponga sea de Brave, la forma de activar DNS over HTTPS, será igual en Chrome, con alguna consideración. Para poder utilizar DNS sobre HTTPS (DoH) debemos tener al menos la versión 83 del navegador.

Si queremos habilitar DoH en Brave / Google Chrome tenemos que ir a configuración. A continuación y abrir el apartado de Privacidad y seguridad.

Disculpad que las capturas estén en ingles, pero es intuitivo.

Tras hacer clic en Seguridad. En configuración avanzada buscamos "Usar un DNS seguro". En nuestro caso y tras el ultimo ejemplo usado, podéis ver la configuración de Quad9 de la captura de Wireshark anterior.

Si no te aparece el menú anterior para configurar DoH, como se trata de una función experimental y depende de la versión, podríamos habilitarla así:

1. Escribimos chrome://flags/#dns-over-https en la barra de direcciones y pulsamos en enter.
2. Buscamos Secure DNS lookups y pulsamos en Enabled.
3. Reiniciamos Chrome y seguimos los pasos anteriores.

De las opciones que tenemos disponibles, encontramos Cloudflare, Google y Quad9 entre las predeterminadas :

Activar DNS over HTTPS en Firefox

Otro de los navegador más famosos y que ya admite DNS sobre HTTPS (DoH) es Firefox ( Aunque le costó algo ). Para activarlo:

1. Vamos a la configuración.
2. En «buscar» ponemos DoH o DNS sobre HTTPS ( si lo teneis en ingles, con el over ) y os saldrá el apartado configuración de red. Allí pulsaremos el botón que está a la derecha y que pone configuración.

Posteriormente buscaremos "Activar DNS sobre HTTPS ". La variedad de la que disponemos en Firefox, es bastante menor en comparación con Brave / Chrome. Si embargo, también podemos poner un servidor DoH seleccionando la opción "Personalizada".

Activar DNS over HTTP (DoH) en Windows 11

Con la creciente adopción de Windows 11 , y viendo lo que paso con la adopción de Windows 10, creo que es necesario tratarlo tambien en dicho sistema operativo, de donde tomara los ajustes Edge.

Si clickamos en el Botón de inicio , debemos seleccionar o buscar "Ajustes" desde el menú Inicio. También podemos usar las teclas WIN + I, que nos llevara directamente al mismo punto.

Una vez en Ajustes, debemos ir al menú lateral izquierdo, en la parte de “red e internet" , seleccionando en el menú lateral del lado derecho la red que estemos usando, ethernet o Conexión inalámbrica, en Propiedades .

Editamos la asignación de DNS:

Al editar, podremos observar que si forzamos a la configuración manual, nos da la opción de poder seleccionar DoH:

Es posible que dicha configuración, no la tengamos activa y directamente no nos salga. En nuestro entorno empresarial, lo ideal es desactivar, via GPO las directivas de forma que no nos de la opción de activar DoH como se muestra en la imagen :

Podríamos Prohibir el uso o habilitarlo en las directivas que os traslado:

Y marcando la necesidad en la directiva:

Comprobando nuestra privacidad DoH / DoT

Cloudflare ofrece una página web que puede verificar el estado de nuestra configuración. Cuando visitemos la página, si hacemos clic en "Verificar mi navegador", se mostrarán las medidas de seguridad aplicadas y las que faltarían.

Y en este punto, te estarás preguntando, pero ... Rubén , te sale Secure SNI deshabilitado , y es que de forma intencionada, he dejado eSNI, el futuro ECH y como podríamos activar DNS over QUIC del que tanto hemos hablado, ambas partes, en mi opinión, las que mayor proyección tendrán en un futuro cercano.

Entendiendo SNI y el fututo estándar Encrypted Client Hello (ECH)

A lo largo del post , siempre hemos hablado de dos conceptos claves, cifrado y descifrado de las comunicaciones , como eje central de la privacidad y como "limitar" la misma, a fin, siempre, claro esta a favor de evolucionar la visibilidad de la ciberseguridad en nuestro negocio.

Pero toda la potencia de SSL , TLS , QUIC ... tiene un punto débil común llamado formalmente SNI (Server Name Indication), que básicamente es una cabecera que el cliente envía al servidor en texto plano sin cifrar al inicio de la conexión, donde se indica el nombre del dominio. Es aquí donde pensáis que todo el post se viene abajo, pero veremos más adelante la luz al final del túnel.

Los proveedores de internet, no pueden saber qué hacen sus clientes dentro de una web ni sus datos, pero sí saben a qué webs acceden. Por ello, podemos ver que, tras un juicio en el que se bloquea el acceso por ejemplo, desde españa a ciertas web, realmente se limita, todas ellas, bloqueadas gracias a las cabeceras SNI.

The Telegraph desveló a principios de este año, que se estaba solicitando formalmente a la Comisión Europea, que se impida que Apple ofrezca iCloud Private Relay a los usuarios de iPhone en Europa. El servicio, crea un túnel cifrado entre el terminal y los servidores de Apple, de forma que todo el tráfico de internet que genera el usuario queda oculto para los intermediarios. Al utilizar Private Relay, todo el tráfico viaja cifrado, por lo que el proveedor de internet no tiene forma de leer el SNI. De esta forma, se rompe el principal instrumento para impedir el acceso a sistemas declarados ilegales.

De esta forma , webs tan conocidas como EMUDESC , las cuales, tras ser declarada en juicio, ilegal y solicitado el bloqueo en España a los distintos proveedores de internet, pueden ser libremente visitadas, con una IP de Madrid del propio servicio Private Relay.

Pero Private Relay no es el "coco" al que deben temer como aniquilador de la privacidad ( puede ser el primero ofrecido y al alcance de millones de personas de una forma sencilla ). Pero para los principales ISPs , así como la industria de contenido , el principal problema , nace de la evolución SNI, dado que el mismo estará cifrado y será imposible conocer su contenido, lo que impedirá conocer la peticiones iniciales, imposibilitando el bloqueo que actualmente se está realizando.

Encrypted Client Hello ( ECH ) , el futuro de la privacidad

El futuro de la privacidad pasa necesariamente por evolucionar de SNI a Encrypted Client Hello ( ECH ), promovido por el cualitativo salto en lo que respecta a privacidad se refiere. ECH encripta el protocolo de enlace completo para que estos metadatos se mantengan en secreto, corrigiendo un antiguo fallo de privacidad sobre Server Name Indicator (SNI).

El predecesor inmediato de ECH fue la extensión de la SNI cifrada(ESNI). El cliente encriptaba la extensión de su SNI bajo la clave pública del servidor y enviaba el texto cifrado al servidor. El servidor intentaba descifrar el texto cifrado utilizando la clave secreta correspondiente a su clave pública. Si se conseguía el descifrado, el servidor procedía a la conexión utilizando la SNI descifrada. De lo contrario, simplemente abortaría el protocolo.

Pero para la distribución de dichas claves, ESNI se basaba en otro protocolo crítico: el sistema de nombre de dominio (DNS). Pero como ya sabéis, el protocolo DNS tiene sus carencias, lo que hace que la implementación de ESNI solo se hiciese factible con DoH, permitiendo la encriptación de las consultas de DNS a los resolutores que proporcionan el servicio DoH.

Y es en este punto donde entra en juego Encrypted Client Hello. El objetivo de ECH es encriptar todo el mensaje ClientHello, cerrando así la brecha entre TLS 1.3 y ESNI, con el fin de proteger todos los parámetros del protocolo sensibles a la privacidad. El protocolo ECH involucra dos mensajes ClientHello: el ClientHelloOuter, que se envía sin cifrar, como de costumbre, y el mensaje ClientHelloInner, que se encripta y se envía como una extensión del ClientHelloOuter. Si se consigue el descifrado, se procede con el mensaje ClientHelloInner, si no, se procede con el mensaje ClientHelloOuter.

El objetivo de ECH es asegurar que las conexiones TLS realizadas a diferentes servidores de origen detrás del mismo proveedor de servicios ECH no se distingan entre sí. Y que, cuando te conectas a un servidor, nadie en la red entre tú y dicho servidor debería ser capaz de discernir a qué origen llegaste, o qué parámetros del protocolo de enlace confidenciales acordaste con el servidor de origen, impidiendo dicha característica SNI que no nos hacia tan invisibles como creíamos.

Podéis conocer muchísimo más allá de este pequeño alto nivel que os intento resumir, en un fantástico post de uno de los promotores de dichos estándares, Cloudflare. Por contra, a inicios del año pasado, Firefox anunciaba que retiraba eSNI, sustituyéndolo por ECH, una decisión que dejaba a los usuarios repentinamente sin mecanismo anti bloqueos, puesto que Cloudflare sigue usando a día de hoy, eSNI y no ECH. Pero ojo, y esto es importante si a día de hoy queremos "ser invisibles" :

La única forma de usar eSNI es utilizar una versión de Firefox anterior a la 85.

Mientras tanto, el ECH progresa firmemente, camino de convertirse en un estándar, lo que forzara a soportarlo nativamente tanto a Apache o Nginx entre otros.

Usando DNS over QUIC

Como antes os trasladaba, creo que DNS over QUIC ( DoQ ) es el futuro del cifrado de DNS. Pero sólo el tiempo lo dirá, y deberemos ver muchísima evolución por el camino, afianzando la privacidad que hemos tratado por ejemplo con Encrypted Client Hello ( ECH ).

Si queremos probar y jugar con DNS over QUIC, diría que sólo tenemos una opción "sencilla", que se trataría de AdGuard DNS , dado que es el primer resolutor de DNS público compatible con el nuevo protocolo DNS sobre QUIC. Actualmente, el estándar DoQ se encuentra en etapa de borrador , pero esto no nos impide experimentar con él.

En algún punto cercano del tiempo, DNS over HTTPS también admitirá QUIC, gracias al futuro empleo del protocolo HTTP/3 que se está construyendo alrededor de QUIC. Lo que nos lleva a una pregunta existencial , entonces ¿por qué necesito DoQ y por que este "tio" me lo vende como el futuro?.

Y es que HTTP no se concibió como un protocolo de capa de transporte . Si bien es muy cierto que puede servir como sustituto de un protocolo de transporte, no genera muchos problemas en el área de la privacidad, ya que el uso de HTTP para transferir solicitudes de DNS generará como ya os adelantaba:

• cookies HTTP
• Encabezados HTTP (Authentication, User-Agent, Accept-Language)
• Múltiples Fingerprintings

Si bien todos estos problemas pueden tenerse en cuenta en el lado del cliente a nivel de DoH, los propios clientes varían mucho: navegadores, sistemas operativos ... Es prácticamente imposible tener una solución del lado del cliente para todos y cada uno de ellos, y por ello, vimos distintas.

En este punto, la solución de DoQ que propone Adguard, si auna todo, pero este no es el plus a su favor, ya que iran saliendo herramientas similares, si no el propio DNS over QUIC usado.

Lo que esta claro, es que todo aquel que proclamase la privacidad de los datos como su leitmotiv, tal vez aupado por la certeza de que no era tan "privacidad" , va a tener que posicionarse, puesto que la supremacía de la misma esta próxima y llegara el día en el que deba elegirse entre privacidad o no.