Tor

1
Tor
Tor
Desarrollador
The Tor Project
www.torproject.org
[1]
Informacin general
Lanzamiento inicial 20 de septiembre de 2002
ltima versin estable
0.2.4.22 (info
[2]
)
16 de mayo de 2014
Gnero Onion routing, Anonymity, Cultura libre, Comunidad
Programado en C
Sistema operativo Multiplataforma
Licencia licencia BSD
En espaol
S
The Onion Router, en su forma abreviada Tor, es un proyecto cuyo objetivo principal es el desarrollo de una red de
comunicaciones distribuida de baja latencia y superpuesta sobre internet en la que el encaminamiento de los
mensajes intercambiados entre los usuarios no revela su identidad, es decir, su direccin IP (anonimato a nivel de
red) y que, adems, mantiene la integridad y el secreto de la informacin que viaja por ella. Por este motivo se dice
que esta tecnologa pertenece a la llamada darknet o red oscura tambin conocida con el nombre de deep web o web
profunda.
Para la consecucin de estos objetivos se ha desarrollado un software libre especfico. Tor propone el uso de
encaminamiento de cebolla de forma que los mensajes viajen desde el origen al destino a travs de una serie de
routers especiales llamados 'routers de cebolla' (en ingls onion routers). El sistema est diseado con la flexibilidad
necesaria para que pueda implementar mejoras, se despliegue en el mundo real y pueda resistir diferentes tipos de
ataque. Sin embargo, tiene puntos dbiles y no puede considerarse un sistema infalible.
No es una red entre iguales (peer-to-peer) ya que por un lado estn los usuarios de la red y por otro lado los
encaminadores del trfico y algunos de los cuales hacen una funcin de servicio de directorio.
La red funciona a partir de un conjunto de organizaciones e individuos que donan su ancho de banda y poder de
procesamiento. Segn informacin obtenida de los documentos de alto secreto filtrados por Edward Snowden en
2013, la Agencia de Seguridad Nacional de Estados Unidos (NSA) habra, supuestamente, conseguido "romper" Tor
y as descubrir las identidades de los usuarios que buscan el anonimato.
Tor
2
Historia
El 20 de septiembre de 2002 se anunci una versin alfa del software libre con la red del encaminamiento de cebolla
en funcionamiento. Creado en 2003 por Roger Dingledine, Nick Mathewson y Paul Syverson surgi como la
evolucin del proyecto Onion Routing del Laboratorio de Investigacin Naval de los Estados Unidos (por eso se dice
que es la segunda generacin de onion routing). Inicialmente financiado por el Laboratorio de Investigacin Naval
de los Estados Unidos. A finales de 2004 pas a ser patrocinado por la Electronic Frontier Foundation, la
organizacin de defensa de libertades civiles en el mundo digital, hasta noviembre de 2005. Actualmente el proyecto
Tor est en manos del 'Tor project' una organizacin sin nimo de lucro orientada a la investigacin y la educacin,
radicada en Massachusetts y que ha sido financiada por distintas organizaciones.
[3]
Actualmente el proyecto est
formado por un equipo
[4]
liderado por Roger Dingledine.
En marzo de 2011, Tor recibi de la Free Software Foundation el premio para proyectos de beneficio social
correspondiente a 2010 por haber permitido que, aproximadamente, 36 millones de personas de todo el mundo,
usando software libre, hayan experimentado libertad de acceso y de expresin en Internet manteniendo su privacidad
y anonimato. Su red ha resultado crucial en los movimientos disidentes de Irn y Egipto.
Aplicacin y limitaciones
El objetivo principal de Tor (no logrado al 100%) es conseguir que internet pueda usarse de forma que el
encaminamiento de los mensajes proteja la identidad de los usuarios. Es decir, persigue que no se pueda rastrear la
informacin que enva un usuario para llegar hasta l (su direccin IP). El uso ms habitual de Tor es aprovechar sus
caractersticas para lograr cierto grado de privacidad en la navegacin web en internet. Sin estar especialmente
diseado para ello, pronto se descubri que Tor tambin hace ms difcil la labor de programas que intentan censurar
o vigilar el acceso a cierto tipo de contenidos. Todo esto ha provocado que Tor sea muy usado en entornos en los que
los comunicantes estn especialmente motivados en proteger su identidad y el contenido de sus comunicaciones (Ej.
conflictos polticos, restricciones en la difusin y acceso a ciertos tipos de contenido, comunicacin de informacin
confidencial etc.)
[5]
Observar que el enrutado annimo no asegura el que la entidad origen sea desconocida para la entidad destino.
Esto es debido a que los protocolos de nivel superior pueden transmitir informacin sobre la identidad. Por ejemplo
un servicio web puede usar cookies o simplemente pedir que nos identifiquemos. Cuando queremos un anonimato a
nivel de aplicacin es bueno configurar el cliente adecuadamente y protegernos usando proxys que modifican los
contenidos en este sentido. Por ejemplo para conseguir ms privacidad cuando navegamos por la web es
recomendable configurar el navegador adecuadamente (Ej. deshabilitando cookies, no permitiendo plugins Java,
Flash o ActiveX, o deshabilitando el historial) y redirigir el trfico hacia un proxy web intermedio (Ej. privoxy o
polipo) que nos filtre contenido que puede ser aprovechado para violar nuestra privacidad (Ej cookies o cabeceras
HTTP que puedan ser usadas para identificar).
La red Tor cifra la informacin a su entrada y la descifra a la salida de dicha red (encaminamiento de cebolla). Por
tanto el propietario de un router de salida puede ver toda la informacin cuando es descifrada antes de llegar a
Internet, por lo que aunque no pueda conocer el emisor s que puede acceder a la informacin. Esta debilidad ha sido
aprovechado por algunos atacantes. Por ejemplo Dan Egerstad, un sueco experto en seguridad informtica, cre un
servidor en la red Tor y controlando toda la informacin que sala por l hacia Internet, pudo conseguir contraseas
de importantes empresas, embajadas de todo el mundo y otras instituciones. Para paliar esta debilidad y asegurarnos
de que nadie accede a la informacin que se est enviando, es recomendable usar un protocolo que provea cifrado al
protocolo de aplicacin como SSL). Por ejemplo para trficos HTTP es recomendable usarlo sobre SSL (HTTPS).
Como hemos comentado Tor es usado principalmente para ocultar la identidad de los usuarios que utilizan servicios
habituales de internet. Sin embargo tambin proporciona caractersticas que permiten la comunicacin interactiva de
entidades que quieren ocultar su identidad (mediante los llamados puntos de encuentro) y proveer servicios
Tor
3
ocultando la identidad de la entidad que provee dicho servicio (mediante los llamados servicios ocultos).
Interfaz de entrada
Tor slo permite anonimizar trfico TCP. Las aplicaciones acceden a la red TOR a travs del interfaz SOCKS lo cual
significa que toda aplicacin con soporte SOCKS puede usar TOR para realizar comunicaciones annimas sin
necesidad de modificaciones adicionales. El cliente Tor recibe trfico SOCKS desde nuestras aplicaciones y luego,
de forma transparente, se encarga de comunicarse con los routers de la red Tor para enviar las peticiones y
posteriormente devolvernos los resultados.
SOCKS es un protocolo que facilita el enrutamiento de paquetes que se envan entre un cliente y un servidor a travs
de un servidor proxy. Segn la pila de protocolos OSI est en el nivel 5 (sesin). Segn la pila de protocolos IP est
en la capa de aplicacin. En los primeros intentos de usar encaminamiento de cebolla se requera un proxy de
aplicacin para cada protocolo de aplicacin soportado. Esto conllevaba mucho trabajo y provocaba que algunos
proxys no fueran escritos nunca y por tanto algunas aplicaciones nunca fueron soportadas. Tor usa SOCKS para, de
un plumazo, soportar la mayora de programas basados en TCP sin hacer ninguna modificacin.
Observar que cuando navegamos por internet hacemos dos tipos de peticiones:
Peticiones DNS para que el servidor de DNS que nos diga la direccin IP de una URL
Peticiones HTTP a las direcciones IP del servidor web que aloja la informacin.
Si no pasamos por Tor las bsquedas con DNS que hacen los navegadores, pueden ser un problema de privacidad ya
que si las peticiones se mandan directamente a travs de la red regular un atacante podra deducir qu sitios se estn
visitando a travs de Tor ya que antes de navegar por ellos se pregunta por DNS que IP tienen. Por tanto es necesario
redirigir el trfico de DNS por la red Tor.
Algunas aplicaciones convierten directamente el trfico del protocolo la capa de aplicacin en trfico SOCKS. Por
ejemplo Firefox permite convertir tanto el trfico DNS como el HTTP a SOCKS y envirselo al cliente Tor. Otras
aplicaciones necesitan redirigir el trfico del protocolo de la capa de aplicacin hacia un proxy que realice la
conversin al protocolo SOCKS. Por ejemplo si tuvieramos un navegador que no permitiera el trfico HTTP y DNS
va SOCKS podra usar privoxy para realizar esta tarea (y podramos aprovechar para filtrar las peticiones HTTP). Si
tenemos una aplicacin genrica que no soporta SOCKS y queremos que su trfico TCP se convierta a formato
SOCKS para luego pasarlo al cliente Tor es necesario utilizar una aplicacin adicional. En linux podramos usar el
comando torify (de ah viene el trmino torificar). En Windows podramos usar Freecap (software libre), SocksCap
o Torcap.
Tor
4
Funcionamiento
Componentes
La red est formada por una serie de nodos que se comunican mediante el protocolo TLS sobre TCP/IP manteniendo
as secreta e ntegra (no modificaciones externas) la informacin desde un nodo a otro. Hay 2 tipos de entidades:
Nodos OR o simplemente OR ( del ingls Onion Router): Funcionan como encaminadores y en algunos casos
adems como servidores de directorio (DNS) de una especie de servicio de mantenimiento. Los nodos OR
mantienen una conexin TLS con cada uno de los otros OR. Las conexiones OR-OR no son nunca cerradas
deliberadamente salvo cuando pasa cierto tiempo de inactividad. Cuando un OR comienza o recibe nueva
informacin de directorio l intenta abrir nuevas conexiones a cualquier OR que no est conectado.
Nodos OP o simplemente OP (del ingls Onion Proxy): Los usuarios finales ejecutan un software local que hace
la funcin de nodo OP y que su funcin es obtener informacin del servicio de directorio, establecer circuitos
aleatorios a travs de la red y manejar conexiones de aplicaciones del usuario. Los OP aceptan flujos TCP de
aplicaciones de usuarios y las multiplexa a travs de la red OR's. Las conexiones OR-OP no son permanentes. Un
OP debera cerrar una conexin a un OR si no hay circuitos ejecutndose sobre la conexin y ha vencido cierto
temporizador
Servicio de directorio
El servicio de directorio publica una base de datos que asocia a cada OR una serie de informacin (router descriptor).
Esta informacin es accesible a todos los OR y a todos los usuarios finales y la usan para tener un conocimiento de la
red. Si se tienen pocos servidores de directorio se corre el riesgo tener un punto cuyo fallo puede ocasionar el fallo
del sistema completo. Por motivos de backup y de latencia los OR que dan el servicio de directorio mantienen
duplicada la informacin pasndosela de unos a otros. Hay una serie de OR principales (autoridades de directorio) y
luego hay otros secundarios que hacen de caches y backup (directory caches). Una lista de algunos servidores de
directorio son distribuidos con TOR para facilitar la suscripcin a la red (bootstrapping). Los servidores de directorio
son en realidad un grupo establecido de ORs confiables. Para dar fiabilidad a la informacin que da el servicio de
directorio las entradas son protegidas criptogrficamente con firmas y slo la informacin que proviene de ORs
aprobados ser publicada en la base de datos. Por tanto todo nodo nuevo tiene que ser previamente aprobado y de
esta forma se evitan ataques en los que alguien aade muchos nodos no confiables. No hay sistema automtico para
aprobar OR's; Los administradores del servidor de directorio lo hace manualmente.
Tor
5
Cuando un OR se arranca, recolecta un conjunto de datos que lo describen a l, a su modo de funcionamiento y
capacidades. Ejemplos de este tipo de atributos son la direccin IP, nombre amigable para el usuario, versin del
software TOR, sistema operativo, clave pblica, exit policies (restricciones a como puede funcionar el nodo si es el
ltimo nodo de un circuito de datos Ej: definir una lista de direcciones IP y nmero de puertos a los cuales est
dispuesto llevar el trfico. Observar que usando esto se puede hacer que un nodo no pueda actuar como ltimo nodo
de un circuito nunca). Toda esta informacin se publica a travs del servicio de directorio.
Esquema bsico
El funcionamiento a grandes rasgos es el siguiente:
A partir de la informacin obtenida de su configuracin y del servicio de directorio el OP decide un circuito por el
que van a circular los paquetes. Por defecto el circuito tienen 3 nodos OR.
El OP negocia, usando un enfoque telescpico, las claves de cifrado necesarias con cada OR del circuito para
proteger sus datos en todo el camino antes de realizar transmisin alguna. La obtencin de las claves simtricas
(AES-128), una para cada sentido de comunicacin (Kf<- forward key, Kb<-backward key), se realiza a partir del
protocolo de establecimiento de claves Diffie-Hellman para obtener una clave compartida y a partir de ella derivar
las dos claves simtricas El circuito es construido desde el punto de entrada (usuario) de la siguiente forma: Los
mensajes para negociar las claves de la comunicacin entre ORn y ORn+1 se realizadas a peticin del OP y
retransmitiendo paquetes a travs de los nodos OR1,... ORn. En cada paso los mensajes son cifrados con las
claves de sesin negociadas, o cuando no lo estn, con la clave de cebolla del host que recibe el dato
A continuacin cifra el paquete que contiene la clave para el ltimo OR del circuito,
A continuacin hace lo propio del penltimo
Hace lo mismo con todos los nodos hasta hacer lo propio con el paquete para el primer nodo.
Enva el paquete resultante al primer nodo del circuito. Observar que el paquete construido con este proceso se
puede considerar como un paquete envuelto en varias capas de cifrado. Por eso se usa la metfora de la cebolla
para describir este tipo de mtodo de encaminamiento (encaminamiento de cebolla).
El primer OR quita 'su' capa de la cebolla y enva el paquete al siguiente nodo
Segn va llegando el paquete a cada OR ste pela la capa externa. De esta forma ningn OR puede hacerse con la
imagen completa del circuito ya que slo conoce los OR/OP anterior y posterior.
Como terminologa se llama 'exit server' o 'exit node' al ltimo servidor del circuito (y por tanto el nico que se
comunica con el destino), el primer OR se le llama 'entry node' (nico que se comunica con el origen de la
comunicacin) y al resto de nodos se les llama middle-node.
Podemos observar que la forma en la que se establecen las claves y todas estas capas de cebolla que se construyen
con ellas permiten que la informacin permanezca secreta mientras va circulando por el circuito de nodos OR.
Adems, al estar el cifrado de las capas basado en claves de sesin, aunque un atacante recopilara todos los mensajes
no podra descifrarlos una vez que estas claves de sesin son descartadas por el OR (perfect forward secrecy).
Puntos de encuentro
La idea de los puntos de encuentro, denominados por las siglas RP (del ingls Rendezvous Points), es, en lugar de
explcitamente enviar un paquete a un destino, establecer un punto de encuentro que acte como nivel de indireccin.
De esta forma desacoplamos el acto de enviar del acto de recibir. Cada extremo de la comunicacin enva sus
mensajes a ese punto de encuentro y desde ah son enviados a donde corresponda usando circuitos que esconden la
localizacin del destino. Por ejemplo podramos usar este sistema para conectarnos a un servidor de chat IRC.
Tor
6
Servicios ocultos
Los servicios que ocultan la localizacin (por ejemplo, la direccin IP) de quien provee el servicio (Ej. un servicio
web accesible slo desde la red de encaminamiento de cebolla) se les suele llamar servicios de localizacin oculta
(en ingls location-hidden services) o simplemente servicios ocultos (en ingls hidden services).
[6][7]
Para soportar esta funcionalidad los proveedores de servicios generan una clave pblica y privada para
identificar su servicio. A continuacin anuncian su servicio a distintos routers, haciendo peticiones firmadas con su
clave pblica, para que sirvan como punto de contacto. A los routers con esta funcin se les llama puntos de
introduccin, en ingls introduction point. El proveedor de servicio asocia a su servicio una FQDN del pseudo-TLD
.onion y la publica en un servidor de directorio. La FQDN tiene la forma <valorhash>.onion donde el valor hash es
de 16 caracteres en Base32 y est generado usando una funcin hash sobre la clave pblica del servicio. Cuando un
cliente se quiere conectar a cierta FQDN (por ejemplo ha encontrado la direccin a travs de un sitio web) consulta
un servicio de bsqueda (lookup service) y este le indica un punto de introduccin (introduction point) y la clave
pblica del servicio. Observar que para mantener el anonimato es necesario que la consulta del servicio de bsqueda
se realice a travs de Tor. A continuacin el cliente se conecta con un punto de encuentro (esto lo podra haber hecho
antes) y se establece un identificador de esa conexin (rendezvous cookie). A continuacin el cliente le enva un
mensaje, firmado con la clave pblica del servidor, al punto de introduccin indicndole el punto de encuentro
donde est, el identificador que permita identificar al cliente en el punto de encuentro (la rendezvous cookie) y parte
del protocolo Diffie-Hellman ((start of a DH handshake). A continuacin el punto de introduccin enva el mensaje
al servidor del servicio el cual determina si se conecta al punto de encuentro para proveerle el servicio o no. Si
determina que quiere conectarse con l entonces se conecta al punto de encuentro y le indica a este el identificador
del cliente con el que quiere conectarse (la rendezvous cookie), la segunda parte del Diffie-Hellman (the second half
of the DH handshake) y un hash de la clave que comparten. A continuacin el punto de encuentro conecta a el
cliente y el servidor y se establece una comunicacin normal.
Clulas
Una vez que se establece la conexin TLS, ya sea OP-OR o OR-OR, las entidades se envan paquetes de informacin
estructurada llamadas clulas. Estas clulas tienen tamao fijo de 512 bytes y pueden ser enviadas en registros TLS
de cualquier tamao o dividido en varios registros. Los registros de TLS no tienen que revelar ninguna informacin
sobre el tipo o el contenido de las clulas que contiene. Varios circuitos pueden ser multiplexado sobre una misma
conexin TLS. Las clulas estn formadas por una cabecera y una carga til.
Formato:
Formato de clula de Tor
circID.- Es el identificador de circuito y especifica el circuito a el
que se refiere la clula
CMD.- Indica el comando que especifica el significado de la clula.
Atendiendo al tipo de comando (valor de CMD) hay 2 tipos de
clulas: Clulas de control y Clulas de transmisin
Tor
7
Clulas de control
Las clulas de control (en ingls control cell) son siempre interpretadas por el nodo que las recibe y permiten
controlar la comunicacin.
Comandos que tienen estas clulas:
PADDING (cdigo 0).-Actualmente no usadas porque los ataques existentes funcionan incluso con trfico de
relleno y porque el trfico que provocan incrementa el ancho de banda necesario. Adems de stas las celdas del
tipo RELAY_DROP puede crearse tambin para crear tambin trfico de relleno.
CREATE (cdigo 1).-Para crear circuito
CREATED (cdigo 2).-ACK de CREATE
DESTROY (cdigo 4).-Destruir circuito
CREATE_FAST (cdigo 5).-Crear un circuito reaprovechando operaciones de clave pblica existentes),
CREATED_FAST (cdigo 6).-ACK de CREATE_FAST
VERSIONS (cdigo 7).-Usado cuando se establecen las conexiones),
NETINFO (Cdigo 8).-Usado cuando se establecen las conexiones),
RELAY_EARLY (cdigo 9)
Clulas de transmisin
Las clulas de transmisin (en ingls relay cell) son usadas para la comunicacin entre el OP y cualquiera de los OR
del circuito, normalmente el exit node. Por ejemplo esto se usa cuando se quiere cambiar la parte final del path de un
circuito (RELAY_TRUNCATE).
En las ltimas versiones el sistema permite trfico de salida desde nodos OR que no son los ltimos del circuito. Esto
permite frustar ataques que se basan en la observacin del trfico de salida del exit node.
Este tipo de clulas se distinguen porque el valor del campo CMD siempre tiene el comando RELAY (cdigo 3).
En este tipo de clulas el formato tiene campos que forman parte de la carga til (PAYLOAD):
Formato de clula relay en Tor
Relay command.- El el subcomando RELAY que indica el
funcionamiento de la celda.
Hay tres tipos de subcomandos relay:
forward: Son enviados desde el OP origen del circuito
backward: Son enviados desde los OR del circuito al OP origen
ambos: Pueden funcionar como forward o como backward
Posibles subcomandos:
RELAY_BEGIN (cdigo 1).- De tipo forward
RELAY_DATA (cdigo 2).- De tipo forward o backward
RELAY_END (cdigo 3).- De tipo forward o backward. Permite indicar el cierre de un stream TCP e indica el
motivo
RELAY_CONNECTED (cdigo 4).- De tipo backward
RELAY_SENDME (cdigo 5).- De tipo forward o backward. A veces se usa para funciones de control
(streamID=0)
RELAY_EXTEND (cdigo 6).- De tipo forward. Se usa para funciones de control (como veremos
streamID=0)
RELAY_EXTENDED (cdigo 7).- De tipo backward. Se usa para funciones de control (streamID=0)
RELAY_TRUNCATE (cdigo 8).- De tipo forward. Se usa para funciones de control (streamID=0)
RELAY_TRUNCATED (cdigo 9).- De tipo backward. Se usa para funciones de control (streamID=0)
RELAY_DROP (cdigo 10).- De tipo forward o backward. Se usa para funciones de control (streamID=0)
Tor
8
RELAY_RESOLVE (cdigo 11).- De tipo forward
RELAY_RESOLVED (cdigo 12).- De tipo backward
RELAY_BEGIN_DIR (cdigo 13).- De tipo forward
Los cdigos 32 al 40 son usados para servicios ocultos
Recognized: Campo que junto con el campo digest permite identificar si la celda es para ser procesada
localmente.
StreamID: Es el identificador de flujo. De esta forma se permite que varios flujos puedan ser multiplexados en un
solo circuito. Este campo permite identificar el stream al que nos referimos entre los mltiples streams del
circuito. Es seleccionado por el OP y permite a el OP y al exit nodo distinguir entre mltiples streams en un
circuito. Las clulas que afectan al circuito entero en lugar de a un streamID particular tienen este campo a 0 y se
pueden considerar como de control.
Digest.- Permite el control de integridad extremo a extremo (end-to-end integrity checking). Contiene los
primeros cuatro bytes de ejecutar SHA-1 sobre TODOS los bytes de clulas relay que han sido enviados a este
nodo del circuito o originados desde este nodo del circuito (slo conocidos por el origen y el destino ya que van
cifrados), usando las semillas Df o Db respectivamente (slo conocidas por el origen y el destino), e incluyendo la
carga til entera de esta clula RELAY cogiendo el campo digest a zero. Por la visibilidad de los datos un nodo
intermedio nunca podra calcular este valor de digest. Se ha estimado con 4 bytes de digest la posibilidad de que
un adversario adivine por casualidad un hash vlido es suficientemente baja. Es claro que cada nodo necesita
mantaner el SHA-1 de los datos recibidos y enviados para poder ir calculando este digest.
length.- Indica el nmero de bytes del campo DATA que contiene carga til real. El resto del campo ir rellenado
por bytes a NUL
Una clula se considera completamente descifrada si el campo Recognized est a ceros y el campo Digest es el
primero de los 4 bytes resultado de ejecutar la funcin de digest de todos los bytes 'destinados a' o 'originados desde'
este salto del circuito. Si una celda no est completamente descifrada se pasa al siguiente salto del circuito. Si la
clula se ha comprobado que est completamente descifrada pero el comando de la clula no se entiende la clula
ser borrada e ignorada pero su contenido todava cuenta respecto a los digests. Observar que el campo Recognized
permite, de una forma muy rpida, descartar ciertas clulas como candidatas a estar completamente descifradas.
El contenido completo de la cabecera y de la carga til es encriptado usando la clave AES-128 negociada en el
establecimiento de circuito y haciendo un cifrado AES-128 en counter mode (AES-CTR).
Claves de OR
Cada OR tiene asociados una serie de pares de claves pblica/privada:
Una clave larga de identidad (en ingls Identity Key) que sirve slo para firmar informacin (Ej: descriptor de
las capacidades del OR o info de directorio cuando acta como servidor de directorio) y certificados, y e usado
para permitir identificacin. Para denotar la clave de identidad de el nodo OR n usamos PKORn_ID
Una clave mediana de enrutamiento de cebolla (en ingls Onion Key) que sirve para cifrar las peticiones de
establecimiento de circuito (CREATE) para negociar las claves efmeras. Las claves viejas deben ser aceptadas
durante al menos una semana despus de que haya sido cambiada para dar tiempo a que todo haya sido
actualizado. Para denotar la onion key de el nodo OR n usamos PKORn_OK
Una clave pequea de conexin (en ingls Connection Key) usada en el handshake TLS. Esta clave se mete en
un certificado que se firma con la clave de identificacin. Ambos certificados (certificado de la clave de conexin
y certificado de la clave de identificacin) se envan en el handshake del TLS. El certificado de la clave
identificacin est firmado por la clave de identificacin. El certificado de la clave de identificacin est
autofirmado. Esta clave debera cambiarse frecuentemente, al menos una vez al da.
Tor
9
Algoritmos de cifrado usados
Para establecer las conexiones TLS usa TLS/SSLv3. Todos los OR y OP tienen que soportar
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA y deberan tener disponible
TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Los OP para comunicarse con los OR pueden usar:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Como algoritmo simtrico de cifrado se usa AES en counter mode (AES-CTR) con claves de 128 bits, con vector
de inicializacin con todos los bytes a 0
Como algoritmo de clave pblica usa RSA con claves de 1024 bytes y exponente fijo 65537. Usa como esquema
de relleno OAEP-MGF1 con SHA-1 usado como funcin resumen
Como funcin resumen usa SHA-1
Para establecimiento de claves usa DH (Diffie-Hellman) con g=2 y para p usamos el primo seguro de 1024 bits
obtenido de RFC2409 con valor hexadecimal:
FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E08
8A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B
302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9
A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE6
49286651ECE65381FFFFFFFFFFFFFFFF
Funcionamiento detallado
Establecimiento e inicializacin de circuito
Intercambio de mensajes para establecimiento de circuito
La cadena de ORs que forman un circuito es construida de forma telescpica, esto es, el OP negocia las claves de
sesin con cada sucesivo OR. Una ventaja de esta forma de operar es que se dejen una vez que stas claves de sesin
se dejen de utilizar y sean borradas, aunque un nodo sea comprometido no se podr descifrar clulas viejas (perfect
forward secrecy). El esquema se realiza con siguientes pasos:
El OP escoge un OR como exit node (ORn), de acuerdo con su exit policy.
EL OP escoge una cadena de OR's para constituir el path del circuito (OR1....ORn) de forma que ningn OR
aparece dos veces en el path.
El OP abre una conexin TLS con el entry-node (OR1 ) si es que no la tena abierta
El OP escoge aleatoriamente un ID de circuito (circID) que no se est utilizando en la conexin con el entry-node
El OP inicia un intercambio de clave Diffie-Hellman con el entry-node envando una celda CREATE
Tor
10
El entry-node le devuelve una cella CREATED y de esta forma se obtiene una clave compartida Diffie-Hellman
(D-H). De esta clave se derivan dos claves simtricas, una para cada sentido:
kf1 (forward key).- Se usar en la comunicacin OP->OR1 del circuito
kb1 (backward key).- Se usar en la comunicacin OR1->OP.
A continuacin el OP enva una peticin a el OR1 para extender el circuito mediante una clula
RELAY_EXTEND. Esta clula le indica al OR1 cual va a se el nuevo nodo OR2, su puerto y tambin contiene
estructuras de datos que le tendr que reenviar el OR1 al OR2 y que permitirn establecer un protocolo D-H de
intercambio de claves entre el OP y OR2 a travs de OR1 sin que el OR1 se entere de nada
El OR1 coge la clula y realiza el procedimiento Diffie-Hellman escogiendo l mismo un nuevo circID
apropiado. Observar que ahora la clulas CREATE/CREATED se intercambian entre el OR1 y el OR2.
El OR1 manda al OP una clula RELAY_EXTENDED para mandarle lo que ha respondido el OR2 y as el OP
tiene conocimiento de la clave D-H. La informacin est cifrada de tal forma que el nodo OR1 no puede acceder
la informacin que se estn intercambiando indirectamente el OP y OR2. De esta forma se establecen las nuevas
claves simtricas: kf2 y kb2.
De forma similar se contina hasta conseguir que el OP tenga establecidas las claves kf1, kb1, kf2, kb2,..., kfn,
kbn con los respectivos nodos OR.
En cada establecimiento de clave Diffie-Hellman se obtiene un valor g^xy que es usado para calcular un valor K
obtenido con la siguiente frmula:
K=H( g^xy | [00] ) | H( g^xy | [01] )....| H( g^xy | [04] )
donde:
| es la concatenacin
[NN] es un byte cuyo valor es NN
H(x) es el SHA-1 de x
A partir de K se sacan una serie de valores derivados que se van usando en el proceso:
derivative key (KH): Primer HASH_LEN bytes. Usado en la respuesta del handshare para demostrar el
conocimiento de la clave compartida
digest forward (Df): Segundo HASH_LEN bytes. Es usado como semilla de la comprobacin de integridad para
flujos de datos desde OP a OR
backguard digest (Db):Tercer HASH_LEN bytes. Es usado como semilla de la comprobacin de integridad para
flujos de datos desde OR a OP
forward key (Kf): Es usado para encriptar los flujos de datos desde OP a OR
backguard key (Kb): Es usado para encriptar los flujos de datos desde OR a OP.
Clula CREATE
Clula CREATE inicial en el establecimiento del circuito
Sobre el formato de la clula CREATE
cabe sealar que el cifrado de g^x se
hace de forma hbrida (con
RSA-OAEP se cifra una clave de
sesin y parte de g^x, con la clave de
sesin se cifra el resto de g^x) para
permitir que en una sola clula
podamos hacer el intercambio del g^x
completo.
Tor
11
Cuando inicializamos el primer salto de un circuito, el OP puede tener ya establecida la identidad del OR y
negociado una clave secreta usando TLS. Por tanto no siempre es necesario para el OP realizar operaciones de clave
pblica para crear el circuito. En este caso el OP puede enviar una clula CREATE_FAST en lugar de una clula
CREATE slo para el primer salto. El OR responde con un CREATED_FAST, cuando el circuito est creado. La
clula CREATE_FAST contiene una clave X generada aleatoriamente. La clula CREATED_FAST contiene una
clave Y generada aleatoriamente y un hash de la clave derivada construida a partir de X e Y. La clave compartida
entre el OP y el OR ser la concatenacin de X e Y. Por tanto cuando detectamos un CREATE_FAST podemos estar
seguros de que el nodo OR es el primero del circuito. Por tanto los ORs deberan rechazar intentos de crear streams
con RELAY_BEGIN (que sirven para indicar a los nodos que son exit node y por tanto tienen que enviar el
contenido a cierta IP) saliendo del circuito en el primer OR. De esta forma se evitan cierto tipo de ataques.
Clula CREATED
Clula CREATED inicial en el establecimiento del
circuito
El valor resumen de la clave establecida se manda para poder hacer una verficacin de que ambos extremos de la
comunicacin comparten la misma clave.
Clula RELAY_EXTEND
Clula RELAY_EXTEND inicial en el establecimiento del circuito
Son de especial inters los siguientes campos:
La direccin (address) IPv4 y el puerto (port) del prximo OR del circuito.
El campo streamID vale 0 porque este tipo de clulas relay sirven para control.
Tor
12
El campo SHA-1(PCKS#1(PKOR1_ID)) es el hash SHA-1 del PKCS#1 con codificacin ASN.1 de la clave de
identidad (PKOR_ID) del prximo OR. Esto permite prevenir cierto tipo de ataques man-in-the-middle.
Observar que cuando el OR1 descifra con su clave AES obtiene distintos campos y entre ellos obtiene la siguiente
piel de cebolla que puede utilizar directamente en la clula CREATE que tiene que construir para envirsela al OR2.
Clula RELAY_EXTENDED
Clula RELAY_EXTENDED inicial en el establecimiento del circuito
Observar que consiste en la comunicacin de la respuesta al protocolo Diffie-Hellman que hace el OR2 al OP usando
al OR1 como intermediario sin que ste pueda inferir informacin alguna. El campo streamID vale 0 porque este tipo
de clulas relay sirven para control.
Encapsulamiento de streams TCP
Una vez que un circuito se ha establecido se procede con el encapsulamiento de los streams TCP que contienen los
datos de la aplicacin.
Un circuito ya establecido se puede aprovechar para multiplexar en l varios streams TCP provenientes de la misma
o de distintas aplicaciones. De hecho, por eficiencia, Tor usa el mismo circuito para nuevos streams TCP durante
diez minutos siempre que sea posible por la exit policy del exit node. Transcurridos los diez minutos, las peticiciones
se darn a un nuevo circuito. Esto mejora la proteccin y evita que un atacante vincule trficos antiguos con los
nuevos.
El circuito permanecer abierto hasta que todos los TCP streams que multiplexe hayan cerrado. Esta caracterstica es
necesaria para soportar muchos protocolos como SSH, los cuales son incapaces de mantener una sesin si se
cambian los circuitos y, por tanto, el exit node, durante la sesin.
Tor
13
Conexin HTTP a travs de un circuito en Tor
Los pasos para encapsular el trfico TCP son los siguientes:
El OP escoge un circuito abierto que tenga un exit node que le permita conectarse de la formada adecuada con el
servidor. Si no existe, lo crea segn el algoritmo visto anteriormente
El OP selecciona un StreamID arbitrario que no haya sido utilizado todava en el circuito
El OP construye una clula RELAY_BEGIN que contiene, cifrado adecuadamente para que slo sea visto por el
exit node, la direccin y el puerto destino de la comunicacin.
Esta clula es procesada por los nodos intermedios y el contenido til es propagado hasta llegar en una clula
RELAY_BEGIN que llega al exit-node
El exit node obtiene la direccin y el puerto destino e intenta abrir una nueva conexin TCP con el host destino.
Pueden suceder dos cosas.
Si el exit node no puede establecer la conexin devuelve una clula RELAY_END.
Si el exit node puede establecer la conexin devuelve una clula RELAY_CONNECTED que se ir
propagando por la lista de ORs hasta llegar al OP.
Una vez que la clula RELAY_CONNECTED llega al OP, este y el exit node empaquetan el stream de
datos TCP en clulas RELAY_DATA
Si un OP quiere cerrar un stream TCP anonimizado enva una clula RELAY_END a lo largo del circuito y los
nodos van cerrando ese stream para su circuito. Cuando llega al exit node, este cierre la conexin TCP. El exit node
genera una clula RELAY_ENDED que se propaga hasta el OP.
Si el stream TCP que mantiene el exit node con el destino se cierra de forma abrupta, entonces el exit node enva a lo
largo del circuito hasta el OP una clula RELAY_TEARDOWN que indica el cierre inesperado de la conexin. Por
el camino se van cerrando los streams de circuito asociados a stream TCP.
Una vez que un OR recibe una clula RELAY, comprueba el circID de la clula y determina si tiene un circuito que
se corresponda con esta a lo largo de la conexin. Si no lo tiene, descarta la clula. Por otra parte, si el OR no es exit
node, entonces cifra o descifra la carga til del stream usando la clave kb o kf correspondiente con el OP. El OR
decide si reconoce la clula que est completamente descifrada. Si el OR reconoce la clula, la procesa. Si no, la
pasa a lo largo del circuito. Si el exit node no reconoce una clula RELAY ocurre un error y el OR enva una clula
DESTROY para cerrar el circuito.
Tor
14
Cuando una clula RELAY llega al OP, el OP descifra la carga til con kbi. Si la carga til est completamente
descifrada procesa la carga til.
Cierre y modificacin de un circuito
Destruccin o truncamiento de circuito en Tor
Un circuito es cerrado cuando ocurre
un error irrecuperable a lo largo del
circuito o cuando l OP ve que todos los
streams de un circuito estn cerrados y
el tiempo de vida del circuito ha
terminado. Para cerrar un circutio el
OR o el OP envan una clula
DESTROY que se va propagando y
cerrando los circID asociados al
circuito.
Una vez que se ha establecido un circuito y se est utilizando el OP puede decidir truncarlo (por ejemplo porque se
ha cado) y crear uno nuevo a partir de donde trunque. Se procede con los siguientes pasos:
El OP escoge el OR donde se va a truncar y el OR nuevo que se quiere usar en el path.
El OP construye una clula RELAY_TRUNCATE que llega hasta el OR a partir del cual se va a truncar.
El OR desde el que se trunca comienza un proceso de cierre de circuito enviando una clula DESTROY.
El OR desde el que se trunca lanza una clula RELAY_TRUNCATED hacia el OP.
El OP cuando le llega el RELAY_TRUNCATED enva un RELAY_EXTEND para construir el nuevo circuito.
Cuando un error irrecuperable ocurre a lo largo de la conexin de un circuito, el OR debera, si est habilitado para
ello, enviar al OP una clula RELAY_TRUNCATED; el nodo ms lejano basta con enviar una clula DESTROY
para cerrar el circuito.
Tambin se cierra el circuito por parte de los ORs cuando ha habido algn error irrecuperable a lo largo del circuito
La carga til de las clulas DESTROY o RELAY_TRUNCATED contienen slo un octeto que indican el motivo por
el que el circuito debera ser cerrado o truncado. Este motivo es propagado a lo largo de los nodos
Referencias
[1] https:/ / www. torproject. org/
[2] https:/ / gitweb. torproject. org/ tor. git/ blob/ HEAD:/ ChangeLog
[3] https:/ / www. torproject. org/ about/ sponsors.html. en
[4] https:/ / www. torproject. org/ about/ corepeople.html. en
[5] [5] Paul Syverson, "A peel of Onion", ACSAC'11. Orlando, Florida USA. Diciembre de 2011
[6] [6] Roger Dingledine et al. "Tor: The Second-Generation Onion Router"
[7] Peter Wayne,"Disappearing Cryptography: Information Hiding: Steganography & Watermarking". Third Edition. Morgan Kaufmann 2009
Tor
15
Bibliografa
Tor Protocol Specification - Roger Dingledine, Nick Mathewson
Tor:Design e Simulaziones - Carmelo Badalamenti
Anonimato in Rete - Diodato Ferraioli, Enrico Rossomando
Enlaces externos
Sitio web oficial del proyecto Tor (https:/ / www. torproject. org/ ) (en ingls)
Fuentes y contribuyentes del artculo
16
Fuentes y contribuyentes del artculo
Tor Fuente: http://es.wikipedia.org/w/index.php?oldid=74918813 Contribuyentes: Airunp, Alessus, Anicholo, Aronu, Biasoli, BlouBlou, Chrisyagami, Cobalttempest, Coffee, Death Master,
Diamondland, Eduardosalg, El Ayudante, Fercufer, Gallowolf, Ganon, GermanX, Gtz, Hugo Amador, Isha, Jgaray, Jkbw, Jorge c2010, Jynus, Kizar, La cebolla terron, Locutus Borg, Luis junco,
Marc-Andr Abrock, MataGigantes, Matdrodes, Misterio3264, Nehyx, Neotobarra, Nihilo, Novelln, Pan con queso, Ralgis, Resped, Sixstone, SuperBraulio13, Superzerocool, Technopat,
UA31, Wer?Du?!, Yosicogito, 75 ediciones annimas
Fuentes de imagen, Licencias y contribuyentes
Archivo:Tor-logo-2011-flat.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Tor-logo-2011-flat.svg Licencia: Creative Commons Attribution 3.0 Contribuyentes: Tor Project
Archivo:Yes_check.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Yes_check.svg Licencia: Public Domain Contribuyentes: SVG by (modified by )
Archivo:Funcionamiento_red_tor2.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Funcionamiento_red_tor2.svg Licencia: Creative Commons Attribution-Sharealike 3.0
Contribuyentes: User:Fercufer
Archivo:Celula tor.gif Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_tor.gif Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes: User:Fercufer
Archivo:Celula relay tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_relay_tor.png Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes:
User:Fercufer
Archivo:Crea circuito Tor.gif Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Crea_circuito_Tor.gif Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes:
User:Fercufer
Archivo:Celula create Tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_create_Tor.png Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes:
User:Fercufer
Archivo:Celula created Tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_created_Tor.png Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes:
User:Fercufer
Archivo:Celula relayextend Tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_relayextend_Tor.png Licencia: Creative Commons Attribution-Sharealike 3.0
Contribuyentes: User:Fercufer
Archivo:Celula relayextended Tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Celula_relayextended_Tor.png Licencia: Creative Commons Attribution-Sharealike 3.0
Contribuyentes: User:Fercufer
Archivo:Envio info Tor.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Envio_info_Tor.png Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes:
User:Fercufer
Archivo:Destroy truncate circuito Tor.gif Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Destroy_truncate_circuito_Tor.gif Licencia: Creative Commons Attribution-Sharealike
3.0 Contribuyentes: User:Fercufer
Licencia
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/