How .onion Hidden Services Work: A Technical Deep Dive

Los servicios onion (conocidos comúnmente como Hidden Services) representan uno de los paradigmas más avanzados de privacidad arquitectónica en redes superpuestas. A diferencia de las conexiones convencionales de la red Tor, donde un cliente utiliza un circuito de tres nodos para alcanzar un destino en la Internet abierta mediante un nodo de salida (Exit Node), los servicios onion permiten que el tráfico permanezca íntegramente dentro de la red Tor. Esto garantiza no solo el anonimato del cliente, sino también el anonimato del servidor, eliminando de forma nativa la necesidad de exponer direcciones IP públicas, abrir puertos en cortafuegos perimetrales o depender de la infraestructura jerárquica de DNS global.

Anatomía criptográfica de una dirección .onion v3

La versión actual del protocolo, conocida como Onion v3 (desplegada para sustituir al obsoleto y vulnerable esquema v2), basa toda su seguridad en primitivas de criptografía de curva elíptica. Una dirección .onion no es un nombre de host arbitrario asignado por una autoridad centralizada, sino una representación autocertificada de una clave pública.

Una dirección típica v3 consta de 56 caracteres alfanuméricos en Base32. Su estructura binaria exacta se compone de 35 bytes:

• Clave pública del servicio: 32 bytes derivados de un par de claves asimétricas Ed25519.
• Suma de verificación (Checksum): 2 bytes calculados mediante el algoritmo de hash SHA3-256 sobre la cadena de prefijo, la clave pública y el byte de versión.
• Versión del protocolo: 1 byte con el valor constante 0x03.

El cálculo de la suma de verificación sigue formalmente esta construcción criptográfica:

checksum = SHA3-256(".onion checksum" || public_key || version)[:2]

Esta composición garantiza que sea matemáticamente imposible para un atacante suplantar la identidad de un servicio sin poseer la clave privada Ed25519 correspondiente, protegiendo las comunicaciones frente a ataques de intermediario (MitM) a nivel de resolución de nombres.

Fase 1: Configuración local y puntos de introducción

Cuando un demonio Tor inicializa un servicio onion, genera internamente su par de claves maestras Ed25519. Posteriormente, el servicio debe establecer su presencia topológica en la red sin revelar su ubicación real. Para ello, selecciona aleatoriamente un conjunto de repetidores Tor confiables (habitualmente entre 3 y 6) para que actúen como Puntos de Introducción (Introduction Points).

El servicio construye un circuito estándar anónimo de tres saltos hacia cada uno de estos repetidores seleccionados y negocia con ellos un canal de escucha mediante una celda criptográfica denominada ESTABLISH_INTRO. Durante este proceso, se genera una clave de autenticación única para cada punto de introducción. La función primaria del punto de introducción no es transferir datos de la aplicación, sino permanecer a la escucha de solicitudes de conexión provenientes de futuros clientes y retransmitirlas al servicio a través del circuito ya establecido.

Fase 2: Publicación y anonimización del descriptor en el HSDir

Para que un cliente pueda conectarse a un servicio onion, necesita conocer la lista actual de sus puntos de introducción y sus respectivas claves públicas temporales. Esta información se empaqueta en una estructura de datos firmada conocida como el Descriptor del Servicio Onion.

No obstante, publicar directamente la clave pública del servicio en los directorios distribuidos permitiría a nodos maliciosos enumerar todos los sitios .onion existentes en la red. El protocolo v3 mitiga esto mediante un sofisticado sistema de claves ciegas (blinded keys):

• Cálculo de clave derivada: El servicio utiliza su clave pública maestra A, un valor de consenso temporal (time period) y un valor pseudoaleatorio compartido para derivar una clave efímera cegada: A' = derive_blinded_key(A, ...).
• Cifrado del descriptor: El contenido interno del descriptor (que incluye las identidades de los puntos de introducción) se cifra utilizando AES-256-GCM con claves derivadas de la clave pública del servicio. Solo quien posea la dirección .onion completa puede derivar las claves de descifrado.
• Publicación en la DHT: El descriptor cifrado se sube a un subconjunto específico de repetidores que ofrecen el rol de HSDir (Hidden Service Directory), determinados dentro de una tabla hash distribuida en función del valor hash de la clave cegada.

Gracias a este esquema de derivación matemática, un operador de un nodo HSDir únicamente almacena y sirve datos criptográficos opacos. No puede deducir la dirección .onion original ni descifrar la lista de puntos de introducción.

Fase 3: El protocolo de encuentro (Rendezvous Protocol)

El establecimiento de la conexión es una operación simétrica y coordinada en la que ambas partes preservan el anonimato de sus saltos de enrutamiento mediante un Punto de Encuentro (Rendezvous Point).

Selección del Punto de Encuentro por el cliente

El cliente descarga el descriptor del servicio desde la DHT utilizando la dirección .onion provista y lo descifra. A continuación, el cliente elige un nodo Tor cualquiera al azar para que actúe como su Rendezvous Point (RP). Construye un circuito anónimo de tres saltos hacia este RP y envía una celda ESTABLISH_RENDEZVOUS, la cual incluye un identificador único aleatorio y de un solo uso denominado Rendezvous Cookie (de 20 bytes).

La celda INTRODUCE

Con el circuito hacia el RP en espera, el cliente construye otro circuito de tres saltos hacia uno de los puntos de introducción declarados en el descriptor del servicio. A través de este circuito, envía una celda cifrada INTRODUCE1. Esta celda se cifra en capas:

1. El punto de introducción recibe la celda, valida la clave de autorización y extrae una carga útil cifrada que no puede descifrar.
2. El punto de introducción reenvía esta carga útil al servicio onion mediante el circuito preestablecido en la Fase 1, utilizando una celda INTRODUCE2.
3. El servicio descifra el contenido, revelando la identidad del nodo de encuentro elegido por el cliente, la Rendezvous Cookie y la mitad de un intercambio de claves Diffie-Hellman efímero basado en Curve25519.

Cierre del circuito en el Rendezvous Point

El servicio onion construye ahora su propio circuito independiente de tres saltos hacia el Rendezvous Point indicado por el cliente. Al llegar al RP, el servicio entrega una celda RENDEZVOUS1 que contiene la Rendezvous Cookie original y la segunda mitad del intercambio Diffie-Hellman efímero.

Cliente  ---(3 saltos)---> [ Rendezvous Point ] <---(3 saltos)---  Servicio Onion
                                   |
         Tráfico E2EE pasa a través del empalme de circuitos

El Rendezvous Point empareja las dos conexiones basándose exclusivamente en la coincidencia exacta de la cookie de 20 bytes. Una vez validada, el RP envía una celda RENDEZVOUS2 al cliente confirmando el enlace y une ambos circuitos a nivel de transporte (puenteando celdas de retransmisión sin descifrar el tráfico).

Cifrado de extremo a extremo y aislamiento topológico

El circuito final resultante consta exactamente de seis saltos:

• Tres saltos controlados por el cliente (Guardia de entrada, Nodo intermedio, Punto de encuentro).
• Tres saltos controlados por el servicio (Punto de encuentro, Nodo intermedio, Guardia de entrada del servicio).

A través de este conducto unificado de seis nodos, cliente y servidor derivan claves de sesión compartidas a partir del intercambio de claves criptográficas completado en el proceso de encuentro. El tráfico entre el cliente y el servidor viaja protegido por múltiples capas de cifrado de celda de Tor, más una capa adicional de cifrado simétrico de extremo a extremo que se negocia directamente entre el cliente y la aplicación onion. Ni siquiera el Rendezvous Point intermedio tiene visibilidad criptográfica sobre las celdas de datos de aplicación intercambiadas.

Adicionalmente, este diseño otorga propiedades defensivas inherentes: el servicio no requiere exponer puertos a la WAN ni configurar redirección de puertos (NAT traversal), eliminando vectores de ataque tradicionales como escaneos de puertos remotos o explotación de vulnerabilidades en la pila TCP/IP del sistema operativo subyacente.

Implicaciones defensivas y casos de uso en seguridad

Lejos del sensacionalismo habitual, los servicios onion constituyen una pieza de infraestructura crítica para la seguridad defensiva y los derechos civiles:

• Sistemas de denuncia segura (Whistleblowing): Plataformas como SecureDrop se basan completamente en la arquitectura onion para asegurar que fuentes periodísticas puedan transferir documentos clasificados sin dejar trazas de direcciones IP en logs perimetrales ni exponer la ubicación física de las salas de redacción.
• Comunicaciones operacionales para periodistas e investigadores: Permite hospedar herramientas de colaboración y mensajería en zonas bajo estricta vigilancia estatal o censura activa, anulando el bloqueo basado en inspección profunda de paquetes (DPI) sobre nombres de dominio DNS o prefijos BGP.
• Protección contra el análisis de metadatos: Al suprimir por completo los nodos de salida convencionales de Tor (los cuales pueden ser objeto de monitorización por parte de adversarios a nivel de sistema autónomo), se erradica la posibilidad de que un operador hostil intercepte tráfico no cifrado o correlacione flujos salientes.

Conclusión

Los servicios onion v3 son una lección magistral de ingeniería de privacidad y arquitectura de confianza cero. Mediante la sinergia de primitivas criptográficas robustas (Ed25519, Curve25519, SHA3-256), directorios distribuidos con claves cegadas y un protocolo de encuentro simétrico desacoplado, logran un entorno de comunicaciones verdaderamente resiliente. Al eliminar la dependencia de intermediarios centralizados y desacoplar la identidad criptográfica de la localización de red, los servicios onion consolidan una de las defensas más sólidas disponibles en la actualidad contra la censura sistemática y la vigilancia masiva del tráfico global.