Hoy presentamos la compatibilidad para una nueva propuesta de estándar DNS, elaborado conjuntamente por ingenieros de Cloudflare, Apple y Fastly, que separa las direcciones IP de las consultas para que ninguna entidad pueda ver ambas al mismo tiempo. Mejor aún, hemos puesto a disposición el código fuente para que cualquiera pueda probar ODoH o ejecutar ¡su propio servicio ODoH!
Pero antes, analicemos brevemente el contexto. El sistema de nombres de dominio (DNS) es la base de una tecnología que nos permite navegar por Internet. Asigna nombres de dominio legibles, como cloudflare.com, a direcciones IP y otra información necesaria para conectarse a ese dominio. Para leer una introducción rápida sobre la importancia y los problemas del DNS consulta la entrada anterior del blog. Para este artículo es suficiente saber que el diseño inicial y el uso aún dominante de las consultas de DNS se envían en texto sin cifrar. Esto significa que cualquier persona en la ruta de red entre tu dispositivo y el resolutor de DNS puede ver tanto la consulta que contiene el nombre de host (o sitio web) que deseas como la dirección IP que identifica tu dispositivo.
Para proteger el DNS de observadores y terceros, la organización internacional IETF (Internet Engineering Task Force) estandarizó el cifrado de DNS con DNS mediante HTTPS (DoH) y DNS mediante TLS (DoT). Ambos protocolos evitan que las consultas sean interceptadas, redirigidas o modificadas entre el cliente y el resolutor. Los servicios de atención al cliente para DoT y DoH están creciendo y las últimas versiones de Firefox e iOS, entre otros, también los incluyen. Aun así, hasta que su implementación no sea más universal entre los proveedores de servicios de Internet, Cloudflare es uno de los pocos proveedores que ofrece un servicio público de DoH/DoT. Esto ha planteado dos cuestiones principales. Una de ellas es que la centralización de DNS introduce puntos únicos de fallo (aunque con más de 100 centros de datos, Cloudflare está diseñado para estar siempre accesible). Por otro lado, el resolutor sigue pudiendo vincular todas las consultas a las direcciones IP del cliente.
El compromiso de Cloudflare es velar por la privacidad del usuario final. Los usuarios de nuestro servicio de resolutor de DNS público están protegidos por una política de privacidad sólida y auditada. Sin embargo, para algunos clientes, confiarle a Cloudflare información confidencial de consultas representa un gran obstáculo para la adopción de este servicio, incluso con una política de privacidad tan sólida. En lugar de depender de las políticas de privacidad y auditorías, ¿qué pasaría si pudiéramos darles a los usuarios una opción para mejorar el listón asegurando garantías técnicas?
Cloudflare presenta hoy junto a sus socios la compatibilidad con un protocolo que hace exactamente eso: Oblivious DNS over HTTPS (ODoH).
Socios de ODoH:
Estamos encantados de presentar el lanzamiento de ODoH junto con varios socios líderes que están igualmente comprometidos con la privacidad.
El componente clave de ODoH es un servidor proxy que se separa del resolutor del servidor de destino. Hoy presentamos ODoH con varios socios líderes en soluciones de servidores proxy, tales como PCCW, SURF y Equinix.
"ODoH es un concepto nuevo y revolucionario que está diseñado para mantener la privacidad de los usuarios en el centro de todo lo que hacemos. Nuestra asociación con Cloudflare en el protocolo ODoH nos coloca en una buena posición en el ámbito de la privacidad y la "infraestructura de Internet". Además de reforzar la seguridad y el rendimiento de la red subyacente de PCCW Global, a la que se puede acceder mediante petición a través de Console Connect, hemos observado también una mejora en el rendimiento de los servidores proxy de nuestra red gracias a los resolutores 1.1.1.1 de Cloudflare. Este modelo por primera vez desvincula completamente el proxy del cliente de los resolutores. Esta asociación refuerza nuestro enfoque actual en la privacidad, especialmente ahora que el mundo avanza hacia una modalidad de trabajo en remoto que convierte la privacidad en una función aún más importante". -- Michael Glynn, Vicepresidente de innovación digital automatizada, PCCW Global
"El objetivo de nuestra asociación con Cloudflare es mejorar la privacidad del usuario a través de ODoH. El paso a ODoH supone un verdadero cambio de paradigma, en el que la privacidad de los usuarios o la dirección IP no está expuesta a ningún proveedor, lo que permite una privacidad real. Con el lanzamiento del protocolo piloto OdoH, nos sumamos al poder de la red de Cloudflare para responder a los desafíos de los usuarios en todo el mundo. Esta iniciativa no solo plantea un cambio de paradigma sino que también enfatiza la importancia que tiene la privacidad para cualquier usuario, sobre todo este año. Además, está en línea con nuestro enfoque principal y convicción en torno a la privacidad".-- Joost van Dijk, Gerente técnico de productos, SURF.
¿Cómo funciona Oblivious DNS mediante HTTPS (ODoH)?
ODoH funciona añadiendo una capa de cifrado de clave pública, así como un proxy de red entre los clientes y los servidores de DoH, como 1.1.1.1. La combinación de estos dos elementos garantiza que solo el usuario tenga acceso a los mensajes DNS y a su propia dirección IP al mismo tiempo.
Hay tres participantes en la ruta de ODoH. Empecemos por el servidor de destino fijándonos en el diagrama que se muestra arriba. El servidor de destino descifra las consultas encriptadas por el cliente a través de un proxy. De manera similar, el servidor de destino encripta las respuestas y las devuelve al proxy. El estándar ni confirma ni desmiente que el destino es el resolutor (hablaremos de esto más adelante). El servidor proxy hace lo que se supone que debe hacer un proxy, es decir, reenvía los mensajes entre el cliente y el servidor de destino. El cliente se comporta como lo hace en el DNS y el DoH, pero difiere al cifrar las consultas para el destino y descifrar las respuestas del destino. Cualquier cliente que elija hacerlo puede especificar el servidor proxy y de destino de su elección.
Juntos, el cifrado añadido y el proxy garantizan lo siguiente:
El destino solo ve la consulta y la dirección IP del proxy.
El proxy no tiene visibilidad de los mensajes DNS, ni capacidad para identificar, leer o modificar la consulta que envía el cliente o la respuesta que devuelve el servidor de destino.
Solo el servidor de destino previsto puede leer el contenido de la consulta y generar una respuesta.
Estas tres garantías mejoran la privacidad del cliente, manteniendo al mismo tiempo la seguridad y la integridad de las consultas de DNS. Sin embargo, cada una de ellas se basa en una propiedad fundamental, que el proxy y los servidores de destino no actúen en colusión. Mientras sea así, un atacante solo logrará su objetivo si el proxy y el servidor de destino están comprometidos.
Un aspecto de este sistema que vale la pena destacar es que el servidor de destino está separado del resolutor recursivo ascendente que realiza la resolución de DNS. En términos de rendimiento, esperamos que el destino sea el mismo en la práctica. De hecho, 1.1.1.1 ahora es tanto un resolutor recursivo como un ¡servidor de destino! No hay razón para que un servidor de destino tenga que existir independientemente de un resolutor. Si se separan, el destino es libre de elegir los resolutores y actuar como intermediario. El único requisito es que los servidores proxy y de destino nunca colaboren.
Además, es importante que los clientes tengan el control total de la selección de los servidores proxy y de destino. Las consultas de los clientes pueden ser privadas y seguras sin necesidad de programas similares de resolutores recursivos de confianza TRR. El servidor de destino solo conoce el proxy y, por tanto, el destino y cualquier resolutor ascendente son ajenos a la existencia de cualquier dirección IP del cliente. La importancia de esto radica en que los clientes tienen un mayor control de sus consultas y las formas en que pueden ser utilizadas. Por ejemplo, los clientes pueden seleccionar y alterar sus servidores proxy y de destino en cualquier momento, por cualquier razón.
Flujo de mensajes ODoH
En ODoH, la 'O' significa oblivious (ajeno), y esta propiedad proviene del nivel de cifrado de los propios mensajes DNS. Este cifrado añadido es "de extremo a extremo" entre el cliente y el servidor de destino y es independiente de la encriptación de nivel de conexión proporcionada por TLS/HTTPS. Uno podría preguntarse por qué se requiere este cifrado adicional en presencia de un proxy. La respuesta es que se necesitan dos conexiones TLS separadas para admitir la funcionalidad del proxy. En concreto, el proxy termina una conexión TLS del cliente, e inicia otra conexión TLS con el destino. Entre esas dos conexiones, los contextos de los mensajes DNS aparecerían en ¡texto sin formato! Por este motivo, ODoH también cifra los mensajes entre el cliente y el destino para que el proxy no tenga acceso al contenido del mensaje.
Todo el proceso comienza con el cifrado de la consulta de los clientes para el servidor de destino mediante HPKE. Los clientes obtienen la clave pública del destino a través del DNS, donde se incluye en un registro de recursos HTTPS y está protegida por DNSSEC. Cuando el tiempo de vida (TTL) de esta clave expira, los clientes solicitan una nueva copia de la clave según sea necesario (igual que harían para un registro A/AAAA cuando el TTL de ese registro expira). El uso de una clave pública validada por DNSSEC de un servidor de destino garantiza que solo el destino previsto puede descifrar la consulta y cifrar una respuesta.
Los clientes envían estas consultas cifradas a un proxy a través de una conexión HTTPS. Una vez recibida, el proxy reenvía la consulta al servidor de destino designado. Acto seguido, el servidor de destino descifra la consulta, genera una respuesta enviando la consulta a un resolutor recursivo como 1.1.1.1, y luego cifra la respuesta al cliente. La consulta cifrada del cliente contiene material de codificación encapsulado del que los servidores de destino derivan la clave simétrica cifrada de respuesta.
Esta respuesta luego se envía de vuelta al proxy y posteriormente se reenvía al cliente. Toda la comunicación es autenticada y confidencial ya que estos mensajes DNS están encriptados de un extremo a otro, a pesar de ser transmitidos a través de dos conexiones HTTPS separadas (cliente-proxy y proxy-destino). El mensaje que de otra manera aparece en el proxy como texto sin formato es en realidad una tergiversación encriptada.
¿Cómo funciona en términos de rendimiento? ¿Tengo que sacrificar el rendimiento para conseguir privacidad?
Hemos hecho muchas mediciones para averiguarlo, y seguiremos en ello mientras se generaliza la implementación de ODoH. Nuestra serie preliminar de configuraciones de medición abarcó ciudades de Estados Unidos, Canadá y Brasil. Es importante que nuestras mediciones incluyan no solo 1.1.1.1, sino también 8.8.8.8 y 9.9.9.9. Hasta ahora, el conjunto completo de mediciones está documentado para acceso abierto.
En esas mediciones era importante aislar el costo del proxy y la encriptación adicional del costo de la configuración de la conexión TCP y TLS. La razón es que DoH incurre de cualquier forma en los costos de TLS y TCP. Así que, en nuestra configuración, "preparamos" las mediciones estableciendo una vez las conexiones y reutilizando esa conexión en todas las mediciones. Lo hicimos tanto para DoH como para ODoH, ya que la misma estrategia puede usarse en ambos casos.
Lo primero que podemos decir con seguridad es que la encriptación adicional es marginal. Lo sabemos porque seleccionamos al azar 10.000 dominios del conjunto de millones de datos de Tranco y medimos tanto la encriptación del registro A con una clave pública diferente como su descifrado. El coste adicional entre una consulta/respuesta de DoH mediante proxy y su homólogo ODoH es consistentemente menor de 1ms en el percentil 99.
Sin embargo, el canal de solicitud-respuesta de ODoH es mucho más que un simple cifrado. El gráfico de distribución acumulativa muestra una forma muy útil de analizar las mediciones. Si estás familiarizado con este tipo de gráficos, lee el siguiente párrafo. A diferencia de la mayoría de los gráficos en los que empezamos por el eje x, con las distribuciones acumulativas solemos empezamos con el eje y.
El siguiente gráfico muestra las distribuciones acumulativas de los tiempos de consulta/respuesta en DoH, ODoH y DoH cuando se transmiten a través de la red Tor. La línea horizontal discontinua que comienza a la izquierda desde 0,5 es la marca del 50 %. A lo largo de esta línea horizontal, para cualquier curva trazada, la parte de la curva que está debajo de la línea discontinua es el 50 % de los puntos de datos. Ahora fíjate en el eje x, que es una medida de tiempo. Las líneas que aparecen a la izquierda son más rápidas que las líneas de la derecha. Un último detalle importante es que el eje x está trazado en una escala logarítmica. ¿Qué significa esto? Observa que la distancia entre los marcadores etiquetados (10x) es igual en las distribuciones acumulativas, pero la 'x' es un exponente y representa órdenes de magnitud. Así que, mientras que la diferencia de tiempo entre los dos primeros marcadores es de 9ms, la diferencia entre el tercer y cuarto es de 900ms.
En este gráfico, la curva media representa las mediciones de ODoH. También medimos el rendimiento de las alternativas de preservación de la privacidad, por ejemplo, las consultas DoH transmitidas por la red Tor, representadas por la curva derecha del gráfico. (Las alternativas adicionales de preservación de la privacidad están capturadas en el informe técnico de acceso abierto). En comparación con otras variantes del DNS orientadas a la privacidad, el ODoH reduce a la mitad el tiempo de consulta, o incluso más. Este punto es importante ya que la privacidad y el rendimiento raramente se entienden, ¡así que es una mejora alentadora!
El gráfico que se muestra arriba también muestra que el 50 % de las veces las consultas ODoH se resuelven en menos de 228ms. Comparemos ahora la línea del medio con la línea de la izquierda que representa la "línea recta" (o normal) DoH sin ninguna modificación. La línea trazada de la izquierda señala que el 50 % de las veces, las consultas DoH se resuelven en menos de 146ms. Si observamos debajo de la marca del 50 %, las curvas también nos indican que la mitad de las veces esa diferencia nunca es mayor de 100ms. Por otro lado, si examinamos las curvas por encima de la marca del 50 % sabremos que la mitad de las consultas de ODoH son competitivas con DoH.
Esas curvas también ocultan mucha información, por lo que es importante examinar más a fondo las mediciones. El siguiente gráfico tiene tres curvas de distribución acumulativa diferentes que describen el rendimiento de ODoH si seleccionamos los servidores proxy y de destino por su latencia. Este es también un ejemplo de los datos que las mediciones pueden revelar, algunos de las cuales son incomprensibles. Por ejemplo, si observamos por encima del 0,5, estas curvas indican que la mitad de los tiempos de consulta/respuesta de ODoH son prácticamente idénticos, independientemente de la elección de los servidores proxy y de destino. Ahora concéntrate en la función de distribución acumulativa por debajo del 0,5 y compara las dos curvas sólidas con la curva discontinua que representa el promedio general. Esta región sugiere que la selección de los servidores proxy y de destino de menor latencia ofrece una mínima mejora con respecto a la media pero, lo que es más importante, muestra que la selección del proxy de menor latencia ¡empeora el rendimiento!
No hay duda de que quedan cuestiones pendientes. Este primer conjunto de mediciones se realizó principalmente en Norteamérica. ¿Puede cambiar el rendimiento a nivel mundial? ¿Cómo afecta esto al rendimiento del cliente en la práctica? Estamos trabajando para averiguarlo, y este lanzamiento nos ayudará a conseguirlo.
¡Interesante! ¿Puedo probar ODoH? ¿Existe un servicio ODoH abierto?
¡Sí y sí! Hemos abierto nuestras implementaciones interoperables de ODoH en Rust, odoh-rs y Go, odoh-go, además de integrar el servidor de destino en el DNS Resolver de Cloudflare. Así es, 1.1.1.1 está listo para recibir consultas a través de ODoH.
También hemos abierto clientes de prueba en Rust, odoh-client-rs, y Go, odoh-client-go, para realizar demos y consultas ODoH. Además, puedes comprobar la configuración HPKE utilizada por ODoH para la encriptación de mensajes a 1.1.1.1 consultando directamente el servicio:
$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com. IN TYPE65
;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==
;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE rcvd: 291Nuestro compromiso es trasladar este estándar al IETF. Esperamos que más operadores se unan a nosotros en esta andadura y ofrezcan compatibilidades para el protocolo, ya sea ejecutando servidores proxy o de destino, y esperamos que mejore el soporte al cliente a medida que aumente también la infraestructura disponible.
El protocolo ODoH es un enfoque práctico para mejorar la privacidad de los usuarios y tiene como objetivo mejorar la adopción general de protocolos DNS encriptados sin comprometer el rendimiento y la experiencia del usuario mientras navega en Internet.
Reconocimientos
La aportación de Marek Vavruša y Anbang Wen ha sido decisiva para conseguir que el resolutor 1.1.1.1 admita el protocolo ODoH. Chris Wood y Peter Wu ayudaron a preparar y probar las bibliotecas de ODoH.