mhr-cfw: domain fronting con GAS para eludir DPI

mhr-cfw es un relay de domain fronting que enruta tráfico a través de Google Apps Script (GAS) y lo reenvía a un Cloudflare Worker, con el objetivo de eludir la inspección profunda de paquetes (DPI) ocultando el destino real de las conexiones HTTPS detrás de dominios legítimos de Google.

Google es una empresa multinacional de tecnología estadounidense fundada en 1998 por Larry Page y Sergey Brin que desarrolla servicios de búsqueda, publicidad, productividad en la nube y herramientas de desarrollo.

¿Qué es mhr-cfw? Definición y arquitectura

mhr-cfw es una herramienta de evasión de red que implementa domain fronting usando Google Apps Script como nodo de relay y Cloudflare Workers como destino final del tráfico. El nombre viene de “Master HTTP Relay + Cloudflare Worker” (hay una variante en Rust llamada MasterHttpRelayVPN-RUST que sigue la misma lógica pero con mejor rendimiento).

El flujo de tráfico es así: tu navegador se conecta al proxy local en 127.0.0.1:8085, ese proxy arma una petición HTTPS hacia un endpoint de Google Apps Script, GAS la reenvía al Cloudflare Worker, y el Worker finalmente llega al destino real. Desde afuera, un firewall con DPI ve solo tráfico cifrado hacia dominios de Google. El destino real queda opaco.

La arquitectura en capas es lo que lo hace interesante. No es un simple proxy: tiene tres nodos intermedios, cada uno con un rol técnico específico.

Domain Fronting: La técnica detrás de la elusión de DPI con domain fronting

Ponele que tu ISP tiene un firewall que bloquea acceso a ciertos servicios. Cuando abrís una conexión HTTPS, el handshake TLS incluye el campo SNI (Server Name Indication) en texto plano, antes del cifrado. El firewall lee ese SNI y decide si bloquear o no.

Domain fronting abusa de una discrepancia entre dos campos: el SNI del TLS (visible al firewall) y el header Host del HTTP interno (visible solo al servidor de destino, ya cifrado). Ponés en el SNI un dominio legítimo y permitido, como script.google.com. Pero dentro del tráfico cifrado, el header Host apunta al worker real. El CDN o la infraestructura de Google recibe la conexión y la enruta según ese header interno.

¿Por qué funciona? Porque las grandes CDNs y servicios cloud comparten infraestructura de IP. Cuando te conectás a script.google.com, llegás a servidores de Google que también sirven miles de otros dominios. El firewall bloquea por SNI/dominio, no por IP. Google no puede bloquear su propia IP. En infraestructura de Google profundizamos sobre esto.

La diferencia con otras técnicas de bypass DPI es que domain fronting no requiere modificar el protocolo TLS ni instalar software especial en el destino. Usa la infraestructura existente de terceros como “prestada”.

Componentes técnicos: Google Apps Script y Cloudflare Workers

GAS (Google Apps Script) en este esquema no es un simple redirector. Tiene que estar correctamente configurado como web app con permisos de ejecución pública, y genera un Deployment ID único que el cliente usa para identificar el endpoint. Ese ID es la “dirección” del relay dentro de la infraestructura de Google. Sin la autenticación correcta, el script rechaza las peticiones.

Cloudflare Workers es el destino final dentro del sistema. Recibe las peticiones que GAS le reenvía y las dirige al servidor real. La gracia de usar Workers es que también se aloja en una infraestructura masiva y compartida, lo que hace difícil el bloqueo por IP sin daño colateral para el bloqueador.

El proxy local corre en 127.0.0.1:8085 y es el componente que vos configurás en el navegador. Con FoxyProxy podés hacer que solo el tráfico que querés pase por ahí, sin afectar el resto de tu navegación. El cliente Python arma las peticiones, inyecta los headers correctos y maneja la discrepancia SNI/Host que hace funcionar todo el esquema.

Inspección Profunda de Paquetes (DPI): El objetivo a eludir

DPI no lee solo los headers de red como hace un firewall clásico. Analiza el payload completo de los paquetes, incluyendo protocolos de aplicación. Un router con DPI puede identificar tráfico de BitTorrent aunque uses un puerto no estándar, detectar VoIP, reconocer patrones de Tor, o bloquear servicios específicos aunque estén cifrados si hay fingerprinting del protocolo.

En el contexto de HTTPS, el punto débil histórico fue el campo SNI, que hasta la llegada de ECH (Encrypted Client Hello) viajaba en texto plano. Un firewall con DPI lee ese SNI y bloquea la conexión antes de que se complete el handshake TLS. Sin acceso al contenido cifrado, sin necesidad de un ataque man-in-the-middle. Ya lo cubrimos antes en distribución geográfica de tráfico.

Los ISPs en países con censura usan DPI a escala nacional. Pero también lo usan empresas en sus redes corporativas, gobiernos para monitoreo, y hasta algunos routers domésticos “inteligentes” para control parental. Los usos legítimos existen (seguridad de red, QoS), pero el mismo mecanismo que prioriza tráfico de videoconferencias es el que bloquea Signal en ciertos países.

Instalación, configuración y uso práctico

Necesitás tres cosas antes de arrancar: una cuenta de Google (para GAS), una cuenta de Cloudflare (para el Worker, el plan gratuito alcanza), y Python instalado localmente.

El proceso general según el repositorio:

• Desplegá el script de GAS como web app en tu cuenta de Google, configurando acceso público de ejecución. Guardá el Deployment ID que genera.
• Desplegá el Worker en Cloudflare con el código incluido en el repo. El Worker actúa como proxy final y necesita estar configurado para aceptar las peticiones de GAS.
• Configurá las credenciales en el cliente Python: Deployment ID de GAS, URL del Worker, y cualquier token de autenticación que hayas configurado.
• Ejecutá el proxy local con Python. Queda escuchando en 127.0.0.1:8085.
• Configurá FoxyProxy (o el proxy del sistema) para rutear el tráfico deseado por ese puerto.

Ojo: la configuración no es trivial para alguien sin experiencia en GAS o Cloudflare Workers. Y hay un punto crítico que el README no siempre aclara bien: si tu Deployment ID de GAS se desactiva o Google detecta abuso, el relay se cae sin aviso.

Casos de uso reales: desde censura hasta investigación

El historial de domain fronting tiene nombres concretos. Signal lo usó para seguir funcionando en Egipto, Omán, Qatar y los Emiratos Árabes entre 2016 y 2018, usando Amazon CloudFront como frente. Telegram usó AWS de la misma manera cuando Rusia intentó bloquearlo en 2018. Tor implementó domain fronting en su mecanismo de transporte “meek” para eludir bloqueos de los nodos de Tor, usando tanto Google como Azure como fronts.

Ese último caso es interesante porque ilustra la diferencia entre usar la técnica para privacidad legítima versus para ofuscación maliciosa. Los mismos mecanismos técnicos sirven para que un periodista en un país autoritario acceda a información, y también aparecen en el framework MITRE ATT&CK bajo la técnica T1090.004 como táctica de Command & Control usada por actores de amenaza.

Desde el punto de vista de seguridad ofensiva, esto no es un secreto ni una novedad. Lo interesante de mhr-cfw es que intenta mantener la técnica operativa en 2026, cuando los grandes proveedores ya cerraron el agujero.

Detección y contrameasuras: ¿cuán efectivo es hoy?

La respuesta corta: limitado. Google bloqueó domain fronting en su infraestructura en 2018. AWS hizo lo mismo ese año con CloudFront. Cloudflare tiene sus propias políticas al respecto. Cubrimos ese tema en detalle en comparativa de proveedores cloud.

Hay varios métodos de detección que los firewalls modernos implementan. El más directo es comparar el SNI del TLS con el header Host del HTTP interno (requiere terminación TLS en el firewall, es decir, un ataque MITM explícito sobre los usuarios). Otro es análisis de tráfico: si ves miles de conexiones a script.google.com desde una IP corporativa, algo raro está pasando. Palo Alto Networks documentó en PAN-OS 10.2 capacidades específicas de detección de domain fronting.

El problema fundamental que mhr-cfw no resuelve: si Google decide que tu Deployment ID de GAS está siendo usado como relay y lo suspende, terminó el juego. Google tiene visibility total sobre su propia infraestructura.

Limitaciones y evolución: por qué el domain fronting clásico quedó obsoleto

Cuando Google y AWS bloquearon domain fronting en 2018, lo hicieron por una razón práctica: actores maliciosos (incluyendo APTs estatales) lo usaban para C2 de malware. Ocultar tráfico malicioso detrás de google.com es un problema reputacional y legal para Google, que no tiene incentivo en mantener ese agujero abierto.

Las técnicas que evolucionaron post-2020 son más sofisticadas. ECH (Encrypted Client Hello) cifra el SNI completo, haciendo que el campo sea ilegible para el firewall sin terminar TLS. NaiveProxy usa el protocolo HTTP/2 de Chrome para mimetizarse con tráfico de navegador real. La fragmentación TLS divide el handshake en paquetes pequeños para confundir sistemas de fingerprinting. NoDPI es otra aproximación que analiza el problema desde un ángulo diferente.

mhr-cfw intenta mantener vivo el approach de domain fronting usando GAS como intermediario, pero está en una carrera contra las políticas de los propios servicios que explota. ¿Alguien verificó que funcione de forma consistente en 2026? La documentación del repo no tiene casos de uso documentados recientes, lo que es una señal de alerta.

Comparativa: técnicas de evasión DPI en 2026

Errores comunes al intentar implementar este tipo de soluciones

Error 1: Asumir que domain fronting sigue funcionando en CDNs grandes. Si buscás tutoriales de 2017 sobre domain fronting con CloudFront o Google CDN, lo que vas a encontrar ya no funciona. Los grandes proveedores cerraron esa puerta hace años. mhr-cfw trabaja con GAS, que es una superficie diferente, pero también sujeta a las políticas de Google.

Error 2: Creer que el tráfico es completamente invisible. Domain fronting oculta el destino al nivel de SNI, pero no esconde el patrón de tráfico ni el volumen. Un análisis de flujo de red puede levantar alertas aunque no se vea el contenido. La “invisibilidad” es parcial.

Error 3: Ignorar los términos de servicio de GAS y Cloudflare Workers. Usar estos servicios como relay de evasión viola los ToS de ambas plataformas. Eso no es un argumento moral, es un dato operativo: tu Deployment ID o tu Worker pueden ser suspendidos sin previo aviso, dejando el sistema sin funcionar en el momento que más lo necesitás. Sobre eso hablamos en infraestructura de GitHub.

Preguntas Frecuentes

¿Qué es mhr-cfw y cómo funciona?

mhr-cfw es un relay de domain fronting que usa Google Apps Script como intermediario y Cloudflare Workers como punto de salida para eludir sistemas de inspección de tráfico. El cliente local arma peticiones HTTPS que parecen ir a dominios de Google, pero internamente el tráfico se redirige al worker que definiste, ocultando el destino real al firewall o ISP que intercepta la conexión.

¿Cómo elude la inspección profunda de paquetes (DPI)?

DPI lee el campo SNI del handshake TLS, que viaja en texto plano antes del cifrado. Domain fronting pone en el SNI un dominio legítimo (como script.google.com) mientras el header HTTP interno, ya cifrado, apunta al destino real. El firewall ve solo el SNI y permite la conexión porque el dominio es conocido y confiable.

¿Cuál es la diferencia entre domain fronting y otros bypasses DPI?

Domain fronting abusa de infraestructura compartida de terceros (CDNs, servicios cloud) sin modificar el protocolo TLS. Otras técnicas como ECH cifran directamente el SNI, NaiveProxy mimetiza tráfico de Chrome, y la fragmentación TLS divide el handshake para confundir el análisis. Domain fronting es más antiguo y hoy más detectable; ECH y NaiveProxy son opciones más robustas para 2026.

¿Es legal usar herramientas como mhr-cfw para evadir censura?

Depende del país y el contexto. En Argentina no hay legislación específica que prohíba usar proxies o herramientas de evasión para uso personal. En países con censura estatal activa, las leyes varían desde tolerancia hasta criminalización. Lo que sí es claro es que el uso viola los Términos de Servicio de Google Apps Script y posiblemente de Cloudflare Workers, con el riesgo de suspensión de cuenta.

¿Puedo usar Google Apps Script para ocultar mi tráfico de internet?

Técnicamente es posible con mhr-cfw, pero con limitaciones importantes. GAS tiene cuotas de ejecución diarias, no está diseñado para tráfico continuo de red, y Google puede suspender el Deployment ID si detecta uso anómalo. Para uso de producción o necesidades de privacidad serias, hay alternativas más estables como Tor con meek o NaiveProxy.

Conclusión

mhr-cfw es un proyecto técnicamente interesante que documenta cómo intentar mantener vivo el domain fronting en 2026, cuando los grandes CDNs cerraron esa puerta hace años. Usar GAS y Cloudflare Workers como relay es un approach creativo, pero frágil: depende de que Google no detecte y suspenda el Deployment ID, de que el Worker siga activo, y de que los patrones de tráfico no levanten alertas de análisis de flujo.

Para equipos de seguridad que necesitan entender estas técnicas con fines defensivos, el repositorio y el ecosistema alrededor de T1090.004 en MITRE ATT&CK son lecturas relevantes. Para alguien que necesita evasión de censura confiable, ECH (ya disponible en Firefox y Chrome) y NaiveProxy son opciones más sólidas hoy.

Lo que sí dejó claro este proyecto es que la batalla entre DPI y técnicas de evasión sigue activa, y que la infraestructura de cloud compartido sigue siendo un vector que los investigadores exploran, para bien y para mal.

Fuentes

• denuitt1/mhr-cfw en GitHub — repositorio oficial del proyecto
• MITRE ATT&CK T1090.004 — Domain Fronting como técnica de C2
• Palo Alto Networks PAN-OS 10.2 — Detección de domain fronting
• ElHacker.net — NoDPI y técnicas de evasión DPI en 2026
• MasterHttpRelayVPN-RUST — variante en Rust del mismo esquema