Tor y el anonimato

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 conozcáis este proyecto, basta con decir que es una de las bases de WikiLeaks; si alguna vez has necesitado navegar anónimamente, sigue leyendo.

Llevo bastante tiempo queriendo escribir sobre tor, el motivo que me lo ha impedido es que no disponía de suficiente tiempo. Para hacerse una idea de tor hay que aplicar muchos conceptos. Por este motivo me he decido a hablaros de tor en tres capítulos.

– El primero es este, que va a intentar explicar el funcionamiento básico de un programa de anonimato.
– El segundo tratará del funcionamiento específico de tor.
– El tercero se adentrará en la configuración de las herramientas que nos proporciona tor.

Sé que puede parecer un poco extenso, pero quiero que conozcáis el funcionamiento de un proyecto que admiro especialmente. El hecho de que sea FLOSS hace que merezca la pena gastar mis energías en acercaros el que yo creo que es uno de los mejores proyectos libres que existen actualmente. Si te ha picado la curiosidad (espero que sí) y  nunca habías oído hablar de tor, coge aire y salta al siguiente párrafo.

Para hablar de tor primero tengo que explicar brevemente un pilar fundamental de internet: el protocolo TCP. Solo voy a decir, para no aburriros, que 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 paquetes TCP (datagramas) 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.

Hasta ahora hemos visto que a través de un servidor intermedio (proxy) puedo esconder mi dirección IP del servidor que hospeda la página. Pero, ¿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: 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 ordenador como un retransmisor.

– Clientes tor u OP: 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 (en el siguiente capítulo ahondo más en el tema).

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 (lo veré con mayor detalle en el segundo capítulo) y el segundo es el dinamismo de los retransmisores. Como he 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.

Para acabar, tengo que aclarar una cosa. En todo el artículo he puesto como ejemplo el uso de tor en un navegador web, aunque tor puede aplicarse a cualquier aplicación que haga uso del protocolo TCP. No solo se limita a navegadores web, puedo utilizarlo con programas de mensajería instantánea, programas de descargas que utilicen puertos TCP o clientes de identi.ca.


Voy a hacer un breve resumen que sirva como repaso del anterior artículo. La semana pasada aprendimos que el funcionamiento de un programa de anonimato se basa en interponer varios servidores entre mi ordenador y el servidor que hospeda la página. De esta forma, los servidores intermedios, también denominados proxies, esconden mi dirección IP y no permiten que el servidor que hospeda la página la averigüe. Así pues, tor crea una red de servidores a la que yo me puedo conectar. También vimos que el usuario es el cliente u OP y los servidores intermedios eran denominados retransmisores u OR. Sin embargo, ¿cómo se realiza la conexión entre el cliente y el retransmisor? La respuesta a esta pregunta la trataré de dar en este artículo.

Supongamos que ya tengo montado un circuito formado por mi ordenador, 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 mí son los de mi conexión, y no los paquetes de la conexión de mi vecino, es decir, que existe un proceso de autenticación. De poco me serviría que fuese anónimo si la conexión que mantengo con los servidores intermedios no es satisfactoria, es decir, que por ejemplo los proxies alteran el paquete y encima me entregan los paquetes del vecino.

Aquí es donde entra en juego la criptografía. La criptografía es la 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 (os sonará si habéis batalleado con gpg) 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 cifro un mensaje con la clave pública, si intento descifrar el texto cifrado con la clave pública, no obtendré nada, aparte de números y letras sin sentido; necesito la clave privada para descifrar el mensaje. Esto es reversible, es decir, también puedo cifrar un mensaje con la privada, pero solo podré descifrarlo con la pública. ¿Qué consigo con esto? Pues depende de cómo utilice las claves. Si utilizo la pública para cifrar y la privada para descifrar, tengo confidencialidad, solo el destinatario puede averiguar el contenido del mensaje. Pero si utilizo la privada para cifrar y la pública para descifrar, obtengo la autenticación del remitente e integridad del mensaje, ya que solo la persona que dispone de la clave privada me ha podido enviar el mensaje. La criptografía simétrica utiliza solo una clave tanto para cifrar como para descifrar. Pero, ¿qué tiene que ver la criptografía con tor? Mucho.



Hace dos párrafos he dicho que para que el anonimato sea práctico, tengo 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. Ya sé que parece un poco abstracto, pero en cuanto empecéis a leer, comprenderéis el significado de los nombres. Empecemos por el principio: las cebollas. Algunos os habréis preguntado por qué el símbolo de tor es una cebolla, 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 quiero hacer una petición de conexión a un servidor web, y que me conecto 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. Veamos la siguiente imagen de redescebolla para entenderlo mejor:

Alice es el cliente, la nube representa la red tor y los ordenadores 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 solo 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.

Ahora bien, el protocolo anteriormente descrito tiene un inconveniente: previamente tengo 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 negocio la clave con el servidor y genero la cebolla, el proxy puede que no esté activo, y la conexión se vuelva imposible. Es decir, necesito un sistema que me permita crear la conexión al mismo tiempo que negocio la clave; este sistema es la red telescópica o red de cebollas de segunda generación.

El funcionamiento de este sistema es el siguiente. Primero conecto con la puerta de entrada, negocio con ella una clave y la utilizo para usarla como clave de sesión. Es decir,  creo un canal de comunicación cifrado sobre el que voy a transmitir el paquete.

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

Así sucesivamente hasta que llego 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 solo conoce la identidad del servidor inmediatamente anterior a él.

El esquema de la red telescópica, por tanto, crea un canal seguro sobre el que 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 demonios se crean las conexiones? ¿Por ciencia infusa? La respuesta nos la da el protocolo de seguridad TLS .Tls (transport layer security) 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, genero un túneles entre dos servidores sobre el que mando 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. Si habéis sido observadores, habréis notado que siempre he dado por sentado un dato: la identidad de los servidores intermedios. En todo el artículo 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 tengo la base de datos de los retransmisores, y decido almacenarla en un único servidor. Si hay tres clientes que quieren acceder a ella, igual me empiezo a estresar, porque el servidor se está empezando a sofocar, pero, ¿y si en vez de tres son trescientos? Puede que el servidor se ponga en huelga. Para evitarlo, duplico la base de datos y descentralizo 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, cosulta la base de datos y crea el circuito tor.
Hasta ahora hemos visto el funcionamiento normal de tor. Sin embargo, el funcionamiento normal de tor no es el adecuado bajo ciertas condiciones. Imaginemos que resides en un país cuyo gobierno censura ciertos sitios web. Quieres visitar esos sitios, porque crees que hay información útil almacenada en ellos, pero no puedes acceder porque tu gobierno opina que no debes hacerlo. Si conoces tor, lo podrías 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, puedes acceder a esta página, que te proporciona tres bridges de forma inmediata. Si la anterior página también esté bloqueada, no desesperes, porque el proyecto tor tiene la solución. Si envías un correo a la dirección bridges@torproject.org con la palabra clave “get bridges” ellos te enviarán la dirección del bridge. Así de fácil. Ahora os estaréis preguntando cómo configuro el servicio para usar los bridges, pero me temo que tendrás que esperar al último capítulo.

Por último, tengo que hablar de los servicios ocultos. Supongamos que estás 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 quiero montar un servidor dentro del país con contenido “sospechoso”? ¿Me bloqueará el gobierno mi servidor? Sí, pero con tor, una vez más, podemos evitarlo con los denominados servidores de ubicación oculta. No me voy a extender en el funcionamiento de esta funcionalidad, pero sí quiero explicaros cómo funcionan de forma muy breve.


Los servidores de ubicación oculta solo pueden ser accedidos desde la red tor. Es decir, tienes que montar un circuito tor para conseguir acceder al contenido del servidor. Realmente no accedes al servidor, sino que accedes 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.

Fuente: PillateUnLinux