CASI TODO SOBRE TOR

-1-
Casi todo sobre tor
por kudrom

Este documento se distribuye bajo una licencia Creative Commons de

Reconocimiento 2.5 España. Usted es libre de:

Copiar, distribuir y comunicar públicamente la obra

Hacer obras derivadas

Bajo las condiciones siguientes:

Puede descargar la versión más reciente de la licencia Creative Commons en la

página http://creativecommons.org/
Puede consultar los artículos originales en la página http://www.pillateunlinux.com

-2-
 TOR (parte I)

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.
- El cuarto tratará de las vulnerabilidades y alternativas de este proyecto de
anonimato.
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

-3-
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.

-4-
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).

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.

-5-
 TOR (parte II)

En esta segunda entrega voy a hablar del funcionamiento más específico de Tor.
Hablaré del protocolo TSL, de criptografía asimétrica y simétrica, de cebollas o de
bases de datos distribuidas. Ya sabemos la filosofía detrás de un programa de
anonimato, ahora falta saber cómo funciona tor.
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

-6-
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

-7-
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:

-8-
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.

-9-
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

-10-
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.

-11-
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.

-12-
Y esto ha sido todo por hoy, en el próximo capítulo hablaré de la configuración de
las herramientas que nos proporciona tor para utilizar todas las funcionalidades que
he presentado en estos dos primeros capítulos. Espero no haberos abrumado y nos
vemos en el siguiente capítulo.

-13-
 TOR (parte II)

En los dos artículos anteriores he intentado explicar cómo funciona, a grosso modo,
un programa que te proporciona anonimato. En éste me propongo poner en práctica
todos esos conocimientos estudiando las herramientas que nos proporciona el
proyecto tor. El uso más habitual de tor es utilizarlo junto al navegador web, pero
también se puede utilizar con otras herramientas.
Antes de empezar, un resumen de los anteriores dos artículos. En el primero vimos
que un programa de anonimato básicamente interpone servidores intermedios para
tapar nuestra dirección IP. Vimos la tipología de los servidores y que tor trabaja con
paquetes TCP. En el segundo vimos que tor se basa en una red telescópica, que
utiliza el protocolo TSL para crear las conexiones y que para saber la identidad de
los retransmisores visitaba una base de datos distribuida denominada Autoridad de
Directorio. También vimos que un Bridge es un retransmisor no listado en las
autoridades de directorio y que sirve para proporcionar un circuito tor a gente que
viva en un entorno en el que tor esté bloqueado. Por último, hice una mención a los
servidores ocultos y cómo trabajan. Antes de aplicar todos estos conceptos, tengo
que explicar una última cosa.
Cuando navego por internet, tecleo en la barra de direcciones del navegador un
nombre, como pillateunlinux.com, google.es o red-sostenible.net. Como muchos
sabréis, lo que tecleo 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.es que 74.125.230.84. 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 escribo
pillateunlinux.com en la barra de direcciones, primero pregunto al servidor DNS de
mi ISP, o a OpenDNS o GoogleDNS si lo he configurado así. A partir de este
momento, el servidor DNS al que yo hago la petición empieza a preguntar a otros
servidores por pillateunlinux.com, primero empezará por el dominio de más peso (en
este caso .com) para luego encontrar la dirección IP del servidor que aloja
pillateunlinux.com. Todo esto lo cuento porque nunca serás anónimo si la petición
DNS no está anonimizada. Aquí es donde entran en juego los proxys como Privoxy o
Polipo.

-14-
Recordemos que un proxy es un servidor que se coloca entre el cliente (el
navegador web en el ejemplo) y el servidor. Supongamos que utilizo el proxy para
conectarme a internet, y que visito asiduamente la wikipedia; para ahorrar tiempo,
el servidor intermedio puede alojar una copia exacta de la wikipedia, para que la
próxima vez que le mande una petición me envíe la copia guardada de la 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, me 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 que voy a puntualizar es que cuando yo me conecto a privoxy o polipo para
realizar las peticiones DNS lo hago mediante el protocolo SOCKS. El objetivo de
éste protocolo es facilitar el enrutamiento de paquetes de datos entre un cliente y
un servidor via proxies. SOCKS, por lo tanto, es el protocolo elegido que usa tor
para conectarse tanto a privoxy como polipo.
Que empiece el baile. Las herramientas que nos proporciona tor son el cliente que
inicia todo el proceso que he descrito, y vidalia, una frontend gráfica para configurar
tor.
Para instalar el cliente, es decir, tor, seguid las indicaciones oficiales . Está
disponible para GNU/Linux, Windows y MAC OS X. Una vez que lo hayáis instalado,
es muy recomendable que instaléis o polipo o privoxy; aunque no es obligatorio,
pero tenéis que saber que si no usáis un proxy para las peticiones de DNS, os
servirá de muy poco utilizar una red tor porque sois fácilmente localizables. Para
instalar cualquiera de estos dos proxies también os recomiendo que sigáis la guía
oficial , porque está muy bien explicado y no es un proceso complejo. Yo he probado
en debian polipo y en arch privoxy y funcionan a la perfección, no he tenido ningún
problema. Son muy parecidos, así que instalad el que más rabia os dé. Pero si
instaláis uno, aseguraros de que no tenéis instalado el otro, porque de lo contrario
no os va a funcionar nada. Llegados a este punto, podemos empezar a utlizar tor
con cualquier navegador o con vidalia. Para utilizar tor con un navegador web,
tienes que instalar una extensión para controlar las conexiones, es decir, para
controlar si estáis utilizando el cliente de tor y el proxy de DNS o no, este paso es
el único que varía dependiendo del navegador.
Firefox o IceWeassel:

Hay que instalar el paquete torbutton que nos proporciona el propio proyecto tor.
Simplemente bájate el paquete del sitio oficial de firefox, instálalo, reinicia el
navegador y pulsa el botón que se encuentra en la Barra de Estado para habilitar o
deshabilitar la conexión a tor, así de complicado.

Chromium o Chrome:

La extensión elegida es Proxy Switchy .
icono de la bola del mundo, vete a
extensión. Cuando estés en la pestaña
de nombre tor (por ejemplo), y rellena
siguiente imágen:
Bájatela e insálala, una vez que te salga el
la pestaña de configuración de la citada
de configuración, añade una nueva cuenta,
los campos tal y como se puede ver en la

-15-
Cada vez que quieras ser anónimo, pulsa en la bola del mundo y elije el perfil
asociado a tor, la bola se volverá azul y serás anónimo.
Opera:
La configuración en Opera es un poco más complicada porque no existe ninguna
extensión que proporcione soporte a tor y lo tenemos que configurar a mano, pero
no os desalentéis. Primero abre el navegador y vete a las opciones de
configuración, con la ruta Menú->Configuración->Opciones o pulsando la
combinación de teclas Ctrl+F12, Vete a la pestaña llamada avanzado y en la lista de
la izquierda selecciona redes:

-16-
Ahora pinchamos en servidores proxy y nos saldrá una tabla para configurar los
proxy que queramos que use cada protocolo, os recomiendo habilitar http y https,
aunque si queréis podéis habilitar todos, cada vez que queráis usar tor, habilitáis
esta configuración:

-17-
Con estos sencillos pasos, tendréis habilitado tor, pero ¿cómo sé si soy anónimo?
Visitando varias páginas web para comprobar si realmente sois anónimos:
- Tor test : Si estás usando una conexión tor, te aparecerá una pantalla como esta:

- Si no te fías del anonimato que te proporciona tor, puedes ver que la IP que te
muestra tor en la anterior comprobación no es la tuya (en el ejemplo 199.48.147.42
), pero si sigues siendo escéptico, prueba a entrar en ésta página:

-18-
¡Vaya! Parece que estoy en Dallas, qué curioso, porque nunca he viajado a EE.UU.
Además, podéis comprobar que la IP ha cambiado con respecto a la anterior
conexión del tor test, lo que demuestra que el cambio dinámico del circuito tor por
cada conexión funciona.
Ya sabemos cómo utilizar un navegador web para ser anónimo, ahora voy a
introduciros en el funcionamiento de Vidalia, donde realmente se pueden aplicar
todos los conceptos que he ido explicando a lo largo de los artículos. Pasen y lean.
Para instalar Vidalia, podéis consultar vuestros repositorios para buscar si está en
ellos o instalarlo desde el proyecto tor.
Antes de empezar a trabajar con Vidalia, empecemos por solucionar un error
bastante común. Cuando instalas tor, añades el cliente a la lista de los daemons
que se van a iniciar en el arranque del ordenador. Sin embargo, al lanzar Vidalia
lanzas otro cliente tor, pero como ya lo has lanzado en el arranque, Vidalia no
puede iniciar y lanza un mensaje de error:

Lo que tienes que hacer es abrir el monitor del sistema, moverte a la pestaña de
procesos, buscar el de tor y copiar el PID, luego abres una terminal y matas el
proceso con el siguiente comando (desde superusuario):
# kill -9 PID
Ahora ya puedes iniciar Vidalia, vuelve a la ventana principal y clickea en Iniciar
Tor, la barra de progreso se debería completar y te debería aparecer en la bandeja
de iconos activos una cebolla verde.
Lo primero que hay que destacar de Vidalia es la documentación. Está muy, pero
que muy bien, es muy fácil de comprender y te explica de forma magistral los
fundamentos de tor. Para acceder a ella, clickea en Ayuda.
Como he dicho al principio del artículo, Vidalia es una interfaz gráfica que te ayuda
a configurar tor. Además, nos provee de otras herramientas, como un mapa en el
que se refleja el circuito tor que tienes abierto, un monitor que realiza una lectura
del consumo de ancho de banda o el registro de mensajes.
Empecemos con la verdadera utilidad que nos ofrece Vidalia: la configuración de
tor. A través del botón Preferencias, accedemos a las opciones de configuración de
tor. En la Pestaña general podemos determinar el demonio que tiene que ejecutar
Vidalia (útil si tenemos diferentes versiones de tor), o un cliente de un proxy que
queramos ejecutar, sin embargo, si lanzáis un proxy con Vidalia, os pasará lo mismo

-19-
que con el cliente de tor, tendréis que matarlo para que Vidalia pueda arrancar, o
eliminarlo de los daemons que se inician en el arranque. En la siguiente pestaña
denominada Red, podéis configurar el proxy que habías definido en la sección
anterior, configurar tor para que use otros puertos si tu cortafuegos ha cerrado el
8118 (privoxy o polipo) y el 9050 (tor) y configurar tor para que utilice los bridges.
Ya expliqué en el artículo anterior cómo conseguir la dirección de un bridge, pero si
eres muy vago, Videlia proporciona un botón para buscar las direcciones de algunos
bridges, aunque puedes agregar tú mismo los que quieras de manera manual.

Después tenemos la sección denominada Compartiendo. Aquí es donde vamos a

configurar nuestro ordenador como un simple cliente tor, un retransmisor o un
bridge. Si queréis ser un retransmisor, elegid la opción “Repetidor de tráfico para la
red Tor”, la configuración es bastante sencilla, se pide un nombre para el servidor,
una dirección de correo para ponerse en contacto contigo si hay algún problema, el
puerto por el que se van a realizar las peticiones y la posibilidad de habilitar el port
forwarding, que permite a clientes tor conectarse con otro puerto que no sea el
9050, es decir, si el cliente tiene habilitada la anterior opción que rezaba así “Mi
cortafuegos solo me permite conectarme a ciertos puertos”; después tenéis que
determinar el ancho de banda disponible para tor y los protocolos que permitís que
use el cliente tor. La opción del bridge es igual, lo único que cambia es que tor

-20-
genera la dirección IP que puedes darle a un cliente tor para que se conecte al
bridge que estás configurando.

-21-
La pestaña Servicios te permite configurar un servidor oculto. Una vez que tengas
montado el servidor, tienes que darle a tor un puerto por el que el cliente accederá
al servidor (Puerto Virtual), otro puerto opcional destinado a recoger las peticiones
de conexión (Destino), un directorio en el que tor guarde archivos de configuración,
como la clave privada o la dirección .onion y un checkbox (Habilitado) que
determina si finalmente el servidor usa tor o no, para poder desactivarlo sin tener
que eliminar toda la configuración. La dirección .onion del servidor la configura
automáticamente tor.
Para acabar con la configuración de los diferentes servicios que nos ofrece Vidalia,
tenemos la pestaña Avanzado. En el marco “Puerto de Control” determinamos la

-22-
dirección y el puerto que utiliza Vidalia para configurar tor. Es decir, si por ejemplo
tengo dos ordenadores, y tengo configurado en uno de ellos tor, puedo hacer que el
segundo ordenador utilice la configuración del primero si pongo en el campo
“Dirección” la direccón IP del primer ordenador. La siguiente opción del primer
marco es “Autentificación”, que determina el proceso de autenticación que tiene que
realizar una aplicación para configurar tor. Imaginemos que una aplicación quiere
configurar tor, para probar que es una aplicación de confiar, tiene que aportar un
“salto y seña” que es lo que se determina en este campo. El “salto y seña” puede
ser un archivo (cookie), una clave o nada. Por último, tenemos el archivo de
configuración de tor y el directorio en el que tor guardará información adicional.

-23-
Si clickeas en Ver la Red en la ventana principal de Vidalia, se abrirá una ventana
con un mapa, dos listas y un cuadro de texto inicialmente vacío. Como estaréis
adivinando, la lista de la izquierda son todos los retransmisores que la red tor tiene
disponibles y la lista que tenéis en la parte inferior central define el circuito tor que
estáis usando. Cada una de las filas simboliza un retransmisor, y si pincháis en uno
de ellos se refleja cierta información del retransmisor seleccionado en el cuadro de
texto de la parte inferior derecha. Podéis averiguar el país en el que está situado el
retransmisor, el SO que tiene instalado (tengo que decir que la gran mayoría usan
GNU/Linux), el tiempo que lleva disponible o el ancho de banda disponible. Al
mismo tiempo que seleccionas uno de los retransmisores a los que estás conectado
(los de la lista central inferior), en el mapa se dibujará una línea en verde que
simboliza el tramo de la red tor que genera ése retransmisor.

Otra herramienta que nos proporciona Vidalia es el Registro de Mensajes, que

genera un seguimiento de las operaciones que va realizando tor, además te
proporciona información muy útil si por cualquier motivo tor fallara. Puedes guardar
el log en un archivo externo y modificar el nivel de detalle de los mensajes; lo
aconsejable es marcar los mensajes de Error, Advertencia y Notificación, ya que los
de Información y Depurar no tienen mucha relevancia.

-24-
Por último, la Gráfica de Ancho de Banda es un monitor que realiza una lectura de
tu consumo de ancho de banda. Funciona igual que cualquier otro monitor que
registre el consumo de ancho de banda y no tiene ninguna funcionalidad
destacable.
En el último capítulo de la saga que publicaré la semana que viene analizaré las
vulnerabilidades de tor y analizaré muy por encima algunas alternativas. Espero
haber sido ameno y hasta la semana que viene.

-25-
 TOR (parte II)

En esta última entrega intentaré explicar las vulnerabilidades de tor y expondré dos
“alternativas”: FreeNet e I2P. Con este cuarto capítulo acaba mi explicación de un
sistema de anonimato altamente utilizado, en algunos aspectos formidable y en
otros mejorable. Empecemos pues.
Para comprender las vulnerabilidades que presenta tor, primero quiero hacer un
breve repaso de cuál es el funcionamiento de esta popular herramienta.
Recordemos que tor garantiza nuestro anonimato mediante la interposición de
servidores intermedios que escondan nuestra identidad. Estos servidores
intermedios podían ser la puerta de entrada a la red, retransmisores intermedios o
la puerta de salida. Recordemos también que tor se basa en la generación de
circuitos telescópicos, de manera que un nodo solo conoce la identidad del servidor
anterior y posterior. Además, los retransmisores son clientes tor que se han
configurado en éste modo, por lo que cualquiera puede convertirse en retransmisor.
La fuerza de tor reside en la imposibilidad del servidor destino de conocer la
identidad de la persona que está realizando la petición. Pero que el servidor no
conozca tu identidad no implica que otra persona no pueda averiguar tu identidad.

Vulnerabilidades
Para romper el sistema de anonimato de tor, que yo sepa, hay cuatro grandes
caminos que puedes tomar: inyectar código, analizar la red tor, explotar fallos de
seguridad del navegador y explotar vulnerabilidades de la red tor.
Inyectar código:
Tor protege al cliente con los servidores intermedios, pero no hay nada que proteja
el servidor destino o la puerta de salida. Imaginemos que hay una persona que
quiere averiguar las identidades de las personas que visitan una página. Lo primero
que hará será buscar el servidor que aloja la página y controlarlo activa o
pasivamente. En definitiva, saber en todo momento lo que ocurre en el servidor para
monitorear las peticiones y analizarlas posteriormente. Ahora supongamos que el
espía se encuentra con que el servidor es visitado por numerosos clientes tor. No
sabe la identidad de los clientes ya que no son ellos los que visitan la página. Pero
puede hacer una cosa para delatarlos. Controla el servidor, por lo que puede alterar
el funcionamiento del mismo e introducir un trozo de código en todos los paquetes
TCP. Ahora supongamos que introduce algún tipo de malware; todas las personas
que visiten la página se infectarán. Por último, es fácil de suponer que el malware

-26-
puede acceder a tu dirección física, al funcionamiento de tu equipo, a tu ubicación…
Es decir, que el atacante puede identificarte cómodamente. Tan solo tiene que
inyectar código en los paquetes TCP para introducir en tu sistema un malware que
te identifique entre la masa de ordenadores que forman internet.
Analizar la red tor:
Cuando te conectas a tor, te conectas a una red de ordenadores formada por
clientes y retransmisores. A través de esta red te conectas al servidor que almacena
la página web. Sin embargo, la mayor virtud de tor es su mayor carencia. Tor es una
red relativamente pequeña de sistemas interconectados, lo que erróneamente
proporciona mayor confianza a los clientes. Ahora supongamos que alguien analiza
todo el tráfico de la red tor, y que en base a estudios estadísticos puede determinar
que un cliente se ha conectado a un servidor externo por medio de una puerta de
salida. ¿Es posible? Sí ¿En serio? Sí, numerosos países y operadoras de telefonía
actualmente lo hacen. Se necesita una potencia de cálculo inmensa, aunque es
menor si solo se estudian clientes tor concretos, es decir, aquellos que accedan a
unos servidores externos determinados o que pertenezcan a un país determinado.
Lo que se hace con este método es controlar la red tor, monitorear todas las
peticiones de todos los retransmisores y clientes para analizarlas posteriormente
con herramientas estadísticas y determinar qué clientes han accedido a qué
páginas. Como he dicho antes, se necesita una capacidad de cálculo brutal, pero es
posible que empresas gigantes, que manejan miles de millones de dólares al año,
acudan a esta técnica para revelar la identidad de ciertas personas. La única forma
de luchar con éste método desemboca en un peligro mayor: aumentar la red tor.
Pero si aumento la red tor para dificultar las tareas de cálculo, mayor número de
retransmisores no serán de confiar.
Explotar vulnerabilidades del navegador:
Supongamos que tienes tor instalado en un navegador. Pero en el navegador
también tienes instalado flash player, java, real media, quicktime, windows media,
shockwave o cualquier otro plugin. El hecho de que tor funcione bien, de que sea
seguro no implica que el navegador sea seguro. Si tienes habilitada tecnología
flash, puedes darte por fastidiado. El propio proyecto tor pone especial interés en
dejar claro que para utilizar tor no se pueden tener habilitados plugins que puedan
comprometer la seguridad del navegador. Los plugins en los que tor hace especial
hincapié son los que he mencionado anteriormente. A través de este tipo de
tecnologías, el atacante puede explotar las vulnerabilidades que presentan e
identificarte cómodamente. Repito: no habilites estos plugins cuando uses tor,
porque no eres anónimo. Simplemente configura el navegador para que esté lo más
limpio posible. No conozco las técnicas para explotar este tipo de vulnerabilidades,
ya que hay que tener conceptos de programación avanzados, pero puedes visitar
diferentes estudios que así lo demuestran.
Explotar vulnerabilidades de la red tor:
En este apartado me refiero a atacar la propia red tor explotando vulnerabilidades
que presenten y que no he reflejado en los tres anteriores apartados. Por ejemplo
se pueden bloquear las autoridades de directorio, bloquear las puertas de salida,
introducir falsos retransmisores, realizar ataques de denegación de servicio,
ataques de predecesor, ataques Sybil y un preocupante etcétera. Algunos están
solucionados, pero es viablemente imposible poder controlarlos todos, más aún
cuando son Gobiernos y agencias de inteligencia los que desarrollan técnicas para
explotarlos.

-27-
Alternativas
Voy a analizar dos alternativas, aunque existen varias, como GNUnet, Rodi,
Omemo, Nodezilla, Bunzilla o Calypso. Aunque la gran mayoría no son sustitutos de
tor, por eso en la introducción he entrecomillado la palabra alternativa. Casi todos
se basan en clientes P2P anónimos, como FreeNet; la única que realmente puede
sustituir a tor es I2P.
FreeNet:
Según el propio proyecto, FreeNet es:

Un proyecto de software libre que te permite compartir archivos

anónimamente, navegar y publicar sitios libres (a los que
accedes a través de FreeNet) y chatear en foros, sin el miedo de
la censura. FreeNet está descentralizado para hacerlo menos
vulnerablea a ataques y si es usado en el modo “darknet”, donde
los usuarios solo pueden conectarse con sus amigos, es muy
difícil de detectarlos.

Es decir, FreeNet es una iniciativa que proporciona una red en la que poder navegar
sin ser descubiertos. Pero siempre tienes que navegar dentro de la red, no existen
proxies de salida para acceder a internet. Es extremadamente útil para crear redes
anónimas, como la que actualmente utiliza WikiLeaks. Una vez que ya sabemos lo
que es, voy a comentar muy rapidito el funcionamiento para que nos hagamos una
idea.
Cuando accedes a la red, te conviertes en un nodo de la red. Cada nodo tiene que
contribuir con un ancho de banda y un espacio en disco determinado. Funciona
exactamente igual que un programa de P2P. Sin embargo, la diferencia es que está
totalmente descentralizado, no se depende de trackers y nadie sabe la identidad de
nadie (relativamente, luego ahondaré un poquito más). Simplemente se acceden a
recursos. Como es obvio, el ancho de banda que proporcionas se utiliza para que la
gente pueda descargarse los paquetes que quieran, pero ¿el espacio reservado en
el disco duro? Pues en este espacio almacenas los recursos de la red.
Al igual que en un programa P2P, todos contribuyen con todos; cuando me descargo
un archivo, me lo descargo de varios ordenadores, no de uno solo y de varios
archivos, no de uno solo. FreeNet funciona de forma parecida. Primero, un nodo
sube un archivo a la red, la red lo divide en partes, y envía cada parte a varios
nodos (para replicar la información y que siempre esté disponible). Así , si hay
alguien que quiere descargarse el archivo que ha colgado el usuario, se lo
descargará bajándose todas las partes de diferentes nodos. Además, todos los
paquetes están cifrados, de manera que los nodos no pueden acceder al contenido
que almacenan y alterarlo. También se deja claro que ninguna persona es
responsable de lo que almacene, por lo que si estoy almacenando un plano balístico

-28-
de un proyectil nuclear, legalmente no es mi culpa (aunque no impide que siga
estando muy intranquilo).
Por último, puedes conectarte a un nodo de dos formas: mediante Opennet o
Darknet. Lo normal es que cuando quieres acceder a un archivo, te conectes a la
red FreeNet y preguntes a un nodo por el recurso. La red se encarga de buscar los
nodos que tienen el archivo, estableces una conexión y te lo bajas. Este tipo de
funcionamiento es la Opennet:

Sin embargo, si por ejemplo sabes que un nodo tiene el archivo, quieres hablar con
un amigo a través de FreeNet o quieres acceder a un servidor interno, lo más
normal es que le digas a la red FreeNet que quieres establecer una conexión con el
nodo X. Es decir, que estableces una conexión directamente, sin preguntar a los
diferentes nodos. Este método de conexión es el DarkNet. Es muchísimo más
seguro que el OpenNet, ya que el nodo se supone que es de confianza, pero solo lo
puedes utilizar en determinados casos.
Por último, me gustaría destacar que este proyecto no sustituye a Tor, aunque
puede ser un complemento buenísimo, como así lo ha demostrado WikiLeaks.
También es necesario destacar que no es escalable, en el momento en el que haya
muchos nodos, simplemente no funciona, ya que para encontrar un nodo que
contenga el archivo pueden pasar desde horas a milisegundos. Vuelvo a repetir que
FreeNet y cualquier servicio de P2P anónimo no es un sustituto de tor, sino que más
bien es un complemento.
I2P (Invisible Internet Protocol):

-29-
Como en el caso anterior, os presento la definición del proyecto:

I2P es una red anónima que ofrece una simple capa para que
ciertas aplicaciones que manejan información sensible puedan
usarla para comunicarse de una forma segura. Todos los datos
son envueltos en distintas capas de codificación, además la red
es distribuida y dinámica, sin que haya que confiar en una
tercera parte.

Es decir, que es igual que FreeNet (nació de ese proyecto) pero dispone de proxies
para poder comunicarse con el exterior. A través de I2P podré usar clientes P2P,
chats, canales IRC o servidores de correo electrónico. Pero también podré usar la
red para conectarme a un proxy que realice la petición a un servidor externo. Sin
embargo, el funcionamiento es diferente al que presenta Tor. I2P es sensiblemente
más complejo, pero aparentemente más seguro. En la definición que he escrito
arriba pone que I2P proporciona una capa. Pero, ¿qué capa? Lo voy a explicar muy
resumido, obviando varios detalles para que se comprenda mejor, por este motivo
hay tantas palabras entrecomilladas XD.
Para el funcionamiento de internet, existen diversos protocolos que actúan en
diferentes capas. Estas capas tienen una función “determinada” por el modelo OSI
(capa física, capa de datos, capa de red, capa de transporte, capa de sesión, capa
de presentación y capa de aplicación). Así por ejemplo, el protocolo IP se
“encuentra” en la capa de red. Lo que I2P hace es generar una capa de más alto
nivel que “utilizan” las aplicaciones, y que se encuentra “encima” del protocolo IP
cuya misión es no revelar la identidad de los participantes en una conexión. Así
mismo, esta capa asigna una clave cifrada que identifica a cada nodo, maneja las
diferentes claves para poner en contacto a los dos participantes de la conexión y
establece un flujo UDP entunelado entre los dos participantes. Es decir, que cuando
yo me conecto a I2P y realizo una petición de conexión a un nodo, la aplicación lo
identifica con la clave cifrada que le proporciona I2P, establece la conexión con
esas claves y a partir de entonces se genera una conexión protegida del protocolo
UDP (un protocolo para transmitir paquetes parecido al TCP).
Al igual que en tor existían las autoridades de directorio, en I2P existen las Network
Databases. La diferencia es que son muchísimo más seguras que las autoridades
de directorio, están bastante más replicadas y el acceso a la información es más
seguro. Estas bases de datos tienen dos tipos de archivos: los que se refieren a los
nodos de la red (RouterInfos) y los que se refieren a un servidor interno (LeaseSets
). Es decir, que si quiero acceder a un servidor externo, preguntaré por diversos
RouterInfos, pero si quiero acceder a un servidor interno solo preguntaré por los
LeaseSets. La consecuencia de este procedimiento es una total separación entre la
actividad que muestra más peligro (acceder a internet a través de I2P) y las que se
supone que es más confiable (acceder a un nodo interno para compartir un archivo,
para hablar con un amigo…), por lo que la seguridad del sistema aumenta
considerablemente.
Ahora las consecuencias de este planteamiento. Es bastante más complejo que tor
(solo con leer los dos párrafos anteriores queda reflejado), pero el hecho de que
toda la conexión esté entunelada bajo un protocolo que no permite identificar a los
participantes de la conexión hace del sistema bastante más seguro y anónimo que
tor. También hay que decir que I2P es mucho menos escalable que tor, tiene una
comunidad mucho más pequeña, su desarrollo es más lento, la complejidad del

-30-
proyecto hace que haya menos aplicaciones dedicadas y puede caer a ataques a los
que tor es inmune.
Con este párrafo se acaban los cuatro artículos que pretenden explicar el
funcionamiento de tor. Quería agradecer especialmente a Joe Di Castro, lector de
PillateUnLinux, la aclaración que realizó en la primera entrega y que ha posibilitado
que éste último capítulo se haya escrito. Tal y como comentó Debish en otro
comentario,voy a pasar a un documento los cuatro artículos para que los podáis leer
con más tranquilidad. Colocaré al final de este artículo un enlace para descargarlo
cuando tenga algo de tiempo (en unos días, supongo que para el sábado estará).
Conclusión:
Como dicen los desarrolladores de I2P, el anonimato es el incremento de tiempo y
dinero que tiene que realizar una organización para dar con tu identidad. No creo
que exista el anonimato en internet, siempre se puede llegar a identificar a una
persona. Sin embargo, con el uso de varias tecnologías, se puede llegar a ser
bastante anónimo. Wikileaks así lo demuestra.
Fuentes:
RedesCebolla
Tor
FreeNet
I2P
Wikipedia
Zed A. Shaw
Artículos anteriores:
Tor (parte I)
Tor (parte II)
Tor (parte III)

-31-