uBlock Origin modifica el código de CNAME uncloaking para reflejar la opción ipaddress=

 (github.com/gorhill)
1 puntos por GN⁺ 2024-10-08 | 1 comentarios | Compartir por WhatsApp
  • Un commit de uBlock Origin reescribe el flujo de CNAME uncloaking en el procesamiento de red de Firefox y cambia el comportamiento para reflejar en details.ip la IP obtenida mediante la consulta DNS
  • La caché cnames Map existente desaparece y se reemplaza por un ring buffer de 256 entradas basado en dnsList, dnsDict y dnsWritePtr, con una caché TTL de 60000ms
  • La consulta DNS usa browser.dns.resolve(hn, [ 'canonical_name' ]), y utiliza canonicalName y addresses[0] del resultado como CNAME e IP, respectivamente
  • El manejo de excepciones de CNAME mantiene las condiciones de 1st-party, lista de ignorados y documento raíz, y excluye de la reconsulta las direcciones IPv4 o los nombres de host que empiezan con [
  • La versión mínima de Chromium sube a 80.0, la de Opera a 67.0, y se elimina el valor predeterminado cnameMaxTTL de la configuración oculta

Reescritura de la estructura de caché DNS en Firefox

  • El código relacionado con CNAME uncloaking en platform/firefox/vapi-background-ext.js pasa de una estructura centrada en un Map global a una estructura de caché DNS dentro de una clase
  • En lugar del estado global cnameUncloakEnabled y el Map cnames existentes, la caché se administra con los siguientes campos
    • dnsList: ring buffer
    • dnsWritePtr: siguiente posición de escritura
    • dnsMaxCount: máximo de 256
    • dnsDict: mapeo de nombres de host a índices del ring buffer
    • dnsEntryTTL: 60000ms
  • En el constructor, canUncloakCnames y cnameUncloakEnabled se inicializan en true

Flujo de procesamiento de solicitudes

  • onBeforeSuspendableRequest(details) extrae el nombre de host de la URL solicitada y primero revisa la caché con dnsFromCache(hn)
  • Si la entrada DNS en caché tiene ip, la configura en details.ip
  • Si el resultado de llamar al super.onBeforeSuspendableRequest(details) base termina en cancelación, redirección, etc., devuelve ese resultado tal cual
  • Si la entrada DNS en caché no es una Promise, continúa el procesamiento posterior con onAfterDNSResolution(hn, details, dnsEntry)
  • Si no se cumplen las condiciones para una nueva consulta DNS o existe details.proxyInfo?.proxyDNS, no realiza procesamiento DNS adicional

Consulta DNS y método de almacenamiento

  • dnsShouldResolve(hn) excluye de las consultas DNS los nombres de host vacíos, los nombres de host que empiezan con [ y las formas de dirección IPv4
  • dnsResolve(hn, details) registra el nombre de host en la posición actual del ring buffer y llama a dnsAPI.resolve(hn, [ 'canonical_name' ])
  • Si la consulta tiene éxito, se ejecuta dnsToCache(hn, rec, details); si falla, deja una entrada vacía en la caché con dnsToCache(hn)
  • dnsToCache guarda hn y la hora de expiración en una nueva entrada de caché
    • Si cnameFromRecord devuelve un valor, lo guarda en dnsEntry.cname
    • Si ipFromRecord devuelve un valor, lo guarda en dnsEntry.ip
  • dnsFromCache devuelve tal cual una entrada de caché si es una Promise, y elimina las entradas vencidas de dnsList y dnsDict

Condiciones para reflejar CNAME e IP

  • cnameFromRecord(hn, record, details) no devuelve un CNAME si record.canonicalName no existe o es igual al nombre de host original
  • Si cnameIgnore1stParty está activado, excluye los casos en que el CNAME y el dominio del nombre de host original son iguales
  • Si existe cnameIgnoreList, se excluyen los CNAME que no coinciden con esa expresión regular
  • Si cnameIgnoreRootDocument está activado, excluye el caso en que el nombre de host de la solicitud es igual al nombre de host de details.documentUrl || details.url
  • ipFromRecord(record) devuelve la primera dirección addresses[0] cuando record.addresses es un arreglo y no está vacío

Reescritura de URL y filtrado posterior

  • onAfterDNSResolution reescribe la URL con uncloakURL si la entrada DNS tiene CNAME y cnameUncloakEnabled está activado
  • Al cambiar la URL, guarda la URL existente en details.aliasURL y refleja la nueva URL en details.url
  • Si la entrada DNS tiene IP y esta difiere de la details.ip actual, actualiza details.ip
  • Solo cuando ocurre una reescritura de CNAME o un cambio de IP vuelve a llamar a onBeforeSuspendableRequest(details) de la clase base
  • uncloakURL encuentra la posición del nombre de host dentro de la URL y la reemplaza por el CNAME; según el valor de cnameReplayFullURL, concatena la URL completa o conserva solo hasta el inicio de la ruta

Cambios en configuración y manifest

  • Se elimina el manejo de cnameMaxTTL en setOptions
  • Al cambiar opciones, en lugar de inicializar el Map cnames existente, se vacía la caché DNS con dnsList.fill(null) y dnsDict.clear()
  • Se elimina cnameMaxTTL: 120 de los valores predeterminados de configuración oculta en src/js/background.js
  • minimum_chrome_version en platform/chromium/manifest.json cambia de 73.0 a 80.0
  • minimum_opera_version en platform/opera/manifest.json cambia de 60.0 a 67.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-08
Opiniones de Hacker News

  • Creo que el título está mal. uBlock Origin ya soportaba esta función desde hace varios años, pero solo era posible en Firefox.
    Este caso parece más una refactorización de ese código que una función completamente nueva.

    • Todavía la soporta, y antes también la soportaba :P
    • Parece más que una simple refactorización. Ahora parece que el bloqueo basado en IP puede hacerse en una etapa más temprana, antes de que salga la solicitud real.
      Aunque no es perfecto, porque cuando un dominio tiene varias IP no se puede saber cuál elegirá el navegador.
    • Volví a poner el título de la página. El título enviado era “uBlock Origin supports filtering CNAME cloaking sites on Firefox now”.
      Si proponen un título más preciso y neutral, se puede volver a cambiar. Pero, sin contexto adicional, un commit de GitHub normalmente no es muy buen material para un hilo de HN.

  • Aunque todavía no me ha afectado directamente, ya estoy retocando mis extensiones para Firefox, para poder cambiarme si Chrome de verdad elimina uBO.

    • No es cuestión de “si”, sino de “cuándo”. Desde 2020 ya era un “cuándo”, y de hecho está llegando.
      Llegará dentro de unas cuantas versiones, así que hay que prepararse.
    • Estoy pasando a mi familia a Brave. Casi no notan la diferencia, y tengo más confianza en que el navegador seguirá soportando filtrado de contenido centrado en el usuario.
    • Ya fue eliminado en los lanzamientos Canary.
    • No sé qué significa eso de “reescribir las extensiones para Firefox”. Firefox usa la misma API.
      Como mucho, sería cambiar background.service_worker por background.scripts; literalmente solo cambiar el nombre de la clave.
    • Para quienes no sabemos bien del tema: ¿qué es uBO y cómo afecta a la mayoría de las extensiones?

  • uBlock Origin es algo que hace que Firefox sea mucho mejor, y una de las principales razones para usar Firefox en lugar de Chrome y otros.
    Hace que internet sea realmente navegable.

    • Me pasé a esta combinación hace unos años y nunca vi motivo para irme. También en teléfonos Android: es la única experiencia web móvil usable que he visto.
      Durante más de 10 años hubo problemas de visualización en algunos sitios, pero esos sitios también tenían problemas en Chrome.
      Personalmente, considero que la publicidad es como un cáncer de la sociedad moderna. Mezcla mentiras piadosas y mentiras que no lo son, además de manipulación, y el hecho de que mueva cantidades enormes de dinero hace que sea todavía menos respetable.
    • Eso podría cambiar, porque Mozilla se está convirtiendo en una empresa de publicidad.
    • He usado tanto Brave como Firefox y, honestamente, no noté una gran diferencia. Aun así, prefiero Firefox por su filosofía y porque viene de una organización sin fines de lucro.
      Brave también es un proyecto de buena calidad, así que lo uso como respaldo, y a veces también mezclo Vivaldi por la división de ventanas y una gestión de pestañas mucho mejor.

  • ¿CNAME cloaking se refiere a que los sitios de anuncios usan subdominios generados al azar que apuntan a registros wildcard?

    • Eso es parte de la idea.
      Normalmente, cuando visitas contentsite.com, los anuncios se sirven desde adsite.com. Si las reglas de bloqueo de anuncios bloquean adsite.com, no ves los anuncios.
      El CNAME cloaking consiste en que el sitio principal haga que un subdominio como adsite.contentsite.com apunte a adsite.com. Entonces el bloqueador de anuncios queda ante una tarea casi imposible: bloquear millones de subdominios que parecen pertenecer a un sitio legítimo.
      El sitio legítimo puede seguir cambiando de subdominios, y el bloqueador de anuncios no tiene forma de saber qué subdominio es contenido legítimo y cuál es publicidad. Además, como el contenido se sirve desde el mismo dominio, también puede eludir algunas políticas de cookies para rastrear mejor a los usuarios.
      Esta actualización permite configurar reglas que filtran según la IP resuelta.
    • Correcto. Los proveedores de publicidad y analítica empezaron a usar este método para eludir las protecciones contra cookies de terceros.

  • Este es un buen ejemplo de por qué Manifest V3 es malo. Por definición no puede hacer cosas como esta, y tampoco permite heurísticas basadas en código en tiempo de ejecución.
    Es una carrera armamentista contra los anunciantes, y Google es el vendedor de armas que le vende a ambos bandos. No va a darle a los usuarios lo que necesitan para ganar.

    • No hay razón para que la API declarativa de Manifest V3 no pueda ofrecer esta función. Si leí bien el commit, incluso podría funcionar mejor si se integra mejor en el flujo de solicitudes antes de enviar cualquier cosa al servidor real, bloqueando según la dirección IP que se usará efectivamente.
      Por supuesto, todo esto depende de si el proveedor del navegador, es decir Google, quiere agregar esa API. Poder hacer procesamiento imperativo con “código en tiempo de ejecución” permite innovar en el espacio de usuario antes de que los fabricantes del navegador incorporen soporte nativo.
    • Técnicamente, Manifest V3 en sí es independiente de la API que el navegador ofrece a las extensiones. En Firefox, Manifest V3 se soporta junto con solicitudes web bloqueantes[1], que es la API de filtrado anterior a “Manifest V3”.
      Por lo tanto, decir que cierta función es imposible “por definición” es incorrecto.
      [1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
    • Basta con abandonar Chrome y adoptar Firefox

  • CNAME cloaking. Por ejemplo, supongamos que el proveedor SaaS A quiere ofrecerle a la empresa Q un excelente software de seguimiento publicitario.
    Con el método antiguo, A le habría dicho a Q que insertara en su sitio web, ubicado en https://q-company.example, un script de, por ejemplo, https://A-ads-tracking.example.
    Entonces, en las listas de bloqueo que usa uBlock Origin aparecería una regla como “bloquear las solicitudes al dominio A-ads-tracking.example”, y los anuncios quedarían bloqueados.
    El CNAME cloaking consiste en que el proveedor SaaS A no aloja el servicio de seguimiento publicitario en el dominio A-ads-tracking.example, sino en una dirección IP específica, por ejemplo 29.1.2.3. Y la parte importante es que SaaS A le pide a la empresa Q que cree un subdominio de q-company.example y que su registro CNAME apunte a 23.1.2.3. Le ponen un nombre plausible, como media.q-company.example.
    Después de que la empresa Q configura ese CNAME y agrega al sitio web una etiqueta de script para media.q-company.example, SaaS A puede rastrear a todos los usuarios de ese sitio. Por esta capa de evasión, se genera en la práctica un juego infinito del gato y el ratón entre los dueños de la empresa Q y las listas públicas de bloqueo.
    Para evitar este problema, el software que ejecuta extensiones como uBlock Origin debe poder ver no solo el dominio de destino de la solicitud del navegador, sino también la dirección IP real de ese dominio. Este commit parece estar relacionado con habilitar ese comportamiento o, al menos, hacer que ese código funcione mejor.

    • Para ser precisos, es un poco distinto. Como su nombre lo indica, usa CNAME, que no es un registro A que apunta a una IP, sino un registro que apunta a otro registro.
      Por ejemplo, media.q-company.example podría ser un CNAME que apunta a q-company.ads-tracking.example, y luego q-company.ads-tracking.example tendría un registro A que devuelve la IP.
      No sé si el navegador les proporciona a las extensiones los nombres DNS intermedios. Por eso, algo como uBlock quizá tenga que depender de listas de IP, pero un filtrado basado en DNS como pihole puede bloquearlo simplemente con una regla para ads-tracking.example.
      En cualquier caso, conviene usar tanto bloqueadores de contenido malicioso basados en navegador como basados en DNS.
    • Por eso, en el modo avanzado de uBlock, conviene bloquear todo JavaScript e ir agregando lentamente a la lista de permitidos los scripts visibles hasta que el sitio funcione correctamente.
      Es lento y propenso a errores, pero cuando te acostumbras se vuelve más fácil, y te vuelve completamente inmune a este tipo de tonterías.

  • ¿Chrome va a bloquear uBO? No siempre sigo la situación más reciente.
    Tengo entendido que ahora sí van a permitir las cookies de terceros, así que tal vez haya alguna posibilidad.

    • No van a bloquear uBO en sí, sino que, con la nueva API de plugins, Manifest V3, están eliminando las funciones del navegador que permitían que uBO funcionara.
      Están quitando las API clave que uBO necesita para identificar lo que no debe cargarse y luego impedir que se cargue.
      Google afirma que es por “rendimiento” o “seguridad”. Por supuesto, el único “rendimiento” o “seguridad” realmente afectado de forma importante es la capacidad de identificar, interceptar y detener descargas dañinas o relacionadas con publicidad antes de que comiencen.
    • También es riesgoso no actualizar el navegador. Es mucho mejor cambiarse a Firefox, recibir actualizaciones y tener soporte completo para uBO.
    • Lo están eliminando gradualmente durante un período largo para evitar que estalle de golpe la mala opinión pública sobre el monopolio de los navegadores. Pero ese calendario ya empezó en junio.
      https://developer.chrome.com/docs/extensions/develop/migrate...
      https://www.bleepingcomputer.com/news/google/google-chrome-w...
    • Por ahora, uBlock Origin todavía está en Chrome Web Store para navegadores Chromium que admiten Manifest V2.
      Si usas una versión de Chromium que solo admite Manifest V3, queda oculto.
    • Sinceramente, probablemente dependa de si EE. UU. mantiene una administración dispuesta a llevar a juicio a monopolios descarados.

  • ¿No hay algunos servidores DNS que tienen una función que se comporta como un CNAME resuelto por el servidor? Me refiero a cuando el administrador pone un registro que apunta a otro nombre DNS, pero el cliente solo ve registros A o AAAA.

    • Creo que te refieres a los registros ALIAS.

  • uBO tiene esta función desde hace bastante tiempo. Desde la versión 1.34.0, y desde la 1.25.0 en la configuración avanzada.
    https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...
    Recuerdo que fue más o menos en 2021.

  • ¿Cuál es el estado de uBO en Brave, Edge y Opera?

    • No me interesan los dos navegadores propietarios mencionados, pero Brave planea dar soporte parcial a Manifest V2 durante el mayor tiempo posible y mantener la compatibilidad con uBO.
      https://brave.com/blog/brave-shields-manifest-v3/
      Aunque no es estrictamente necesario. Brave tiene un bloqueador de anuncios integrado bastante potente y, la última vez que revisé, estaba compilado como código nativo, tenía mejor rendimiento que uBO y también admitía por completo las mismas listas de anuncios.