Meek y domain fronting: el puente de Tor que se esconde dentro de un CDN
Cada tipo de puente en Tor Browser es un ejercicio de disfraz, pero meek toma la ruta más ambiciosa: no remodela el tráfico de Tor en absoluto, simplemente lo transporta como cuerpo de peticiones HTTPS corrientes destinadas a una gran red de distribución de contenido. La técnica subyacente, el domain fronting, estuvo antes disponible en todos los grandes proveedores de nube. Una década después de su debut, sobrevive esencialmente en uno, y el despliegue de meek-azure es el último de esa familia de puentes que sigue en el menú.
Cómo el domain fronting oculta una conexión Tor
La debilidad que explota el domain fronting es que un handshake TLS entrega al censor una etiqueta cómoda: el campo Server Name Indication nombra el sitio visitado. El estudio de 2015 de David Fifield y colegas que llevó la técnica a la elusión de la censura describe cómo el fronting rompe ese vínculo. Un dominio aparece en el exterior de una petición HTTPS, en la consulta DNS y el handshake TLS, mientras un dominio distinto aparece en el interior, en la cabecera Host de HTTP. El censor solo ve la fachada. La cabecera Host es invisible para el censor pero visible para el CDN que recibe la petición, el cual la lee y reenvía la conexión al destino real. Bloquear el tráfico significaría bloquear un sitio web concurrido y ordinario junto con todos sus usuarios legítimos. meek convierte esa idea en un puente. El cliente envuelve fragmentos del tráfico Tor en peticiones POST HTTP y las empuja a través de un CDN con fronting hacia un puente que ejecuta meek-server, donde un identificador de sesión reensambla el flujo; cuando no hay nada pendiente, el cliente sigue enviando sondeos vacíos para que la conexión no enmudezca. En el diseño original esas peticiones se conducían incluso a través de un motor de navegador real, por lo que el estudio podía decir del tráfico resultante que parece un navegador, porque es un navegador.2018: las puertas delanteras se cierran
Todo el esquema descansaba en que los proveedores de nube toleraran el desajuste entre las dos capas, y en 2018 dejaron de hacerlo. Según el relato de Signal, Google avisó con 30 días del fin del soporte de domain fronting después de que Signal usara el fronting de App Engine para llegar a usuarios de Irán, a quienes la propia lectura de Google de la ley de sanciones estadounidense ya había dejado sin acceso. Semanas después, el 27 de abril de 2018, Amazon escribió a Signal advirtiendo que no tenía permiso para usar el dominio Souq.com como fachada, amenazó con suspender su cuenta de CloudFront e introdujo las Enhanced Domain Protections que acabaron con el fronting en todo el CDN. El Tor Project informó ese mismo mes de que ambas empresas cortaban el grifo y de que meek se había vuelto inservible sobre sus redes; Access Now contó alrededor de una docena de herramientas de derechos humanos afectadas, Signal y Telegram entre ellas. La conclusión de Signal fue tajante: el domain fronting como técnica de elusión de la censura se había vuelto en gran medida inviable, y su observación final capturó por qué los apagones no costaron nada a los censores."...no tuvieron que hacer nada más que esperar." - Signal, mayo de 2018
Por qué sobrevivió meek-azure
Un proveedor no se sumó a la retirada. El Tor Project señaló en su momento que la nube Azure de Microsoft seguía permitiendo el domain fronting, y el estudio de 2015 ya había observado una razón estructural: el CDN de Azure solo reenvía peticiones a dominios afines a Azure, mientras que el CloudFront de Amazon reenviaría a casi cualquier parte. El despliegue de meek en Azure se asienta por completo dentro de ese perímetro, con su punto final alojado en el propio CDN de Azure tras un dominio frontal controlado por Microsoft, de modo que la petición nunca cruza entre empresas sin relación. Cuando Google y Amazon dejaron de permitir que el nombre visible y el destino real discreparan, esa tolerancia interna bastó. El Tor Project advirtió desde el principio de que no había recibido aviso previo de los otros apagones, y de que la política de Azure también podía cambiar, una salvedad que ha acompañado a meek-azure desde entonces.El precio de esconderse a plena vista
Las propiedades que hacen difícil bloquear meek también lo hacen lento y caro. El salto extra de CDN y el diseño dirigido por peticiones recortaron las velocidades de descarga medidas en un factor de entre dos y tres en el estudio de 2015, y la guía actual de soporte de Tor es aún más clara: meek tiene una limitación de ancho de banda, así que la opción será bastante lenta. El dinero es la otra restricción. Alguien paga los cargos de salida del CDN por cada byte que mueve un puente meek, y la factura del despliegue original ascendió a 565 dólares en Azure, 3.292 en Google App Engine y 3.793 en CloudFront a lo largo del estudio. Los investigadores advirtieron además de que un adversario podía inflar esa factura a voluntad, el problema de denegación de servicio financiera demostrado cuando el Great Cannon cargó a sus objetivos decenas de miles de dólares en costes de ancho de banda en su alojamiento en la nube.Cuándo meek es la elección correcta
Para la mayoría de los usuarios censurados, meek es un respaldo, no la primera opción. La guía actual de Tor para China sugiere WebTunnel primero y lista meek y Snowflake como respaldos si falla. Las opciones habituales hacen cada una un compromiso distinto:- obfs4 revuelve el tráfico y es rápido y gratuito, pero cada puente es un servidor individual cuya dirección puede filtrarse o ser rastreada.
- Snowflake toma prestados proxies efímeros de voluntarios, fácil de escalar pero variable en velocidad.
- WebTunnel hace que Tor parezca una conexión HTTPS corriente a un servidor web sin necesidad de la cooperación de un gigante del CDN.
- meek se esconde tras uno de los dominios más transitados de la web y sobrevive a las listas blancas más estrictas, a baja velocidad.