Pluggable transports en TOR para la evasión de Deep Packet Inspection

Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.

Funcionamiento de los Pluggable Transports en TOR

Pluggable Transports en TOR con Obsproxy

La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.

Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.

Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.

Configuración del cliente de TOR Browser

Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.

Selección de un PT en Tor Browser

Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.

El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.

Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239

Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9

Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A

Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED

DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor

GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip

GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6

UseBridges 1

Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.

Saludos y Happy Hack!
Adastra.