Tor, nodos "Bridge" y ofuscación

Para que un usuario pueda conectarse a la red Tor, es necesario que sepa dónde conectarse. Por tanto, los nodos Tor públicos están registrados y localizados. Sus IP están identificadas.

Esto tiene dos problemas:

  • De cara al administrador de ese nodo Tor, su IP está registrada. Si ese administrador usa esa IP para más cosas que el servicio Tor, puede experimentar problemas de acceso a algunos recursos. Existen multitud de organizaciones que no permiten el acceso desde la red Tor. Aunque el administrador no esté utilizando Tor para entrar en el servicio, su IP es la de un nodo Tor.

    Alguien con conocimiento sabe que la red Tor está compuesta por dos tipos de nodos: nodos repetidores y nodos de salida. Los únicos nodos que se conectan a la red abierta son los nodos de salida. Aunque filtrar Tor sea feo, puestos a hacerlo deberían filtrarse solo los nodos Tor de salida. Los nodos repetidores, la mayoría de la red Tor, solo se conectan a otros nodos Tor. Que un proveedor de información filtre tu conexión porque tu IP es la misma que un nodo repetidor no es efectivo para prevenir ningún ataque y, en cambio, penaliza al pobre administrador de ese nodo Tor.

    Esto es un problema muy real. A fecha de febrero de 2016 organizaciones como la Xunta de Galicia, la organización gestora de dominios española, o la mismísima http://www.red.es/ filtran el acceso desde IP de Tor, aunque se trate de nodos repetidores.

    Algunos tweets al respecto: 1, 2, 3.

  • De cara a un usuario de Tor que necesita acceder a la red desde un entorno hostil, el acceso puede estar filtrado por el enemigo o, como mínimo, el enemigo sabrá que está usando Tor. Este conocimiento en sí puede suponer un riesgo, ya sea porque en esa jurisdicción se trata de algo ilegal o simplemente resulta sospechoso. Puede posibilitar, incluso, un ataque de confirmación.

Las dos cuestiones a resolver, entonces, son:

  • ¿Cómo un usuario Tor puede encontrar las IPs de nodos Tor para conectarse a la red sin que los malos las conozcan?
  • Dado que el tráfico Tor es claramente identificable como tal, ¿cómo hace para que el malo no sepa que estamos usando Tor?

La respuesta a la primera cuestión son los nodos Bridge. La respuesta a la segunda pregunta es la ofuscación del tráfico mediante pluggable transports. Ninguna de las dos soluciones son la panacea, pero ahora mismo es lo mejor que tenemos.

Nodos Bridge

Los nodos bridge son nodos que no aparecen en el directorio público Tor. En cambio, se registran en un directorio oculto de la red. Cuando un usuario desea acceder a la red Tor, pero, por ejemplo, el acceso a los nodos Tor públicos está filtrado por el enemigo, se conecta primero al directorio bridge y solicita un listado de IPs de nodos bridge. El directorio no le enviará todo el listado de nodos bridge sino solo un pequeño número. Qué nodos se enseñan depende, por ejemplo, de la IP del usuario. La idea es que aunque el enemigo solicite el listado de nodos bridge, recibirá solo un pequeño número de los disponibles y, además, serán diferentes de los nodos bridge que ha recibido el usuario Tor real.

La idea es que el usuario Tor pueda conectarse a un nodo Tor cuya IP es desconocida para el enemigo. Al no conocerla, no podrá filtrar esas conexiones.

Como la conexión a la propia base de datos de nodos bridges puede estar filtrada o resultar sospechosa, el usuario puede pedir un pequeño listado de bridges desde una conexión más o menos segura, apuntárselos e introducirlos manualmente en el Tor Browser o similar cuando se encuentre en la red hostil.

Por ejemplo, si viajo a China podría apuntarme los detalles de conexión de un puñado de nodos bridge, incluyendo los que controlo yo mismo. Naturalmente los nodos Tor aparecen y desaparecen, así que es normal que la lista vaya perdiendo efectividad con el paso del tiempo. Lo que yo haría sería refrescar la lista a través de la propia red Tor de vez en cuando. Es decir, usaría mi lista manual para arrancar el primer día.

Desde el punto de vista del administrador del nodo Tor, que la filiación de esa IP a la red Tor no sea pública y evidente soluciona el problema del filtrado injustificado. Filtrado que no soluciona ningún problema real, pero que tiene efectos colaterales graves.

Los nodos bridge son un recurso valioso y escaso. Solo deben usarlos los usuarios Tor que lo necesiten (personas bajo regímenes represivos, por ejemplo). El resto de usuarios pueden usar los nodos Tor públicos para no ocupar recursos ireemplazables.

Los nodos bridge se utilizan solo como nodos de entrada a la red Tor. El circuito Tor continuará a través de nodos Tor públicos. Este hecho y el hecho de que los nodos bridge se reserven para casos desesperados, hace que -en general- el tráfico de un nodo bridge sea mucho más bajo que un nodo Tor normal. La contribución, no obstante, es muy valiosa: estaremos sirviendo poco tráfico, pero será tráfico que no tiene otra opción y depende de nosotros.

pluggable transports

Que un usuario Tor se conecte a un nodo bridge no ayuda si el tráfico Tor puede identificarse con facilidad. Un enemigo con recursos no necesita conocer las IPs de los nodos Tor si puede reconocer el patrón de tráfico. Por ello Tor desarrolló la tecnología del pluggable transports.

Los pluggable transports son protocolos de ofuscación que pretenden ocultar el hecho de que una conexión determinada es una conexión Tor.

Es evidente que ocultar la naturaleza de una conexión Tor a un nodo Tor público no sirve para nada (el enemigo ya sabe que estamos conectando a un nodo Tor, porque su IP está registrada de forma pública). Por tanto, lo normal es que sean los nodos bridge los que ofrezcan la posibilidad de emplear pluggable transports.

Ejemplo de configuración

La configuración Tor de un nodo bridge con ofuscación es muy similar a la de un nodo Tor repetidor. No tiene mucho sentido que una misma máquina sea un nodo bridge y un Tor nodo de salida, a menos que las IPs de entrada y de salida de ese ordenador sean diferentes. No es habitual, pero puede ocurrir.

Mi cambio de configuración es la siguiente:

 root@MeteoPI:/usr/local/etc/tor# hg diff -r -3:.
 diff -r 30da137a3a05 -r f084ad49a473 torrc
 --- a/torrc     Thu Feb 18 06:42:11 2016 +0100
 +++ b/torrc     Fri Apr 08 02:47:27 2016 +0200
 @@ -113,6 +113,10 @@
  #RelayBandwidthRate 100 KB  # Throttle traffic to 100KB/s (800Kbps)
  #RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)

 +RelayBandwidthRate 1000 KB
 +RelayBandwidthBurst 1500 KB
 +
 +
  ## Use these to restrict the maximum traffic per day, week, or month.
  ## Note that this threshold applies separately to sent and received bytes,
  ## not to their sum: setting "4 GB" may allow up to 8 GB total before
 @@ -196,3 +200,15 @@
  ## address manually to your friends, uncomment this line:
  #PublishServerDescriptor 0

 +
 +
 +# Bridge!! - 18/feb/16 - Ver diario.
 +BridgeRelay 1
 +
 +# Sin esto nos sale un Warning.
 +ExtORPort auto
 +
 +ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy
 +ServerTransportListenAddr obfs3 0.0.0.0:XXXXX
 +ServerTransportListenAddr obfs4 0.0.0.0:XXXXX

Dado que nuestra IP se mantiene oculta para la mayor parte de la red, muchos de los mecanismos de evaluación de calidad de Tor no funcionarán correctamente. Por ello no me fío del ancho de banda calculado por la red Tor, muy conservador, y publico manualmente valores más realistas. Eso es lo que hacen las líneas 9 y 10.

Activo el modo bridge en la línea 23. Las líneas 26-30 configuran y activan los protocolos de ofuscación obfs3 y obfs4. La línea 26 activa un protocolo de comunicación interna entre el demonio Tor y los demonios de ofuscación para cosas como, por ejemplo, poder transferir la IP real de la conexión entrante o implementar mecanismos de control de flujo, etc.

Las XXXXX de las líneas 29 y 30 deben ser puertos elegidos al azar. No pongo los míos para evitar escaneos con la intención de localizar mis nodos bridge.

Por supuesto, si estamos detrás de un router con filtrado de puertos o un cortafuegos habrá que abrir los puertos empleados para la ofuscación. En entornos doméstivos podemos usar técnicas como las descritas en Mapeo de puertos en el "router" a través de Python y UPnP.

Llamada a las armas

Si puedes, contribuye con un nodo Tor a la red. Una Raspberry PI de primera generación (sí, la versión de 2012) y 1Mbps de ancho de banda son suficientes. Si prefieres que tu filiación a Tor no sea conocida, no tener problemas de filtrado inadecuados, ceder menos ancho de banda a Tor y/o deseas facilitar la vida a personas en regímenes opresivos, configura tu nodo para que sea un bridge y, si es posible, activa también la ofuscación.