DNS sobre HTTPS (DoH) ya está aquí, la polémica está servida

Hace muy poco, la IETF ha elevado a RFC la propuesta de DNS sobre HTTPS. Sí, resolver dominios a través del conocido HTTPS, con su POST, su GET e intercambio de certificados para cifrar y autenticar. La noticia tiene mucho más calado de lo que pueda parecer. Por dos razones: primera, es un nuevo paradigma de resolución que remueve los cimientos de la red. Segunda, porque el espaldarazo de disponer de RFC unido al interés mostrado por los navegadores (ávidos del poder que esto les confiere) ha hecho que en tiempo récord ya se hayan lanzado a su implementación. Dicen que garantiza tu privacidad, sí, pero… ¿Es buena o mala idea?

DoH (DNS over HTTPS) es muy simple. En vez de acudir al puerto 53 de un servidor (digamos, el conocido 8.8.8.8) y preguntarle por un dominio a través de un paquete UDP o TCP, DoH estandariza la construcción de un GET o POST a un dominio HTTPS y la respuesta será el registro A y AAAA (el RFC no especifica otros registros) con la IP. Por supuesto tiene más detalles como la solución ingeniosa de que la cabecera cache-control va a convertirse en el TTL. Todo cifrado punto a punto, obviamente. ¿Recordáis cuando en un hotel se podía tunelizar a través del protocolo DNS (habitualmente no restringido) la navegación HTTP para no pagar la WiFi? Pues ahora, al revés.

El protocolo DNS es como un camello. A lo largo del tiempo, se le ha cargado con tanto peso, se le ha obligado a soportar tantos parches, remedios y «plugins», que ahora pacientemente se arrastra por el desierto sin terminar de resolver ningún problema del todo excepto para lo que fue diseñado. Y por una u otra razón, todavía ni siquiera se ha conseguido la deseada sºeguridad y/o privacidad. No porque no se haya propuesto (de hecho hay decenas de propuestas alternativas o complementarias entre sí), sino porque ninguna se ha adoptado masivamente. Desde DNSSEC, pasando por DNS over TLS (DoT), que como se intuye, es seguir con el mismo protocolo DNS, pero con un túnel TLS (algo así como POP3 Y SPOP3). DoT, lo más parecido a DoH, utiliza el puerto 853 y efectivamente, también oculta el contenido del tráfico y autentica al servidor. Este RFC se propuso en 2016. Pero no ha calado tanto como se esperaba. Desde luego, no ha causado el revuelo levantado con DoH.

Por cierto, también existe DNS over DTLS, DNS over QUIC, DNS over TOR… Existe hasta un DoH que devuelve un Json, pero esto es una adaptación especial que usa Google (aunque también lo hace Cloudfare) más potente (por ejemplo, permite consultar otros registros que no sean solo A o AAAA).

En estas imágenes se observa cómo usar DoH a través de las APIs de Google y Cloudfare y cómo devuelve un Json

DNS es uno de los protocolos más antiguos de la red, y siempre ha sido un dolor de cabeza de de la seguridad (desde el ataque cumpleaños, hasta el problema de Kaminsky). Todo en claro, con posibilidad de UDP (más fácil aún de inyectar paquetes falsos…). Un desastre incluso sin necesidad de ataques porque los servidores pueden estar controlados por gobiernos y así redirigir o bloquear peticiones. Y todo de forma absolutamente transparente y sin privacidad ni integridad (porque DNSSEC no está tan instaurado como debería). Hemos confiado los cimientos de Internet a un protocolo que no ha sabido protegerse tecnológicamente como para que se adoptaran masivamente las soluciones (o no se ha querido, precisamente por esa misma razón) y al que se le han aplicado todo tipo de parches y cataplasmas para no romper con el legado. Tanto, que al final la propuesta para conseguir seguridad ha sido rompedora: pasar la resolución al plano de los datos. Y por si fuera poco, DoH hace que la resolución no confíe en el DNS global del sistema, sino que podrá ignorar a ese servidor DNS que habitualmente se te proporciona por DHCP… de forma que cada aplicación podrá resolver a través de HTTPS de forma estándar.

Pero esto no es malo, ¿verdad?, ¿no sería maravilloso que nadie viera qué intentamos resolver, y no pudiera modificarlo de ninguna forma? Disfrazar en el HTTPS las peticiones, las respuestas, y dejarse arrastrar por la masa en un puerto que nadie puede cortar, el 443. No más espías o restricciones. Eso es lo que promete DoH, pero ¿rompe más de lo que arregla?

Los navegadores lo celebran y ya lo implementan. Es su oportunidad de ganar poder, no solo porque ya conocen la tecnología HTTPS y les cuesta poco, sino porque pueden incrustar dentro del navegador el resolvedor al que se consultará por defecto… Por ejemplo, Google ya no tendría acceso a todo lo que resuelve el mundo a través de su famoso 8.8.8.8, sino que ampliaría su porcentaje de usuarios de su DNS (alrededor del 13 %) hasta todo aquel que utiliza Chrome, que ya va por el 60 %. Lo llama «secure DNS». Ha visto la oportunidad de salirse de la tiranía del DNS de sistema justo en el lugar donde más dominios se resuelven: el navegador. Google ya usa también DoH en su aplicación Intra (publicada bajo Jigsaw Operations) que precisamente sirve para eludir bloqueos de DNS.

Android, por su lado, implementa DNS over TLS en su última versión, aunque no lo han hecho demasiado público. Actualmente Cloudfare también está en el negocio de los DNS, así la compañía del famoso 1.1.1.1 se ha asociado con Firefox para ser el proveedor de resolución de confianza. De hecho, DoH en Firefox es conocido como TRR (Trusted Recursive Resolver). Promete no usar los poquitos datos de usuarios que puedan necesitar. Por ejemplo, Cloudfare se compromete a eliminar ese envío de los 3 primeros octetos que se utilizan en una petición DNS. Ese envío de los 3 primeros octetos es un movimiento (con RFC) promovido por Google y OpenDNS en 2011 para mejorar el rendimiento DNS por localización de IP.

Chrome lo implementa, pero todavía no tiene interfaz para manejarlo. Están en ello. https://chromium-review.googlesource.com/c/chromium/src/+/1194946

Firefox ya lo incorpora, desactivado por defecto

Siendo sinceros, hay dos problemas graves. Ambos heredados del propio TLS. El primero, y que los más avispados ya habrán descubierto, es que hoy por hoy en el mundo TLS, el dominio que se visita queda en claro. Si alguien observa una comunicación TLS no verá nada de lo que el cliente habla con el dominio, pero sí el domino en sí. Esto se debe al SIN, Server Name Indication, que es un parámetro que se intercambia de forma natural durante el proceso de negociación TLS. Aquí, los defensores de DoH dicen que sí, vale, pero que cambiará en breve. En 2017 se aceptó como borrador este RFC que define cómo se cifrará toda comunicación TLS, incluyendo los dominios que visitas. Si esto queda cifrado en el TLS, la propia petición de resolución de DNS over HTTPS, será invisible totalmente y ahora sí, tendrá privacidad. ¿Cuánto queda para esto? No se sabe. Simplemente confían en que TLS lo adopte. Pero ojo, que un posible resolvedor tradicional (detrás del DoH) todavía verá qué dominios se solicitan, con lo que, en un momento dado, quizás se podría «ir hacia atrás» y ver quién pidió qué. Quizás lo lógico sea usar DoH como interfaz, y DoT en los servidores que realmente pueden llegar a hacer el trabajo de búsqueda del dominio en el «background» de la petición. Y todo esto añadiendo DNSSEC, puesto que es perfectamente compatible (añade integridad) y cumplen diferentes funciones.

Por otro lado, otro de los graves problemas de TLS en general es el uso de certificados falsos en el servidor, que puedan permitir romper el cifrado y espiar. Esta mala práctica está al alcance de los gobiernos, y resulta paradójicamente un punto débil del DoH por usar TLS, sobre todo cuando DoH se ha diseñado precisamente para garantizar que un gobierno no pueda coartar internet a través del DNS tradicional. Un gobierno solo tendría que interponerse con un certificado falso también en el DoH (como a veces se hace para otras páginas). Pero si bien DoT sí que obliga al uso de pinning en su RFC, en DoH ni siquiera lo recomiendan… ¿No lo han previsto?

Se observa que en DNS over TLS sí se indican los pines (en dnsprivacy.org) pero no se hace lo mismo en DoH. Incluso se desaconseja.

Para conseguir el pinning, como otras soluciones (como en el extinto HPKP), tras el handshake TLS de DoT, el cliente calcula el SPKI del certificado basado en la clave pública y otros datos del X.509. Es exactamente igual que los pines de HPKP, solo que no hay primer traspaso. El cliente debe saberlos de antemano y almacenarlos.

Se supone que esto rompe el paradigma del internet conocido. Al menos plantea dudas. De hecho, Paul Vixie (uno de los padres del DNS) está radicalmente en contra, y promueve el uso de DNS sobre TLS en vez de sobre HTTPS. Una de las razones que argumenta es que (a pesar de sonar aguafiestas) se ha permitido finalmente abrir una especie de caja de Pandora, los analistas perderán control sobre la red, la capacidad de monitorizar, se confunden protocolos de señalización y datos… Hay que tener en cuenta que este modelo otorga todavía más poder al navegador, y por tanto, al que mayor cuota de navegador dispone hoy en día: Google. Firefox tiene una política más transparente en este sentido, aunque Cloudfare podrá obtener interesante información gracias a su alianza. Sea como sea, ¿estamos centralizando demasiado el DNS, que por naturaleza nació descentralizado?

DoH es simplemente una nueva forma de consumir DNS, detrás, el servidor consultado puede hacer lo que quiera (cosa que ya hace) y realmente lo que hará no es más que lo que cualquier otro resolvedor en la red. El protocolo no cambia, se modifica cómo y quién accede a él. Tampoco cambia el cifrado con respecto a DoT, solo que ahora se hace a través de un puerto 443 que esconde todo el resto de tráfico cifrado y así la resolución DNS queda perdida en el resto de consultas. Al igual que el malware aprendió (para contrarrestar la popularidad de los cortafuegos) a situar al servidor fuera de la red (en vez de convertir a la víctima en servidor abriendo un puerto); al igual que luego comprendió que era mejor dejar de usar puertos extraños (IRC, por ejemplo…) y comunicarse a través del 80, y más tarde incluso 443; al igual que hemos ido trasladando nuestro disco duro a la nube y toda aplicación al navegador… DNS se une a esta corriente, de forma que replantea su funcionamiento tradicional. Todo esto plantea dudas de cómo se configurará la resolución en los sistemas. No vaya a ser que lo que se temía que antes hicieran los gobiernos, puedan ahora conseguirlo los dueños de las aplicaciones o grandes centralizadores de DNS. O todo lo contrario… En el futuro, quizás bajemos aplicaciones con su propio DoH incorporado, y aceptaremos cambios en las consultas DNS por el hecho de aceptar los términos y condiciones que nadie lee…

¿Y qué pasa con algo tan común en seguridad como el poder de filtrar dominios a nivel de DNS? Pues no sería posible con DoH, pues el navegador podría seguir visitando ese phishing o command a control a pesar de haberlo bloqueado en el DNS de la compañía. ¿Le estamos haciendo un favor al malware a cambio de privacidad para el usuario y poder para el navegador?

Pero DoH también abre nuevas posibilidades. Para que esto funcione, se utiliza el multiplexado de HTTP/2 , que abre a su vez otras vías, gracias al push que permite resolver más dominios de una sola tacada. Es más, permite reducir el problema del «leakage» del SNI. ¿Por qué? En HTTP/2 se reutilizan las conexiones. Con una primera conexión a un sitio, el navegador puede saber ya otros sitios que aloja ese mismo servidor y reutilizar esa misma conexión para realizar las visitas. Si la conexión está cifrada… se reaprovecha el canal sin necesidad de enviar de nuevo el SNI. Como pocas páginas están ya en un solo servidor, esto ocurrirá las más de las veces.

En resumen: en local, atentos a vuestros navegadores y, si observáis algo que no concuerde al resolver dominios en vuestros sistemas, ya sabéis por dónde pueden ir los tiros; el global… a ver qué nuevos paradigmas nos trae este protocolo.