Anexo 18: Tor

Servicio de directorio

El servicio de directorio publica una base de datos que asocia a cada OR una serie de información (router descriptor). Esta información 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 información pasándosela 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 suscripción a la red (bootstrapping). Los servidores de directorio son en realidad un grupo establecido de ORs confiables. Para dar fiabilidad a la información que da el servicio de directorio las entradas son protegidas criptográficamente con firmas y sólo la información 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 añade muchos nodos no confiables. No hay sistema automático para aprobar OR's; Los administradores del servidor de directorio lo hace manualmente.

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 dirección IP, nombre amigable para el usuario, versión del software TOR, sistema operativo, clave pública, 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 número de puertos a los cuales está dispuesto llevar el tráfico). Observar que usando esto se puede hacer que un nodo no pueda actuar como último nodo de un circuito nunca). Toda esta información se publica a través del servicio de directorio.

Puntos de encuentro

La idea de los puntos de encuentro, denominados por las siglas RP (del inglés Rendezvous Points), es, en lugar de explícitamente enviar un paquete a un destino, establecer un punto de encuentro que actúe como nivel de indirección. De esta forma desacoplamos el acto de enviar del acto de recibir. Cada extremo de la comunicación envía sus mensajes a ese punto de encuentro y desde ahí son enviados a donde corresponda usando circuitos que esconden la localización del destino. Por ejemplo podríamos usar este sistema para conectarnos a un servidor de chat IRC.

Servicios ocultos

Los servicios que ocultan la localización (por ejemplo, la dirección IP) de quien provee el servicio (Ej. un servicio web accesible sólo desde la red de encaminamiento de cebolla) se les suele llamar servicios de localización oculta (en inglés location-hidden services) o simplemente servicios ocultos (en inglés hidden services).

Para soportar esta funcionalidad los proveedores de servicios generan una clave pública y privada para identificar su servicio. A continuación anuncian su servicio a distintos routers, haciendo peticiones firmadas con su clave pública, para que sirvan como punto de contacto. A los routers con esta función se les llama puntos de introducción, en inglés 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 función hash sobre la clave pública del servicio. Cuando un cliente se quiere conectar a cierta FQDN (por ejemplo ha encontrado la dirección a través de un sitio web) consulta un servicio de búsqueda (lookup service) y este le indica un punto de introducción (introduction point) y la clave pública del servicio. Observar que para mantener el anonimato es necesario que la consulta del servicio de búsqueda se realice a través de Tor. A continuación el cliente se conecta con un punto de encuentro (esto lo podría haber hecho antes) y se establece un identificador de esa conexión (rendezvous cookie). A continuación el cliente le envía un mensaje, firmado con la clave pública del servidor, al punto de introducción indicándole 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 continuación el punto de introducción envía 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 continuación el punto de encuentro conecta a el cliente y el servidor y se establece una comunicación normal.

Células

Una vez que se establece la conexión TLS, ya sea OP-OR o OR-OR, las entidades se envían paquetes de información estructurada llamadas células. Estas células tienen tamaño fijo de 512 bytes y pueden ser enviadas en registros TLS de cualquier tamaño o dividido en varios registros. Los registros de TLS no tienen que revelar ninguna información sobre el tipo o el contenido de las células que contiene. Varios circuitos pueden ser multiplexado sobre una misma conexión TLS. Las células están formadas por una cabecera y una carga útil.

Formato:

• CircID: Es el identificador de circuito y especifica el circuito a el que se refiere la célula
• CMD: Indica el comando que especifica el significado de la célula. Atendiendo al tipo de comando (valor de CMD) hay 2 tipos de células: Células de control y Células de transmisión.

CircID (2 bytes)

CMD (1 byte)

PAYLOAD (509 bytes)

Células de control

Las células de control (en inglés control cell) son siempre interpretadas por el nodo que las recibe y permiten controlar la comunicación.

Comandos que tienen estas células:

• PADDING (código 0). Actualmente no usadas porque los ataques existentes funcionan incluso con tráfico de relleno y porque el tráfico que provocan incrementa el ancho de banda necesario. Además de éstas las celdas del tipo RELAY_DROP puede crearse también para crear también tráfico de relleno.
• CREATE (código 1). Para crear circuito.
• CREATED (código 2). ACK de CREATE.
• DESTROY (código 4). Destruir circuito.
• CREATE_FAST (código 5). Crear un circuito reaprovechando operaciones de clave pública existentes).
• CREATED_FAST (código 6). ACK de CREATE_FAST.
• VERSIONS (código 7). Usado cuando se establecen las conexiones).
• NETINFO (Código 8). Usado cuando se establecen las conexiones).
• RELAY_EARLY (código 9).

Células de transmisión

Las células de transmisión (en inglés relay cell) son usadas para la comunicación 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 tráfico de salida desde nodos OR que no son los últimos del circuito. Esto permite frustar ataques que se basan en la observación del tráfico de salida del exit node.

Este tipo de células se distinguen porque el valor del campo CMD siempre tiene el comando RELAY (código 3). En este tipo de células el formato tiene campos que forman parte de la carga útil (PAYLOAD):

• 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 (código 1). De tipo forward.
  • RELAY_DATA (código 2). De tipo forward o backward.
  • RELAY_END (código 3). De tipo forward o backward. Permite indicar el cierre de un stream TCP e indica el motivo.
  • RELAY_CONNECTED (código 4). De tipo backward.
  • RELAY_SENDME (código 5). De tipo forward o backward. A veces se usa para funciones de control (streamID=0).
  • RELAY_EXTEND (código 6). De tipo forward. Se usa para funciones de control (como veremos streamID=0).
  • RELAY_EXTENDED (código 7). De tipo backward. Se usa para funciones de control (streamID=0).
  • RELAY_TRUNCATE (código 8). De tipo forward. Se usa para funciones de control (streamID=0).
  • RELAY_TRUNCATED (código 9). De tipo backward. Se usa para funciones de control (streamID=0).
  • RELAY_DROP (código 10). De tipo forward o backward. Se usa para funciones de control (streamID=0).
  • RELAY_RESOLVE (código 11). De tipo forward.
  • RELAY_RESOLVED (código 12). De tipo backward.
  • RELAY_BEGIN_DIR (código 13). De tipo forward.
  • Los códigos 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 múltiples streams del circuito. Es seleccionado por el OP y permite a el OP y al exit nodo distinguir entre múltiples streams en un circuito. Las células 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 células relay que han sido enviados a este nodo del circuito o originados desde este nodo del circuito (sólo conocidos por el origen y el destino ya que van cifrados), usando las semillas Df o Db respectivamente (sólo conocidas por el origen y el destino), e incluyendo la carga útil entera de esta célula RELAY cogiendo el campo digest a zero. Por la visibilidad de los datos un nodo intermedio nunca podría calcular este valor de digest. Se ha estimado con 4 bytes de digest la posibilidad de que un adversario adivine por casualidad un hash válido es suficientemente baja. Es claro que cada nodo necesita mantener el SHA-1 de los datos recibidos y enviados para poder ir calculando este digest.
• Length: Indica el número de bytes del campo DATA que contiene carga útil real. El resto del campo irá rellenado por bytes a NULL.

Una célula 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 función 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 célula se ha comprobado que está completamente descifrada pero el comando de la célula no se entiende la célula será borrada e ignorada pero su contenido todavía cuenta respecto a los digests. Observar que el campo Recognized permite, de una forma muy rápida, descartar ciertas células 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 pública/privada:

• Una clave larga de identidad (en inglés Identity Key) que sirve sólo para firmar información (Ej: descriptor de las capacidades del OR o info de directorio cuando actúa como servidor de directorio) y certificados, y e usado para permitir identificación. Para denotar la clave de identidad de el nodo OR n usamos PKORn_ID.
• Una clave mediana de enrutamiento de cebolla (en inglés Onion Key) que sirve para cifrar las peticiones de establecimiento de circuito (CREATE) para negociar las claves efímeras. Las claves viejas deben ser aceptadas durante al menos una semana después 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 pequeña de conexión (en inglés Connection Key) usada en el handshake TLS. Esta clave se mete en un certificado que se firma con la clave de identificación. Ambos certificados (certificado de la clave de conexión y certificado de la clave de identificación) se envían en el handshake del TLS. El certificado de la clave identificación está firmado por la clave de identificación. El certificado de la clave de identificación está autofirmado. Esta clave debería cambiarse frecuentemente, al menos una vez al día.

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 deberían 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 simétrico de cifrado se usa AES en counter mode (AES-CTR) con claves de 128 bits, con vector de inicialización con todos los bytes a 0.
• Como algoritmo de clave pública usa RSA con claves de 1024 bytes y exponente fijo 65537. Usa como esquema de relleno OAEP-MGF1 con SHA-1 usado como función resumen.
• Como función 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