Tor, Vidalia y el anonimato en Internet

TOR es un proyecto de software libre que te ayuda a defenderte contra cualquier tipo de vigilancia que amenace tu libertad personal y privacidad. Así es como los desarrolladores de TOR definen la navaja suiza del anonimato. En este artículo voy a tratar de explicar qué es y qué hace TOR. Para todos aquellos que no conozcan este proyecto, basta con decir que es una de las bases de WikiLeaks; si alguna vez has necesitado navegar anónimamente, sigue leyendo.

Para hacerse una idea de TOR hay que aplicar muchos conceptos. Sé que es un poco extenso, pero quiero que conozcan el funcionamiento de un proyecto que admiro especialmente. El hecho de que sea FLOSS hace que merezca la pena gastar mis energías en acercales el que yo creo que es uno de los mejores proyectos libres que existen actualmente.

Para hablar de TOR, primero hay que explicar brevemente un pilar fundamental de internet: el protocolo TCP.

Básicamente, el protocolo TCP se encarga de la transmisión de los paquetes. Cuando navego por internet, pido continuamente al servidor que hospeda la página web, la información que define la página. Con esa información el navegador puede construir la página web. Pero, ¿cómo le llega al navegador la información? En forma de paquetes TCP. Estos están formados por dos partes, la primera es la cabecera, y la segunda son los datos. En la cabecera se encuentra información como el puerto de origen, el de destino, diferentes flags, el tamaño del mensaje o la suma de verificación (checksum). Lo que nos interesa es la puerto de origen. Al visitar una página web, el navegador tiene que construir los paquetes TCP, es decir, tiene que rellenar todos los campos del paquete TCP para que no le rechacen el paquete. Lo que nos lleva a una conclusión, a través del puerto de origen, cualquiera que lea el paquete TCP me puede ubicar espacialmente (a través de la dirección IP, que se puede sacar con el puerto de origen y la cabecera del paquete IP), es decir, no dispongo de anonimato.

Ahora imaginemos que en vez de enviar los paquetes directamente al servidor que hospeda la página, primero envío el paquete a un servidor intermedio, para que este a su vez se los envíe finalmente al servidor que hospeda la página. ¿Qué ha cambiado? Que ahora soy más anónimo, los paquetes que le llegan al servidor que hospeda la página contienen la dirección de origen del servidor intermedio, es decir, que el servidor que hospeda la página no sabe mi dirección. Sin embargo hay un problema, el servidor intermedio sí sabe mi dirección; ahora supongamos que el servidor intermedio, el único que sabe mi dirección real, está protegido. ¿Qué pasa entonces? Que soy totalmente anónimo. Esta es la filosofía detrás de TOR.

¿Y si en vez de esconderla detrás de un servidor intermedio la escondo detrás de varios?

Lo que consigo es fortalecer el sistema; en el hipotético caso en el que un servidor intermedio cayera en manos desconocidas, el atacante no conseguirá mi dirección IP. El objetivo principal de TOR es generar una red de servidores intermedios protegidos a los que yo me pueda conectar. Por defecto me conecto a tres servidores intermedios, aunque se puede variar el número.

Dependiendo de la posición que ocupen los servidores intermedios, tendremos diferentes tipologías: Retransmisor TOR u OR, que son los proxies que están dentro de la red TOR, dependiendo del lugar que ocupen pueden ser la puerta de entrada, de salida o intermedios. Están mantenidos por la comunidad y tú mismo puedes configurar tu computadora como un retransmisor; y Clientes TOR u OP, que es el cliente que solicita una conexión TOR, es decir, el usuario normal y corriente. Para saber la dirección de varios retransmisores TOR el cliente accede a una base de datos semidistribuida, lo que veremos más adelante.

En el esquema de arriba, Alice sería el cliente, los nodos TOR serían los retransmisores, y Bob sería el servidor que hospeda el sitio web. Dentro de los tres retransmisores que forma la red TOR, el primero es la puerta de entrada, el segundo es un retransmisor intermedio y el tercero es la puerta de salida.

La red TOR cambia continuamente para aumentar el anonimato. Cuando me conecto a otro servidor, los retransmisores cambian, fortaleciendo el único punto débil que podría tener el sistema: la puerta de entrada. El primer retransmisor (o puerta de entrada) es el único ordenador que tiene mi dirección IP, es decir que si un atacante se hace con el control de la puerta de entrada, podría averiguar mi dirección IP. Esto no es posible por dos motivos. El primero es que la conexión entre el cliente y la puerta de entrada está cifrada (LINK) y el segundo es el dinamismo de los retransmisores. Como hemos dicho antes, con cada conexión nueva los retransmisores cambian, de tal forma que la puerta de entrada de mi conexión anterior en la nueva conexión no lo es, con lo cual el atacante no sabe a ciencia cierta cuál es mi puerta de entrada, porque está continuamente cambiando.

¿Cómo se realiza la conexión entre el cliente y el retransmisor?

Supongamos que ya tenemos montado un circuito formado por nuestra computadora, tres servidores intermedios, y el servidor que hospeda la página. Sin embargo, hasta ahora hemos dado por sentado que se cumplían varios supuestos. Uno es que los paquetes TCP no van a ser alterados por los servidores intermedios, es decir, que la integridad de los paquetes permanece intacta; otro es que los paquetes que me llegan a nosotros son los de nuestra conexión, y no los paquetes de la conexión de nuestro vecino, es decir, que existe un proceso de autenticación. De poco nos serviría que fuese anónimo si la conexión que mantenemos con los servidores intermedios no es satisfactoria, es decir, que por ejemplo los proxies alteran el paquete y encima nos entregan los paquetes del vecino.

Aquí es donde entra en juego la criptografía, ciencia que estudia la manera de cifrar y descifrar mensajes para que resulte imposible conocer su contenido excepto si se conoce la clave que descifra el citado mensaje. En criptografía, hay dos técnicas muy habituales para cifrar el contenido de un mensaje, denominadas asimétrica y simétrica. La primera está formada por dos claves distintas, una pública y otra privada. La pública la puede tener cualquier persona, y la privada solo la tienen personas autorizadas. Ambas pueden cifrar y descifrar un mensaje, pero si cifro el mensaje con una clave, solo puedo descifrarlo con la otra clave. Supongamos que ciframos un mensaje con la clave pública, si intentamos descifrar el texto cifrado con la clave pública, no obtendremos nada, aparte de números y letras sin sentido; necesitamos la clave privada para descifrar el mensaje. Esto es reversible, es decir, también podemos cifrar un mensaje con la privada, pero solo podremos descifrarlo con la pública. ¿Qué conseguimos con esto? Depende de cómo utilicemos las claves. Si utilizamos la pública para cifrar y la privada para descifrar, tenemos confidencialidad, solo el destinatario puede averiguar el contenido del mensaje. Pero si utilizamos la privada para cifrar y la pública para descifrar, obtenemos la autenticación del remitente e integridad del mensaje, ya que solo la persona que dispone de la clave privada nos ha podido enviar el mensaje. La segunda, en cambio, utiliza solo una clave tanto para cifrar como para descifrar.

Hasta aquí, hemos visto que, para que el anonimato sea práctico, tenemos que satisfacer varios requerimientos. El primero es la integridad del paquete y el segundo es asegurar la identidad del servidor. Para asegurar estos dos requerimientos, TOR se basa en un modelo de redes telescópicas o redes de cebolla de segundo orden. Lo primero que tenemos que saber es el esquema general de funcionamiento de un circuito telescópico, y empezaremos por el principio: las cebollas. Algunos se habrán preguntado por qué el símbolo de TOR es una cebolla, y esto no es porque todos los desarrolladores sean vegetarianos, sino porque las cebollas tienen capas.

Una cebolla esta formada por el núcleo y las capas externas. En el campo de las redes de anonimato, el núcleo de la cebolla es el paquete TCP, y las capas externas son envoltorios cifrados con clave simétrica. Es decir, supongamos que queremos hacer una petición de conexión a un servidor web, y que nos conectamos por Tor. Para proteger el paquete TCP, el cliente que se conecta a Tor genera n capas, siendo n el número de servidores intermedios. Cada capa ha sido creada con una clave simétrica negociada entre cada servidor intermedio y el cliente. Una vez que el cliente ha generado la cebolla, se envía a través de la conexión Tor, y empieza a recorrer los diferentes servidores intermedios. Cada capa de la cebolla es “pelada” por el servidor intermedio correspondiente a medida que la cebolla va pasando por los servidores intermedios, de manera que la puerta de salida genera el paquete TCP original y se lo envía al servidor que hospeda la página web. La siguiente imagen nos ayudará a entenderlo mejor:

Alice es el cliente, la nube representa la red Tor y las computadoras que están dentro de ella representan los servidores intermedios. Podemos observar que Alice inicia la conexión con la puerta de entrada, que está coloreada de verde. El paquete que le manda Alice a la puerta de entrada es la cebolla completa, formada por el paquete TCP (óvalo amarillo) y las diferentes capas cifradas mediante la clave simétrica, que a su vez sólo conocen Alice y el servidor intermedio correspondiente. Es decir, que Alice primero consulta a todos los servidores intermedios que va a utilizar para acordar una clave simétrica con cada uno de ellos, y una vez que tiene todas las claves simétricas, genera la cebolla. Después la envía y cada servidor intermedio retira la capa correspondiente. Al final del camino, el servidor coloreado de amarillo obtiene el paquete TCP original.

El protocolo anteriormente descrito tiene un inconveniente: previamente tenemos que recolectar todas las claves simétricas. La recolección de las claves simétricas es una desventaja bastante grande, porque en el lapso de tiempo que transcurre entre que negociamos la clave con el servidor y generamos la cebolla, el proxy puede que no esté activo, y la conexión se vuelva imposible. Es decir, necesitamos un sistema que me permita crear la conexión al mismo tiempo que negociamos la clave; este sistema es la red telescópica o red de cebollas de segunda generación, que funciona de la siguiente manera: primero conectamos con la puerta de entrada, negociamos con ella una clave y la utilizamos para usarla como clave de sesión. Es decir, creamos un canal de comunicación cifrado sobre el que vamos a transmitir el paquete.

Después, con la conexión establecida con la puerta de entrada, conectamos a través de ésta con otro servidor, negociamos la clave, y creamos otro canal de comunicación anidado en el primero.

Así sucesivamente hasta que llegamos a la puerta de salida, la cual envía al servidor que hospeda la página web (Bob) el paquete TCP, sin saber la identidad de Alice, ya que sólo conoce la identidad del servidor inmediatamente anterior a él.

El esquema de la red telescópica, por lo tanto, crea un canal seguro sobre el cuál mandar los paquetes TCP. Este canal seguro está protegido por una clave simétrica generada entre el servidor intermedio correspondiente y el cliente.

Ahora bien, sabemos que se genera el canal y que está protegido por una clave simétrica, pero, ¿cómo se crean las conexiones?

La respuesta nos la da el protocolo de seguridad TLS (Transport Layer Security), que es la evolución del protocolo SSL (Secure Sockets Layer). Estos dos protocolos aseguran canales de comunicación seguros sobre internet mediante claves simétricas. A través de este protocolo, generamos túneles entre dos servidores sobre el que mandamos la información. Es decir, Tor utiliza el protocolo TLS para establecer la conexión entre los diferentes servidores.

Ahora ya sabemos cómo realiza Tor la conexión dentro de la red Tor. La realiza mediante el protocolo TLS y siguiendo el esquema de las redes telescópicas. De esta forma garantiza tanto la integridad como la identidad de los comunicadores. Sin embargo, todavía falta una cosa bastante importante: dimos por sentada la identidad de los servidores intermedios. En todo el proceso, se partía de la premisa de que Alice conocía la identidad de cada servidor intermedio. Sin embargo, nadie nace sabiendo, y Alice tiene que consultar a alguien la identidad de todos los servidores intermedios, ése alguien es la autoridad de directorio, una base de datos distribuida.

Una autoridad de directorio es una base de datos que almacena todas las direcciones de todos los retransmisores. En este momento hay seis autoridades de directorio, lo que forma una base de datos distribuida. Supongamos que tenemos la base de datos de los retransmisores, y decidimos almacenarla en un único servidor. Si hay tres clientes que quieren acceder a ella, igual nos empezamos a estresar, porque el servidor se está empezando a sofocar, pero, ¿y si en vez de tres son trescientos? Puede que el servidor reviente. Para evitarlo, duplicamos la base de datos y descentralizamos el sistema, de tal forma que los trescientos se repartan entre los seis servidores. Eso es una base de datos descentralizada. Por tanto, el cliente accede a la autoridad de directorio, consulta la base de datos y crea el circuito Tor.

Pero… imaginemos que residimos en un país cuyo gobierno censura ciertos sitios web. Queremos visitar esos sitios, porque creemos que hay información útil almacenada en ellos, pero no podemos acceder porque nuestro gobierno opina que no debemos hacerlo. Conociendo Tor, lo podríamos usar, pero ¿y si el gobierno ha bloqueado totalmente la red Tor?¿Lo pueden hacer? Sí, y de hecho numerosos gobiernos lo hacen actualmente. Si alguien quiere bloquear Tor, solo tiene que bloquear el acceso a las autoridades de directorio, ya que sin las direcciones de los retransmisores, no podemos construir un circuito Tor. Por tanto, si quiero evitar el bloqueo de Tor, tengo que buscar una alternativa a las autoridades de directorio: los bridges relays.

Los bridges relays son retransmisores que no están listados en las autoridades de directorio. Para acceder a la dirección de un bridge, podemos acceder a esta página, que nos proporciona tres bridges de forma inmediata. Si la anterior página también esté bloqueada, a no desesperar, porque el proyecto Tor tiene la solución. Si enviamoss un correo a la dirección bridges@torproject.org con la palabra clave “get bridges” ellos nos enviarán la dirección del bridge. Así de fácil.

Para terminar con este tema, tenemos que hablar de los servicios ocultos. Supongamos que estamos en el citado país que censura la red de redes. Hasta ahora hemos visto cómo acceder a sitios web externos que bloquea el gobierno, pero ¿y si queremos montar un servidor dentro del país con contenido “sospechoso”? ¿Nos bloqueará el gobierno nuestro servidor? Sí, pero con Tor, una vez más, podemos evitarlo con los denominados servidores de ubicación oculta.

Los servidores de ubicación oculta sólo pueden ser accedidos desde la red Tor. Es decir, tenemos que montar un circuito Tor para conseguir acceder al contenido del servidor. Realmente no accedemos al servidor, sino a la información del servidor. Este detalle es importante, porque el cliente en ningún momento sabe la dirección real del servidor, lo que le hace anónimo. El servicio funciona de la siguiente forma. Primero el servidor genera un par de claves pública y privada. Con la clave pública genera un nombre de dominio, formado por la clave pública y el nombre de dominio superior onion, de tal forma que, por ejemplo, el nombre de dominio generado es el siguiente: 982autocid2k45lo.onion. Luego elige un grupo de retransmisores para que funcionen como Puntos de Introducción, crea un paquete que contenga su dirección .onion junto con las direcciones de los PI y lo cifra con la clave privada. Este paquete generado es enviado a una base de datos distribuida que proporciona Tor. Cuando el cliente quiere acceder a la información del servidor, primero tiene que averiguar por sus propios medios (a través de una base de datos de servicios ocultos) la dirección .onion del servidor. Una vez que haya conseguido la dirección, se la entrega a la base de datos distribuida. Con la clave pública, el paquete generado con la privada se descifra, y la dirección de los PI es revelada. A partir de aquí, el cliente se conecta a la red tor y pide a su puerta de entrada que contacte con un PI, cuando contacta con uno de ellos le envía la dirección .onion del servidor, el PI se pone en contacto con el servidor y la comunicación empieza a través de la red Tor.

Cuando navegamos por internet, tecleamos en la barra de direcciones del navegador un nombre, como doble69.com.ar o google.com. Como muchos sabrán, lo que tecleamos en la barra de direcciones es un nombre de dominio. Un nombre de dominio es un sinónimo de la dirección IP que aloja la página web. Los nombres de dominio se inventaron para hacer más fácil el acceso de los usuarios a los diferentes servidores, es más fácil recordar google.com que 192.168.0.1. Sin embargo, los diferentes protocolos que componen internet trabajan con direcciones IP, no con nombres de dominio, por lo que tiene que haber alguien o algo que traduzca los nombres de dominio a direcciones IP, ése traductor lo componen los DNS (Domain Name Server o Servidor de Nombres de Dominio). Estos servidores tienen tablas especiales que relacionan un nombre de dominio con su dirección IP. Están completamente jerarquizados, de manera que cuando escribimos doble69.com.ar en la barra de direcciones, primero preguntamos al servidor DNS de nuestro ISP, o a OpenDNS o GoogleDNS si lo hemos configurado así. A partir de este momento, el servidor DNS al que hacemos la petición empieza a preguntar a otros servidores por doble69.com.ar, primero empezará por el dominio de más peso (en este caso .com) para luego encontrar la dirección IP del servidor que aloja doble69.com.ar. Todo esto es importante porque nunca seremos anónimos si la petición DNS no está anonimizada.

Recordemos que un proxy es un servidor que se coloca entre el cliente (el navegador web en el ejemplo) y el servidor. Supongamos que utilizamos el proxy para conectarnos a internet, y que visitamos asiduamente wikipedia.org; para ahorrar tiempo, el servidor intermedio puede alojar una copia exacta de wikipedia, para que la próxima vez que le mandemos una petición nos envíe la copia guardada de wikipedia y se reduzca el tiempo de espera. El espacio que destina el proxy para almacenar la copia se denomina caché. Lo malo de disponer caché es que si el proxy no actualiza frecuentemente, nos envía una imagen de la web que no es la real, ya que puede ser la de hace un segundo o un año. Privoxy es un servidor intermedio sin caché y Polipo, por el contrario, dispone de caché. Una vez hecha la distinción, lo último por puntualizar es que cuando nos conectamos a Privoxy o Polipo para realizar las peticiones DNS, lo hacemos mediante el protocolo SOCKS. El objetivo de éste protocolo es facilitar el enrutamiento de paquetes de datos entre un cliente y un servidor via proxy. SOCKS, por lo tanto, es el protocolo elegido que usa Tor para conectarse tanto a Privoxy como Polipo.

Entonces, las herramientas que nos proporciona Tor son el cliente que inicia todo el proceso que hemos descripto, el navegador Tor Browser Bundle, y Vidalia, una front-end gráfica para configurar Tor. El cliente Tor Browser Bundle que podemos descargar de la página del proyecto, incluye un cliente Firefox parcheado. Para mantenernos a salvo, tiene desactivados muchos tipos de contenido activo. En sus comienzos, esto se realizaba aplicación por aplicación, y llevaba más tiempo configurarlo. Hoy en día, para instalar el cliente, es decir, TOR, podemos seguir las indicaciones oficiales. Está disponible para GNU/Linux, Windows y MAC OS X. Una vez instalado, es recomendable instalar un proxy (Polipo o Privoxy); aunque no es obligatorio, pero hay que saber que si no usamos un proxy para las peticiones de DNS, servirá utilizar una red Tor pero aún así somos localizables. Para instalar cualquiera de estos dos proxies también es recomendable seguir la guía oficial, porque está muy bien explicado y no es un proceso complejo. Eso sí, hay que asegurarse de que no tenemos instalado el otro, porque de lo contrario no va a funcionar nada.

Al iniciar el programa, se inicia Vidalia, y realiza automáticamente todo el proceso de ruteo, hasta mostrarnos la siguiente pantalla:

Vidalia le permite iniciar y detener Tor, ver la cantidad de ancho de banda que se consume, ver la cantidad de circuitos que tiene actualmente activo, ver donde estos circuitos están conectados en un mapa global, ver los mensajes de Tor acerca de su progreso y estado actual, y deja que configurar el cliente Tor, puente, o el relay con una interfaz sencilla. Incluido en Vidalia es un amplio sistema de ayuda, que le ayuda a entender todas las opciones disponibles.

Con estos sencillos pasos, tendremos habilitado Tor, pero ¿cómo sé si soy anónimo? La página web de inicio por defecto de Tor, Tor test, comprueba automáticamente si somos anónimos, y nos aparecerá una pantalla como esta:

Hasta aquí, hemos explicado de qué manera nos garantizamos navegar de manera anónima por internet, y salvaguardar nuestra privacidad. En futuras entregas, veremos que esta red no es perfecta, y tiene algunas vulnerabilidades. De la misma manera, veremos algunas alternativas, ya que Tor no es la única herramienta que existe para este fin.