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.
