Como se ha mencionado anteriormente en estas entradas, el directorio de TOR almacena información sobre nodos disponibles en la red y cada nodo puede tener el suyo propio con el fin de descentralizar aun más este servicio, dado que cada nodo tiene una copia de esta información y la cachea de forma automática en su estructura interna. La razón por la cual se utilizan estos elementos en la red de TOR ha sido principalmente porque en las primeras versiones, cada cliente tenia conocimiento de los routers que componían los circuitos entre él y sus correspondientes destinos, disponía de un listado de routers que eran confiables (algo que no siempre podría ser cierto) y conocía las claves de cada uno, sin embargo, dada la naturaleza cambiante de la red, este listado se encontraba rápidamente desactualizado, conteniendo nodos que posiblemente ya no se encontraban disponibles o que sus correspondientes claves publicas habían cambiado (un poco menos frecuente, pero también podía ocurrir), lo que obligaba al cliente a realizar una nueva lista con bastante frecuencia. Para ello en TOR se han creado los directorios Autoritativos que contienen el estado actualizado de routers confiables y sus correspondientes estados. A continuación se indican los conceptos teóricos/funcionales y las opciones de configuración.

RELACION DE ONION ROUTERS Y DIRECTORIOS EN TOR.

Un router debe “postear” un descriptor firmado con una serie de campos que le indican a los directorios autoritativos datos tales como las políticas de aceptación/rechazo de peticiones, puertos en escucha, nickname, fingerprint, direcciones IP, correo electrónico del administrador del router, entre otras cosas. Estos ficheros deben de ser verificados por cada autoridad para que posteriormente sean incluidos en el documento de consenso (en próximos párrafos se explica con mayor detalle que significa esto). Las verificaciones que lleva a cabo una autoridad son:

  1. Descriptor correctamente formado y correctamente autofirmado por el administrador del OR.

  2. Nickname único, es decir que no se encuentre asignado a otro OR en la red.

  3. Router admitido, es decir, que no se encuentra en una BlackList debido a su clave, IP o cualquier otra razón.

Si el descriptor logra pasar estas validaciones y la autoridad no tiene almacenado un descriptor para dicho router (el router ha sido registrado por primera vez) con su clave publica, procede a almacenarlo en su estructura interna de routers. Si la autoridad ya tiene un descriptor para dicho router (nickname) con la misma clave publica, el descriptor enviado es almacenado, solamente si es más reciente que el que se encuentra almacenado en la autoridad. Notar que estas validaciones solamente aplican cuando un router sube su descriptor a un directorio autoritativo, en el caso de que un directorio descargue dicho descriptor desde otro directorio autoritativo, no se llevan a cabo dichas comprobaciones.

PROTOCOLOS DE DIRECTORIO EN TOR

Actualmente existen 3 versiones del protocolo de directorio de TOR, a continuación se intentará explicar el funcionamiento de cada una:

V1: En las primeras versiones de TOR, se definió el concepto de “directorio” y “autoridades de directorio” que no eran más que repositorios “confiables” donde se podía consultar “descriptores de router” junto con otra información relacionada con cada uno de estos nodos y su estado en la red (Activo o Inactivo), de esta forma, los clientes podían consultar estos directorios y obtener información actualizada sobre estado de la red de forma automática. Posteriormente surgió el concepto de “caches de directorio” que permitían ahorrar ancho de banda y recursos, las caches de directorios consisten simplemente en nodos que descargan los directorios desde sus correspondientes autoridades y los hacen disponibles a clientes, de esta forma es común que los clientes consulten dichas caches en lugar de directorios autoritativos.

V2: En esta versión del protocolo, se tenia un conocimiento previo del uso de los directorios de cache y los directorios autoritativos y se detectaron dos problemas relacionados con ellos y que esta versión se han intentado mejorar:

  • Los directorios evidentemente crecían constantemente y muchas de las descargas que realizaban los clientes del directorio consistían principalmente en “router descriptors” que estos ya tenían.

  • Cada directorio autoritativo tenia un problema grave relacionado con la confianza que tenia sobre otros directorios autoritativos, por ejemplo si por algún motivo uno de los directorios autoritativos no era realmente confiable, los clientes que descargarán información de estos tendrían una vista arbitrariamente distorsionada y dado que los clientes confían más en los documentos recientemente descargados se convierte en una situación conflictiva y exponencial en función del número de autoridades existentes, dado que entre más autoridades existan la probabilidad de que la red sea menos segura es mucho más alta.

Para solucionar estos problemas, en esta especificación del protocolo se han implementado algunas mejoras, en primera instancia en lugar de descargar todos los descriptores de routers a la vez, los clientes solamente descargan aquellos que no tengan, de esta forma se genera un ahorro en términos de banda ancha y recursos. Por otro lado en esta versión, las autoridades publican los documentos firmados de “status de red” para cada router, conteniendo un hash de la clave de identidad, un hash de su mas reciente descriptor y un resumen sobre lo que la autoridad “creía” sobre dicho documento de estado. Luego los clientes podían descargar dichos documentos y creer en los estamentos de dichos routers si estos eran confirmados por más de la mitad de las autoridades. Por este motivo, como se verá más adelante, es necesario contactar con otros administradores de dichos directorios si se desea crear un directorio autoritativo en la red de TOR, esto significa que todos los directorios autoritativos en la red de TOR, necesitan conseguir una “certificación de confianza” por parte de los demás directorios autoritativos.

V3:

En esta versión no se realizan cambios tan drásticos como los que se aplicaron entre la V1 y V2, sin embargo se aplicaron mejoras que permitían optimizar el rendimiento de los directorios y el consumo de recursos y ancho de banda, en principio estos son los principales cambios con realización a la V3.

  • Se ha ahorrado aproximadamente un 60% de banda ancha usada al cambiar dos campos que no eran utilizados por los routers de TOR (nombrados read-history y write-history), estos dos campos han sido movidos en un documento separado del “network-status” dado que muchos de los clientes no lo buscan o utilizan.

  • Muchos de los datos sensitivos en la red (especialmente las claves de identidad del directorio de autoridad) necesitaban ser almacenadas sin cifrado, así que ahora las autoridades pueden firmar documentos “network-status” al vuelo y almacenar dichas claves de identidad “off-line” y usarlas para certificar las claves de firma.

    Como característica mas llamativa que ha surgido es el concepto de “consensus network status”. En versiones antiguas del protocolo de directorio los clientes debían hacer una correlación de múltiples documentos de estado de red (network status documents), esto cambio en esta versión, dado que ahora, todos los directorios autoritativos generan un documento único que es el resultado del consenso de todas las autoridades llamado «consensus network status document».

AUTORIDADES Y CONSENSOS:
El mecanismo de consenso consiste en primer lugar, en la sincronización y en la definición de un intervalo de tiempos que dividen las autoridades, los valores de estos intervalos suelen ser 5,15,30,60 y 90 minutos y dividen el día de 24 horas. Cada autoridad debe actuar acorde a los intervalos en el consenso más reciente. Todos los administradores de las autoridades se encargan de sincronizar sus relojes y que tengan un tiempo preciso (normalmente utilizando NTP para ello).
El número de directorios de autoridad en la red de TOR son entre 5 y 10 routers los cuales vienen incluidos en un listado que se incluye en el software de TOR, evidentemente es recomendable no cambiar dicha lista. Cada autoridad en dichos intervalos de tiempo debe enviar su “voto” que es un resumen firmado de los descriptores y el estado de los routers conocidos en la red, las autoridades computan el resultado de dicho voto y firman un documento de “consensus status” conteniendo el resultado del voto, toda la información de directorio es subida y descargada usando HTTP.

Cada documento de consenso tiene 3 marcas que determinan su validez, VA (Valid After) FU (Fresh Until) y VU (Valid Until) donde FU debe estar entre VA y VU. Cada uno de estos documentos se mantiene hasta que el siguiente consenso es finalizado, generando a su vez un nuevo documento de consenso, esto no significa que el anterior se vuelve “invalido” de hecho al menos 3 documentos de consenso se mantienen validos en cualquier momento dado (este es el valor por defecto, pero puede ser cambiado como se verá más adelante).

En el ciclo de un consenso entre autoridades se tienen en cuenta las siguientes mediciones de tiempo:

VOTESECONDS: Número de segundos durante los cuales una autoridad dada puede recolectar votos de otras autoridades. Debe ser de al menos 20 segundos.

DISTSECONDS: Número de segundos durante los cuales una autoridad dada puede recolectar las firmas de otras autoridades y votos que aun no tenga. Debe ser de al menos 20 segundos.

VA: Momento exacto en el que es generado un nuevo documento consensuado “network-status”.

VU: Momento exacto en el que un documento consensuado “network-status” deja de ser valido.

FU-VA: Diferencia entre el tiempo de Fresh Until y Valid Until, este valor debe ser de al menos 5 minutos. Este es el periodo de tiempo en el que el Consenso es el más reciente.

VU-FU: Diferencia entre el tiempo de Valid Until y Fresh Until, este valor debe ser de al menos 5 minutos. Este es el periodo de tiempo en el que el consenso deja de ser el más reciente pero aun es valido.

Con estas mediciones se puede definir en términos claros los pasos que se llevan a cabo para que las autoridades puedan generar el fichero “network-status” consensuado:

  1. VA-DISTSECONDS-VOTESECONDS: Las autoridades intercambian sus votos antes de establecer el correspondiente consenso. Para ello lo publican en http://<hostname>/tor/status-vote/next/authority.z y realizan una petición HTTP POST a cada autoridad en http://<hostname>/tor/post/vote

  2. VA-DISTSECONDS-(VOTESECONDS/2): Las autoridades ahora intentan descargar los votos que no tengan de las demás autoridades.

  3. VA-DISTSECONDS: Las autoridades calculan el consenso e intercambian firmas. Una vez una autoridad tiene el estado actual de todas las demás autoridades, este estado se hará disponible en: http://<hostname>/tor/status-vote/next/<fp&gt;.z donde <fp> es el fingerprint de la clave de identidad de la otra autoridad y también se hará disponible el digest del voto en http://<hostname>/tor/status-vote/next/d/<d&gt;.z donde <d> es el digest.

  4. VA-(DISTSECONDS/2): Las autoridades tratan de descargar cualquier firma que no tengan. Estas firmas se almacenan en http://<hostname>/tor/status-vote/next/consensus-signatures.z

  5. VA: Todas las autoridades han firmado un nuevo consenso. En este intervalo cada autoridad también necesita enviar su firma a cada autoridad en una petición post a la URL http://<hostname>/tor/post/consensus-signature

  6. VA … FU: En este intervalo de tiempo los directorios de Cache descargan los documentos de consenso con el fin de que sean disponibles a otros clientes en la red de TOR.

  7. FU: Una vez llegado a este tiempo, se asume que un nuevo consenso se encuentra disponible y que ahora, este consenso no es el más reciente, no obstante sigue siendo valido.

  8. FU … VA: En este intervalo de tiempo, los clientes descargan el consenso desde los directorios de cache.

  9. VU: Llegado a este intervalo de tiempo, el consenso ya no es valido y es removido.

Finalmente el primer intervalo de votación siempre comienza a la media noche 00:00 GMT. Una autoridad debe publicar su voto inmediatamente al inicio de cada intervalo de votación (menos tiempo voto y recolección de firmas como ya se ha indicado anteriormente).

DIRECTORIOS DE CACHE

Del mismo modo que las autoridades mantienen un documento consensuado de “network-status”, un directorio de cache, siempre debe de almacenar dichos documentos para servirlos a los clientes que lo soliciten, las caches siempre intentan descargar estos documentos de sus correspondientes autoridades para almacenarlos si algún de las siguientes premisas se cumplen:

  • La cache no tiene un documento de consenso.

  • El documento de consenso de la cache ya no es valido (la fecha y hora actuales son mayores a la marca VU del documento)

Si ninguna de estas condiciones se cumple, las caches intentan descargar un nuevo documento de consenso de forma aleatoria en un rango de tiempo determinado entre el tiempo en el cual el documento ya no es “fresco” pero aun es valido, es decir, en el periodo que se encuentra entre FU y VU. Por ejemplo, si una cache tiene un consenso que es valido a las 15:00 (VA) y esta fresco hasta las 16:00 (FU), la cache intentará buscar un nuevo consenso de las autoridades en un momento aleatorio entre las 16:00 y las 16:30 (suponiendo que el valor de VU sea 16:30).

CLIENTES TOR

Una vez se han descrito las autoridades y las caches como elementos de la red de TOR en la parte “servidora” se describe el funcionamiento de los clientes. En primer lugar, cada cliente mantiene una lista de directorios de autoridad, en la medida de lo posible todos los clientes deberían mantener la misma lista y no deberían cambiar sus valores. Los clientes siempre intentarán tener un documento “network-status” consensuado valido todo el tiempo, si este documento ya no es valido o se ha perdido por alguna razón, tratará de buscar uno reciente desde un directorio de cache (o desde una autoridad directamente si no conoce un directorio de cache). En el caso de que falle la descarga de dicho documento, espera unos pocos segundos y posteriormente intenta con otra cache, evidentemente si un cliente no tiene un documento “network-status” consensuado no podrá de ninguna manera construir ningún circuito, por lo tanto el arranque de la instancia de TOR fallará.

NOTA: La primera vez que se inicia una instancia de TOR en una maquina, el cliente no tiene conocimiento de ningún directorio de cache, por lo tanto la primera consulta por un “network-status” se ejecuta directamente contra una de las autoridades incluidas en el listado que viene incluido en el cliente (la entidad es elegida de forma aleatoria), una vez se realiza esta petición se obtiene información sobre las caches, por este motivo, los clientes no necesitaran volver a consultar las autoridades de forma directa, en lugar de ello, realizarán consultas contra los directorios de cache.(los directorios de cache a utilizar también son elegidos de forma aleatoria).

Ahora bien, cuando un documento de consenso en una cache esta a punto de expirar, los clientes deben descargar nuevos documentos validos, para evitar inundar las caches con peticiones de clientes esperando recibir este documento, los clientes eligen de forma aleatoria el momento en el que solicitarán dicho documento, que siempre será en un punto después de la marca FU y antes de la marca VU (ver los párrafos anteriores sobre la estructura de un documento “network-status” para conocer el significado de estas banderas). Este tiempo aleatorio es un calculo simple que consta de dos limites, uno inicial y uno final, donde el limite inicial es la suma de FU con ¾ en el primer intervalo entre VA y FU y el limite superior son 7/8 del tiempo restante entre el resultado del limite inicial y el valor de VU. Este calculo a lo mejor resulta un poco confuso, pero en realidad es simple, la mejor forma de demostrarlo es con un ejemplo:

Si un cliente tiene un documento de consenso que se ha vuelto valido a las 15:00 (VA) esta fresco hasta las 16:00 (FU) y expira a las 18:00 (VU), el cliente realizará una consulta , buscando un nuevo consenso entre las 14:45 (limite inicial) y 17:50 (limite final), la explicación de esto es muy sencilla:

VA = 15:00, FU = 16:00, VU = 18:00

Limite Inicial = FU + ((FU – VA)*3/4)

Limite Inicial = 16:00 + ((60 minutos)*3/4)

Limite Inicial = 16:00 + (45 minutos) <=> 16:45

Limite Final = Limite Inicial + ((Limite Inicial – VU) * 7/8)

Limite Final = 16:45 + ((16:45 – 18:00) * 7/8)

Limite Final = 16:45 + ((75 minutos) * 7/8)

Limite Final = 16:45 + (65,625) <=> 17:50

Este es un calculo que realiza de forma automática el cliente de TOR y para un hacker es importante saberlo si por alguna razón desea cambiar dicho comportamiento en el código de su instancia TOR. En el caso de que estos cálculos no hayan sido claros o generen cualquier tipo de duda, el lector podrá postear un comentario indicando cual es su duda.

Ahora bien, cuando un cliente obtiene un documento “consensus network status”, intenta tener el mejor descriptor para cada router, para determinar cual es el “mejor descriptor” se comprueba si este se encuentra listado en el documento “consensus network status” (un cliente no puede utilizar un relay que no se encuentre en este documento) Ademas ningún cliente puede construir circuitos hasta que no tenga un “consensus network status” valido y descriptores de OR para al menos ¼ de los relays que se supone que están en ejecución en la red TOR.

Finalmente, existen algunas restricciones que aplican a los clientes al momento de construir un circuito, en concreto estas son:

  • No deberán usar routers “Non-Valid” o “Non-Running” a menos que se indique explicitamente.

  • No deberán usar routers “Non-Fast” para ningún otro propósito que no sea la construcción de circuitos con banda ancha muy baja.

  • No deberán usar routers “Non-Stable” para conexiones persistentes o de larga duración (tales como las que se establecen con SSH).

  • No deberán usar routers “Non-Guard” cuando se seleccione nodos de entrada “Guard”.

  • No deberán consultar información de directorio desde caches “Non-V2Dir”.

ALGUNAS OPCIONES DE CONFIGURACIÓN

Una vez estos conceptos se han aclarado, se tiene un conocimiento mucho más profundo del funcionamiento interno de TOR, se procede a describir algunas de las opciones que pueden indicarse en el fichero de configuración de TOR (torrc) relacionadas con directorios de autoridad y directorios de cache.

DirPort: Indica que en el puerto indicado en esta opción se iniciará un servicio de directorio TOR.

DirListenAddress: Indica que en esta dirección y en este puerto se iniciará un servicio de directorio TOR.

DirPortFrontPage: Esta opción recibe como parámetro un fichero HTML que será establecido en la raíz del directorio TOR (opción DirPort > 0 o DirListenAddress) este fichero será establecido en “/” y contendrá información relacionada con el “disclaimer” del Directorio TOR.

AuthoritativeDirectory: Cuando esta opción se encuentra activada, indica a TOR que esta instancia actuará como un directorio Autoritativo en lugar de cachear un directorio en la red de TOR, este generará su propio listado de “servidores validos”. normalmente antes de hacer esto se debe contactar con otros administradores de Directorios Autoritativos escribiendo un correo a tor-ops@torproject.org de otro modo, será ignorado prácticamente por todos los clientes en la red de TOR.

V1AuthoritativeDirectory: Cuando se utiliza con la opción AuthoritativeDirectory automáticamente se generá un directorio autoritativo V1. (para clientes TOR 0.1.0.x)

V2AuthoritativeDirectory: Cuando se utiliza con la opción AuthoritativeDirectory automáticamente se generá un directorio autoritativo V2. (para clientes TOR 0.1.1.x y 0.1.2.x)

V3AuthoritativeDirectory: Cuando se utiliza con la opción AuthoritativeDirectory automáticamente se generá un directorio autoritativo V3. (para clientes TOR 0.2.0.x)

DirPolicy: Se trata de las políticas de aceptación para limitar quienes se pueden conectar a los puertos del directorio. La estructura de estas es igual a las que se han definido para la opción ExitNodes que se ha indicado en entradas anteriores.

VersioningAuthoritativeDirectory: Cuando esta opción se encuentra activada (1) indica las versiones de TOR que aun son consideradas como seguras para el uso del directorio publicado, (Esta opción debe venir acompañada con una de las opción Recommended* que se declaran a continuación).

RecommendedVersions: Se trata de un listado de cadenas separado por comas que enumera las versiones de TOR que son consideradas “seguras y estables”. Esta opción puede establecerme en múltiples ocasiones en el mismo fichero de configuración y en todos los casos, siempre debe venir acompañada con la opción VersioningAuthoritativeDirectory activada.

RecommendedClientVersions: Funciona igual que RecommendedVersions, solamente aplica para los clientes de la autoridad, su valor no es utilizado cuando se establece también la opción RecommendedVersions. Siempre debe venir acompañada con la opción VersioningAuthoritativeDirectory activada.

RecommendedServerVersions: Funciona igual que RecommendedVersions, solamente aplica para los servidores y OR, su valor no es utilizado cuando se establece también la opción RecommendedVersions. Siempre debe venir acompañada con la opción VersioningAuthoritativeDirectory activada.

Finalmente, en este post se definió en párrafos anteriores, algunas variables relacionadas con los tiempos empleados por las autoridades para enviar y recoger los votos correspondientes a los consensos. Las siguientes opciones de configuración permiten controlar estos tiempos (Evidentemente son solamente validos para autoridades de directorio y estas normalmente intentan tener los mismos valores para que no tengan conflictos, es así como realmente funciona TOR.)

V3AuthVotingInterval: Numero de minutos predefinidos para el intervalo de cada voto, Es importante anotar que el intervalo es realmente elegido de todas las autoridades que se ponen de acuerdo para ello. Por ejemplo actualmente el intervalo inicial comienza a las 00:00 y posteriormente las 24 horas del día son divididas con el valor de esta propiedad. El valor por defecto es 1 hora.

V3AuthVoteDelay: Configuración del tiempo definido en minutos entre la publicación del voto de la autoridad y la recolección de los votos de las demás autoridades, el valor de esta propiedad es equivalente a la variable VOTESECONDS indicada anteriormente, el valor por defecto es de 5 minutos.

V3AuthDistDelay: Configuración del tiempo definido en minutos de una autoridad para la publicación de su consenso y asegurarse de recolectar firmas y votos de las otras autoridades. equivalente a la variable DISTSECONDS indicada anteriormente.

V3AuthNIntervalsValid: Especifica el número de intervalos de voto para los cuales un consenso debe de ser valido, esto es equivalente al número máximo de documentos “network-status” que pueden ser validos en un periodo de tiempo determinado aunque no todos estén “frescos”, es decir, el número que se especifique en esta propiedad va a fragmentar el número de intervalos existentes entre VA (Valid After) y VU (Valid Until). El valor por defecto es de 3 y el valor mínimo debe ser 2, no se recomienda establecer un valor superior a 5 ya que se incrementa el riesgo de “particionar” la red debido a la cantidad de documentos de consenso que deben descargar caches y clientes.