Cómo alojar un sitio .onion: servicios onion, direcciones v3 y las fugas que te delatan

Qué es en realidad un servicio onion

Un servicio onion es un servidor que nunca le dice a nadie dónde está. En vez de publicar una dirección en el DNS y esperar conexiones, construye circuitos de salida a través de la red Tor hacia un puñado de repetidores que elige como puntos de introducción, y publica un descriptor firmado que dice «quien tenga esta clave puede contactarse a través de estos repetidores». Un cliente que conoce la dirección obtiene ese descriptor, elige un tercer repetidor como punto de encuentro, y le pide a un punto de introducción que le pase la solicitud de encontrarse ahí. Ambos lados construyen su propio circuito hasta el punto de encuentro, y ninguno de los dos llega a conocer la dirección IP del otro, porque nunca se le dice a ninguno.

La dirección en sí es la parte interesante. Una dirección onion v3 son 56 caracteres en base32 seguidos de .onion, y no es un nombre que apunta a una clave: es la clave: una clave pública ed25519, una suma de verificación y un byte de versión, codificados. No hay nada que buscar ni nada que confiar a ciegas. Cuando tu cliente se conecta, el descriptor que obtiene está firmado con esa misma clave, así que la dirección autentica el servicio por construcción. No interviene ninguna autoridad de certificación, nadie puede emitir un certificado para tu dirección, y no existe ningún registro de transparencia que deje constancia de que el servicio existe. Vale la pena leer la especificación del rendezvous si quieres el protocolo completo.

Esa lista es toda la propuesta de valor, y explica la mezcla de gente que los usa. Las instancias de SecureDrop en las redacciones son servicios onion porque una fuente no debería tener que confiar en el DNS. Debian espeja su archivo mediante servicios onion para que actualizar un paquete no sea visible como destino. Varias plataformas de consumo muy grandes publican uno para que la gente en redes censuradas pueda llegar a ellas sin una IP bloqueada de por medio. Nada de esto es exótico; es un transporte con otro conjunto de garantías.

Qué protege, y la parte que no puede proteger

La garantía del protocolo es estrecha y sólida: la capa de red no revela dónde corre el servicio. Un adversario capaz de observar buena parte de internet sigue sin poder resolver tu dirección a una máquina, porque no hay ningún paso de resolución que observar. A un proveedor de hosting no se le puede entregar la dirección y preguntarle a qué cliente pertenece, porque de su lado nadie lo sabe. Los escáneres no pueden encontrar el servicio, porque no responde en ningún puerto público. Y un ataque que tumbaría de la red a un sitio normal no tiene dónde apuntar, por eso el tema aparece tanto en las conversaciones sobre protección DDoS como en las de privacidad.

Todo lo que está por encima de la capa de red sigue siendo cosa tuya, y ahí es donde vive la historia real. Se han localizado servicios porque la aplicación imprimió un stack trace con un hostname real, porque el mismo servidor web respondía en la IP pública con una página idéntica, porque en la misma máquina había instalado un certificado de otro dominio del operador, porque una imagen llevaba coordenadas GPS en sus metadatos, porque la máquina mandó correo que atravesó internet abierto, o porque un endpoint de estado dejado abierto al mundo listaba la propia dirección del servidor. Tor cumplió su parte en cada uno de esos casos. La persona que iba encima, no.

Así que quédate con dos ideas a la vez. El transporte es sólido y lleva años siéndolo; tratarlo como el eslabón débil es una lectura equivocada de cómo han ido en realidad estas investigaciones. Y el transporte es también la mitad fácil: la mitad difícil es la disciplina sobre todo lo que la máquina dice y hace, que es de lo que trata casi toda esta guía. Si estás aquí por una pregunta más amplia sobre cuán rastreable es un servidor alquilado, la versión honesta de esa respuesta es un buen complemento a esta página.

Levantar uno: dos directivas y un reinicio

La configuración es realmente pequeña, lo que sorprende a quien espera algo ceremonioso. Instala el demonio tor, y luego añade dos directivas a torrc: un HiddenServiceDir que nombra un directorio que Tor va a crear y poseer, y un HiddenServicePort que mapea el puerto virtual que usarán quienes se conecten a la dirección local en la que escucha tu aplicación. Reinicia, y Tor genera un par de claves ed25519 y escribe tu dirección en un archivo hostname dentro de ese directorio.

El error más común, con diferencia, está en la tercera fila. Una instalación por defecto de un servidor web escucha en 0.0.0.0, es decir, la dirección IPv4 pública y casi siempre también la IPv6. Si le pones delante un servicio onion, ahora sirves los mismos bytes en dos sitios, y uno de ellos está indexado por todos los escáneres de internet. Cualquiera que compare un hash de página, un favicon, un ETag o una página de error característica los enlaza en segundos. Enlaza a 127.0.0.1, y luego confírmalo con ss -ltnp en lugar de suponerlo — confirmarlo cuesta cinco segundos, y suponerlo le ha costado todo a más de uno.

Antes de seguir, haz una copia de hs_ed25519_secret_key en un sitio cifrado y fuera de la máquina. Ese archivo no está asociado a la dirección; es la dirección. Si lo pierdes, la dirección desaparece para siempre, sin recuperación posible y sin apelación. Si se filtra, cualquiera puede montar un servicio que responda por tu dirección y sea criptográficamente indistinguible de ti. Trátalo como la clave de firma que es — y si el disco donde vive es uno alquilado, cifrar ese disco es el paso complementario obvio, con las salvedades que explica esa guía.

Después, cierra la puerta de entrada. Un servicio onion no necesita ningún puerto de entrada: todas las conexiones que usa las abre él mismo, hacia fuera, hacia la red Tor. Puedes descartar todo el tráfico entrante en el firewall y el servicio sigue funcionando perfectamente. Casi ninguna otra cosa que puedas alojar te ofrece eso, y elimina de un plumazo toda la categoría de ataques que empiezan con un escaneo de puertos. Accede también a tu propia gestión a través de Tor, y la máquina sencillamente deja de responder a internet.

Direcciones v3, prefijos vanidosos y el problema de phishing que crean

Si un tutorial que estás leyendo menciona direcciones de 16 caracteres, está describiendo un protocolo que ya no existe. Los servicios onion versión 2 usaban hashes RSA-1024 de 80 bits, lo bastante cortos para resultar atractivos y lo bastante débiles para ser un problema; además eran enumerables, porque cualquiera que operara un repetidor de directorio podía recolectar las direcciones que pasaban por él. El Tor Project anunció el calendario de retirada en 2020, desactivó v2 en la serie 0.4.6 en julio de 2021, y eliminó el código por completo ese octubre. Las direcciones v3 tienen 56 caracteres, se construyen sobre ed25519, y ya no se filtran a través de los repetidores de directorio.

La longitud es el precio de eso, y por eso existen las direcciones vanidosas. Herramientas como mkp224o generan pares de claves a granel y se quedan con los que tienen una dirección que empieza por el prefijo elegido. Esto no debilita nada: no estás restringiendo la clave, estás descartando candidatas hasta que una acaba codificando las letras que querías, y la superviviente es exactamente tan fuerte como cualquier otra. Lo que cuesta es tiempo, y el coste es exponencial: cada carácter adicional multiplica el trabajo por 32, así que un prefijo de cuatro caracteres es instantáneo en un portátil, seis o siete son horas de una máquina trabajando, y diez ya es una empresa seria. Nadie fuerza por fuerza bruta una dirección completa de 56 caracteres; el espacio de búsqueda es precisamente el punto.

El verdadero peligro es la otra cara de esa misma ventaja. Si un prefijo reconocible ayuda a tus usuarios a identificarte, también le facilita a otra persona generar uno casi idéntico y ponerlo en una página de phishing, porque los ocho caracteres que un humano realmente lee son lo único que comprueba. Defiéndelo como siempre se han defendido las huellas de clave: publica la dirección completa en varios sitios independientes, fírmala con una clave que la gente ya tenga, ponla en la cabecera Onion-Location de tu sitio en la clearnet si tienes uno, y deja claro que nunca vas a anunciar una dirección nueva solo en redes sociales. Un prefijo vanidoso es una mejora de usabilidad, no de autenticación.

La superficie de fuga que de verdad ha desenmascarado servicios

Esta es la sección que importa. El patrón en todos los casos documentados públicamente es el mismo: la capa de red aguantó, y algo por encima de ella apuntó a una máquina concreta, a una persona concreta o a otra propiedad concreta. La mayoría de estos fallos son aburridos, todos se pueden comprobar en una tarde, y el trabajo consiste precisamente en comprobarlos.

Dos de esos fallos merecen mención aparte porque atrapan hasta a la gente cuidadosa. El primero es el tráfico saliente: una máquina que nunca acepta una conexión igual puede delatarse haciendo una. Las actualizaciones de paquetes están bien y son inevitables; un agente de monitorización que informa a un panel asociado a tu nombre no lo está, y tampoco lo está una aplicación que manda correo de restablecimiento de contraseña por internet abierto desde una máquina cuyo único propósito es no ser localizada. El segundo es la clave de host SSH. Reutilizar una entre varias máquinas es una costumbre que parece prolija y crea un vínculo criptográfico permanente y buscable entre dos servidores que se suponía que no tenían nada que ver.

Haz la auditoría como si fueras alguien de fuera, no el operador. Abre el servicio en Tor Browser en una máquina que nunca haya tocado el proyecto, lee todas las cabeceras de respuesta, provoca un error a propósito, mira el código fuente de una página que tú mismo no escribiste, y vigila el panel de red por si la página pide algo de algún otro sitio. Después siéntate delante del servidor y observa qué sale de él durante un día entero. Lo que encuentres ese día es todo el sentido de esta guía.

Autorización de cliente: un servicio al que solo puede llegar cierta gente

Hay un modo que la mayoría de la gente ni sabe que existe, y es lo más elegante del protocolo. Con la autorización de cliente, el descriptor que publica tu servicio se cifra para un conjunto de claves públicas x25519 que tú designas. Un cliente sin la clave privada correspondiente ni siquiera puede descifrar el descriptor, lo que significa que no puede conocer los puntos de introducción, lo que significa que no puede conectarse — y ni siquiera puede confirmar que ahí haya algo. Colocas las claves públicas de cada cliente en un directorio authorized_clients junto a las claves del servicio, un archivo por cliente, y reinicias.

Compara eso con las formas habituales de restringir el acceso. Una lista blanca de IPs exige saber dónde están tus usuarios y deja el servicio respondiendo en internet para que cualquier otro lo escanee y le tome la huella. La autenticación básica HTTP deja ahí un prompt de login anunciando que algo existe. Una VPN añade todo un segundo sistema que mantener, con su propia dirección que exponer. La autorización de cliente saca el servicio de la vista de todo el que no esté en la lista, que es una propiedad de otra categoría por completo: no es una puerta cerrada, es la ausencia de puerta.

El encaje natural son las superficies administrativas. Pon el sitio público en un servicio onion normal, y el panel de administración, el dashboard de métricas, la consola de base de datos y el punto de entrada SSH detrás de servicios autorizados aparte, y las partes de tu despliegue que de otro modo se sondearían continuamente sencillamente no se pueden encontrar. El coste es la distribución de claves — cada cliente necesita tener su clave privada instalada en su configuración de Tor — lo cual está bien para un puñado de operadores y es poco práctico para una audiencia pública. Úsala donde la audiencia se pueda contar con los dedos.

Latencia, redundancia y las contrapartidas honestas

Una conexión onion cruza seis repetidores: tres que elige el cliente y tres que elige el servicio, encontrándose en el medio. Ese es el precio de que ninguno de los dos extremos conozca al otro, y se nota en la latencia, no en el ancho de banda — el primer byte es lento, pero el rendimiento después suele ser bueno. Diseña pensando en eso: menos idas y vueltas, caché agresiva, nada de cadenas de peticiones charlatanas, ninguna página que necesite once subrecursos antes de renderizar. Un sitio agradable sobre un servicio onion suele ser, de entrada, un sitio bien construido.

Si tu servicio no necesita anonimato de ubicación en sí mismo — por ejemplo, una gran plataforma pública que publica una dirección onion solo para que los usuarios censurados puedan llegar a ella — Tor ofrece un modo de single onion service que usa una ruta de un solo salto en el lado del servicio. Reduce la latencia más o menos a la mitad y renuncia explícitamente al propio anonimato del servicio, y el nombre de la directiva de configuración lo dice sin rodeos. Es la respuesta correcta para una organización conocida, y exactamente la respuesta equivocada para cualquiera cuya ubicación sea precisamente lo que se quiere proteger. Elígelo a propósito, o no lo elijas.

La redundancia merece una nota aparte porque el enfoque ingenuo falla. No puedes simplemente copiar el material de la clave a una segunda máquina y correr las dos a la vez — dos servicios publicando descriptores para la misma dirección se pelean por el directorio y los clientes acaban en uno u otro de forma impredecible. OnionBalance existe exactamente para esto: una instancia frontend mantiene la dirección pública y publica un descriptor que apunta a los puntos de introducción de varios servicios backend, cada uno con su propia clave. Los backends se pueden reconstruir o mover de uno en uno sin que la dirección cambie nunca.

Correr uno junto a un sitio normal

Muchos servicios onion son una segunda puerta de entrada a algo que ya existe públicamente, y eso es un proyecto distinto al de un servicio cuya ubicación es secreta. Decide cuál de los dos estás construyendo antes de escribir ninguna configuración, porque quieren cosas opuestas. Si el objetivo es resistir la censura para un sitio que todo el mundo ya sabe que llevas tú, enlazar ambos es precisamente la gracia: publica una cabecera Onion-Location en el sitio de clearnet y Tor Browser ofrecerá la dirección onion a los visitantes de forma automática. Si el objetivo es que nadie sepa dónde corre el servicio, entonces cada enlace entre ambos es una fuga, y el número correcto de enlaces es cero.

Lo que de verdad hace daño es la media medida. Correr ambos desde una sola máquina, con una sola base de datos, un solo dominio de cookie de sesión y un solo conjunto de archivos subidos, mientras te dices a ti mismo que las dos audiencias están separadas, significa que un solo error de configuración derrumba la distinción — y no te enterarás hasta que se entere otro. Si ambos deben existir y no deben estar enlazados, son dos despliegues en dos máquinas con dos juegos de credenciales, y el coste operativo de eso es el precio de la propiedad que querías.

Un detalle práctico si decides enlazarlos: mantén las sesiones y las cookies acotadas por host. Un usuario que inicia sesión en el sitio de clearnet y luego llega por la dirección onion debería tener una sesión nueva, no una compartida, o habrás construido un mecanismo que correlaciona las dos visitas para cualquiera que pueda ver una de las dos. Y sirve a la dirección onion sus propios enlaces canónicos, para que el sitio no redirija «amablemente» a un usuario de Tor Browser de vuelta al host de clearnet que precisamente estaba evitando.

Lo que el hosting tiene que hacer bien de verdad

Los requisitos son poco habituales, por eso un hosting genérico suele encajar mal. Necesitas una ruta de salida sin trabas hacia la red Tor, porque es el único tipo de conexión que hace tu servicio; algunos proveedores filtran directamente el tráfico de directorio y de repetidores de Tor, y te enterarás de eso al ver un servicio que nunca publica un descriptor. Necesitas un proveedor cuya política de uso aceptable aborde Tor por escrito, no por silencio, porque el silencio es lo que se convierte en un correo de cancelación la primera vez que alguien se queja de algo que no tiene nada que ver. No necesitas una IP estable, un dominio, un certificado, ni ningún puerto de entrada — lo que significa que la mayoría de lo que las empresas de hosting venden como diferenciador aquí es irrelevante.

El perfil de abuso es la sorpresa agradable. Un nodo de salida hace conexiones a internet abierto en nombre de desconocidos y por eso recibe quejas; ese es el trato, y por eso los nodos de salida necesitan un proveedor con una postura documentada. Un servicio onion hace lo contrario: todas sus conexiones son entrantes desde la red Tor, nunca contacta con internet abierto en nombre de nadie, y en consecuencia genera prácticamente ningún correo de abuso. Es una carga de trabajo mucho más tranquila de alojar que el repetidor de al lado, y muchísimo más tranquila que un servidor web público.

En BitVPS, Tor está permitido por escrito — repetidores, puentes, salidas y servicios onion por igual, con el caso de las salidas documentado en la página de abuso en lugar de dejarlo al azar. La página de hosting para Tor cubre el dimensionamiento de repetidores; los servicios onion son más ligeros. En la práctica, un Growth a $13.50 con 4 vCPU, 8 GB de RAM y un uplink sin medición corre un servicio onion serio con margen de sobra para la aplicación detrás, y un Starter a $8.50 basta para uno pequeño. Elige la ubicación por su postura legal, no por la latencia: seis saltos hacen que la diferencia entre un datacenter cercano y uno lejano sea casi invisible.

La página de red publica el ASN y el peering, lo cual aquí importa por una razón indirecta. No estás exponiendo ninguna dirección, así que la razón habitual para preocuparte por la red de un proveedor desaparece — pero un hosting que documenta su infraestructura públicamente es también un hosting que ha dejado por escrito qué hace cuando alguien pregunta por un cliente, y eso es lo que en realidad estás comprando.

Dónde está el límite

Vale la pena ser directo con esto, porque la tecnología carga con una reputación que no se corresponde con el tráfico real. Los servicios onion son un transporte con una propiedad de privacidad concreta, y quienes los llevan son, en su inmensa mayoría, gente corriente: redacciones recibiendo filtraciones, un archivo de paquetes que no quiere registrar qué máquina descargó qué actualización, proyectos de mensajería y autoalojamiento, personas en países donde el internet normal está filtrado, y administradores a quienes simplemente les gustaría que su interfaz de gestión no fuera escaneable. Llevar uno es legal en la inmensa mayoría de las jurisdicciones, y no dice nada sobre qué estás alojando.

Lo que no hace es cambiar cuáles son las reglas. Un proveedor que ignora los avisos de derechos de autor — y nosotros lo hacemos, como explica esa guía — sigue actuando ante material de abuso sexual infantil y amenazas creíbles contra personas, y actúa rápido: nuestra ventana publicada es de cuatro horas para eso, frente a cuarenta y ocho para todo lo demás. Eso no es un resquicio en una política por lo demás permisiva, es la política, y ningún transporte la cambia. La política de uso aceptable es corta y vale la pena leerla antes de construir, no después.

La otra nota honesta es que el anonimato es una propiedad de sistema, no un producto que se compra. La dirección esconde la máquina; no esconde un rastro de pagos, una contraseña reutilizada, un estilo de escritura, un dominio que registraste hace años con el mismo correo, o una captura de pantalla con tus propias rutas de sistema de archivos. Si el modelo de amenaza es serio, el transporte es la parte más fácil y en la que menos tiempo vas a invertir. La guía más amplia cubre el resto de esa cadena, y la explicación sobre bulletproof hosting es un buen antídoto contra el marketing que rodea todo este tema.