Chromium es un proyecto de software de código abierto que constituye la base del navegador web Chrome de Google, así como de varios otros productos de navegador, incluidos Microsoft Edge, Opera, Amazon Silk y Brave. Desde su introducción en 2008, los navegadores basados en Chromium han aumentado de manera constante en popularidad y hoy representan aproximadamente el 70% de la participación de mercado.
Chromium ha incluido, desde sus inicios, una función conocida como omnibox, que permite a los usuarios ingresar el nombre de un sitio web, URL o términos de búsqueda. Pero el omnibox tiene un desafío de interfaz. El usuario puede ingresar una palabra como «marketing» que podría referirse tanto a un sitio web (intranet) como a un término de búsqueda. ¿Qué debería elegir el navegador para mostrar? Chromium lo trata como un término de búsqueda, pero también muestra una barra de información que dice algo como «¿quiso decir http: // marketing /?» si una búsqueda de DNS en segundo plano para el nombre da como resultado una dirección IP.
En este punto, surge un nuevo problema. Algunas redes (por ejemplo, ISP) utilizan productos o servicios diseñados para interceptar y capturar el tráfico de nombres de dominio mal escritos. Esto a veces se conoce como «secuestro de NXDomain». A los usuarios de estas redes se les puede mostrar la barra de información «quiso decir» en cada búsqueda de un solo término. Para solucionar este problema, Chromium necesita saber si puede confiar en la red para proporcionar respuestas DNS no interceptadas.
Como resuelva Chromium
Dentro del código fuente de Chromium, hay un archivo llamado intranet_redirect_detector.c. Las funciones de este archivo intentan cargar tres URL, cuyos nombres de host consisten en un nombre de dominio de etiqueta única generado aleatoriamente, como se muestra a continuación:
Este código da como resultado tres búsquedas de URL, como http: // rociwefoie /, http: // uawfkfrefre / y http: // awoimveroi /, y estas, a su vez, dan como resultado tres búsquedas de DNS para los nombres de host aleatorios. Como se puede deducir del código fuente, estos nombres aleatorios tienen de 7 a 15 caracteres de longitud (línea 151) y constan solo de las letras a-z (línea 153). En las versiones del código anteriores a febrero de 2014, los nombres aleatorios siempre tenían 10 caracteres de longitud.
Las funciones del detector de redireccionamiento de la intranet se ejecutan cada vez que se inicia el navegador, cada vez que cambia la dirección IP del sistema / dispositivo y cada vez que cambia la configuración de DNS del sistema / dispositivo. Si dos de estas búsquedas se resuelven en la misma dirección, esa dirección se almacena como el origen de redireccionamiento del navegador.
Identificación de consultas de Chromium
Casi cualquier mirada superficial al tráfico del servidor de nombres raíz mostrará consultas de nombres que se parecen a los utilizados en las consultas de prueba de Chromium. Por ejemplo, aquí hay 20 consultas secuenciales recibidas en una instancia de a.root-servers.net:
$ /usr/sbin/tcpdump -n -c 20 …
20:01:34.063474 IP x.x.x.x.7288 > 198.41.0.4.domain: 34260% [1au] A? ip-10-218-80-155. (45)
20:01:34.063474 IP x.x.x.x.31500 > 198.41.0.4.domain: 64756 [1au] AAAA? fwhjxbnoicuu. (41)
20:01:34.063474 IP x.x.x.x.46073 > 198.41.0.4.domain: 13606 A? cluster1-1.cluster1.etcd. (42)
20:01:34.064413 IP6 x:x:x::x.9905 > 2001:503:ba3e::2:30.domain: 52824 [1au] A? xxnwikspwxdw. (53)
20:01:34.064413 IP x.x.x.x.30251 > 198.41.0.4.domain: 9286% [1au] AAAA? cxhplqrpuuck.home. (46)
20:01:34.064413 IP x.x.x.x.56760 > 198.41.0.4.domain: 60980% [1au] A? ofydbfct.home. (42)
20:01:34.065295 IP x.x.x.x.15410 > 198.41.0.4.domain: 21829% [1au] A? wwtsjikkls. (39)
20:01:34.065295 IP6 x:x:x::x.58815 > 2001:503:ba3e::2:30.domain: Flags [.], ack 3919467200, win 30118, length 0
20:01:34.065295 IP6 x:x:x::x.58815 > 2001:503:ba3e::2:30.domain: Flags [F.], seq 0, ack 1, win 30118, length 0
20:01:34.065295 IP x.x.x.x.17442 > 198.41.0.4.domain: 32435% [1au] A? agawwhcwueppouu. (44)
20:01:34.065295 IP x.x.x.x.35247 > 198.41.0.4.domain: 1328% [1au] A? dev-app.stormwind.local. (52)
20:01:34.065295 IP x.x.x.x.18462 > 198.41.0.4.domain: 23433% [1au] AAAA? liffezmsdw.home. (44)
20:01:34.065295 IP x.x.x.x.40905 > 198.41.0.4.domain: 40371% [1au] A? sqtpvvmi.home. (42)
20:01:34.066283 IP x.x.x.x.18125 > 198.41.0.4.domain: 45688% [1au] A? kktaruyy. (37)
20:01:34.066283 IP x.x.x.x.7986 > 198.41.0.4.domain: 60608 [1au] A? bpbutdlihan. (40)
20:01:34.066283 IP x.x.x.x.53489 > 198.41.0.4.domain: 27734% [1au] A? ip-100-65-32-140. (45)
20:01:34.066283 IP x.x.x.x.54028 > 198.41.0.4.domain: 41670 A? qvo7-itirqg3g.www.rabbitair.co.uk.notary-production. (69)
20:01:34.066283 IP x.x.x.x.43866 > 198.41.0.4.domain: 21093% [1au] A? ip-10-0-71-17. (42)
20:01:34.066283 IP x.x.x.x.41141 > 198.41.0.4.domain: 49747% [1au] A? edu. (32)
20:01:34.066283 IP x.x.x.x.36283 > 198.41.0.4.domain: 65449% [1au] SRV? _ldap._tcp.dc._msdcs.mwaa.local. (60)En este breve fragmento de datos, podemos ver seis consultas para nombres aleatorios de una sola etiqueta, y otras cuatro con primeras etiquetas aleatorias seguidas de un aparente sufijo de búsqueda de dominio. Estos coinciden con el patrón del código fuente de Chromium, tienen entre 7 y 15 caracteres de longitud y constan solo de las letras a-z.
Para caracterizar la cantidad de tráfico de la sonda Chromium en grandes cantidades de datos (es decir, que cubren un período de 24 horas), tabulamos las consultas en función de los siguientes atributos:
- Código de respuesta (NXDomain o NoError)
- Popularidad de la etiqueta situada más a la izquierda
- Longitud de la etiqueta más a la izquierda
- Caracteres usados en la etiqueta más a la izquierda
- Número de etiquetas en el nombre completo de la consulta
La figura anterior muestra una clasificación de datos de a.root-servers.net el 13 de mayo de 2020. Aquí podemos ver que el 51% de todos los nombres consultados se observaron menos de cuatro veces en el período de 24 horas. De ellos, casi todos eran para TLD inexistentes, aunque una cantidad muy pequeña proviene de los TLD existentes (etiquetados “YXD” a la izquierda). Esta pequeña franja representa falsos positivos o consultas de sondeo de Chromium que han estado sujetas a búsquedas de sufijos de dominio añadidas por solucionadores de códigos auxiliares o aplicaciones de usuario final.
Del 51% observado menos de cuatro veces, todos menos el 2,86% de estos tienen una primera etiqueta de entre 7 y 15 caracteres de longitud (inclusive). Además, la mayoría de estos coinciden con el patrón que consta solo de caracteres a-z (no distinguen entre mayúsculas y minúsculas), lo que nos deja con el 45,80% del tráfico total en este día que parece provenir de sondas de Chromium.
A partir de ahí, hemos desglosado las consultas por el número de etiquetas y la longitud de la primera etiqueta. Ten en cuenta que las longitudes de las etiquetas (en el extremo derecho del gráfico) tienen una distribución muy uniforme, excepto para 7 y 10 caracteres. Las etiquetas con 10 caracteres son más populares porque las versiones anteriores de Chromium solo generaban nombres de 10 caracteres. Creemos que 7 es menos popular debido a la mayor probabilidad de colisiones en solo 7 caracteres, lo que puede aumentar el recuento de consultas por encima de nuestro umbral de tres.
Análisis longitudinal
A continuación, centramos nuestra atención en el análisis de cómo el porcentaje de tráfico raíz total de las consultas similares a Chromium ha cambiado con el tiempo. Usamos dos conjuntos de datos en este análisis: datos de las colecciones «Day In The Life» (DITL) de DNS-OARC y datos de Verisign para a.root-servers.net y j.root-servers.net.
La Figura anterior muestra los resultados del análisis a largo plazo. Se analizaron los datos DITL anuales de 2006-2014 y de 2017-2018, etiquetados como «DITL completo» en la figura. Los datos de 2015-2016 no estaban disponibles en los sistemas DNS-OARC. El conjunto de datos de 2019 no se pudo analizar en su totalidad debido a su tamaño, por lo que se conformó con un análisis de muestra, etiquetado como «DITL Sampled» en la Figura anterior.
En cada conjunto de datos DITL, se analizó la identidad de cada servidor raíz («letra») por separado. Esto produce un rango de valores para cada año. La línea continua muestra el promedio de todas las identidades, mientras que el área sombreada muestra el rango de valores.
Para llenar algunos de los vacíos DITL, se usaron los datos de Verisign para a.root-servers.net y j.root-servers.net. Aquí se seleccionó un período de 24 horas para cada mes. Nuevamente, la línea continua muestra el promedio y el área sombreada representa el rango.
La figura también incluye una línea denominada «Cuota de mercado de Chrome» (nota: Chrome, no navegadores basados en Chromium) y un marcador que indica cuándo se agregó la función por primera vez al código fuente.
Se observaron algunas consultas falsas positivas similares a Chromium en los datos DITL antes de la introducción de la función, que comprendían aproximadamente el 1% del tráfico total, pero en los más de 10 años desde que se añadió la función, ahora encontramos que la mitad del DNS Es muy probable que el tráfico del servidor raíz se deba a las sondas de Chromium. Eso equivale a alrededor de 60 mil millones de consultas al sistema del servidor raíz en un día normal.
La interceptación es la excepción más que la norma
El sistema del servidor raíz está, por necesidad, diseñado para manejar grandes cantidades de tráfico. Como hemos mostrado aquí, en condiciones normales de funcionamiento, la mitad del tráfico se origina con una única función de biblioteca, en una única plataforma de navegador, cuyo único propósito es detectar la interceptación de DNS. Esta interceptación es ciertamente la excepción y no la norma. En casi cualquier otro escenario, este tráfico sería indistinguible de un ataque distribuido de denegación de servicio (DDoS).
¿Podría Chromium lograr su objetivo enviando solo una o dos consultas en lugar de tres? ¿Son factibles otros enfoques? Por ejemplo, la prueba del portal cautivo de Firefox utiliza consultas de sonda de espacio de nombres delegadas, dirigiéndolas lejos de los servidores raíz hacia la infraestructura del navegador.
Si bien las soluciones técnicas como Aggressive NSEC Caching (RFC 8198), Qname Minimization (RFC 7816) y NXDomain Cut (RFC 8020) también podrían reducir significativamente las consultas de sondeo al sistema del servidor raíz, estas soluciones requieren la acción de los operadores de resolución recursivos, que han Incentivo limitado para implementar y soportar estas tecnologías.
