Publicó su web en la dark web y perdió su IP para siempre. Así lo hizo

Hay una diferencia enorme entre "estar en la dark web" y "publicar en la dark web". Lo primero lo haces por accidente. Lo segundo lo hiciste a propósito, con un archivo de configuración de cuatro líneas.

David Álvarez Rosa publicó su blog en una dirección .onion la semana pasada. El post explicó cómo lo hizo. En menos de 48 horas llevaba 241 puntos y 92 comentarios en Hacker News, y el debate sigue abierto. No es una anécdote sobre seguridad: es una decisión de arquitectura que cualquiera con un servidor barato puede replicar esta misma tarde.

Qué es un hidden service (y qué NO es)

Tor cifra tu tráfico y lo rebota por miles de relays voluntarios. Eso protege la IP de destino. Un hidden service va un paso más allá: oculta la IP del servidor.

Ahí está la diferencia técnica que casi nadie entiende:

• Sin autoridad de certificación. No hay CA, no hay TLS emitido, no hay Let's Encrypt.
• Sin DNS. No existe un registro que alguien pueda revocar o señalar.
• Sin IP expuesta. La dirección se deriva directamente de una llave pública.
• Sin puerto abierto en el router. El tráfico nunca toca tu IP pública.

El navegador estándar no entra. Necesitas el Tor Browser, que es un Firefox modificado. Pegas la dirección y funciona.

Cómo se hace (el método completo)

El autor no vendió humo. El recipe entero cabe en un bloque de configuración de nginx y tres líneas de torrc:

HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:8080

Reinicias Tor, lees el archivo hostname y te devuelve algo como dhevt6...hid.onion. Eso es todo. Tu nginx solo tiene que escuchar en 127.0.0.1:8080 y servir archivos normales.

Un detalle que casi todos pasan por alto: el directorio tiene que ser propiedad de Tor, con permisos 700. Si lo apuntas a tu web root, Tor se niega a arrancar. Es una barrera de seguridad a propósito, no un bug.

Tampoco necesitas TLS, HTTP/2 ni QUIC. Tor habla TCP plano y ya trae su propio cifrado. Meter un certificado ahí es puro ruido.

El truco que nadie menciona: compila dos veces

Un sitio estático hornea su URL base en los links absolutos. Si construyes una sola vez para el clearnet, tus visitantes de Tor caen de vuelta a tu dominio público. El autor lo resuelve construyendo el sitio dos veces:

hugo --minify --baseURL "http://dhevt6...hid.onion/"

Su pipeline de deploy hace exactamente eso: cada push construye una copia para clearnet y otra para Tor, y sincroniza cada una a su web root. A mano, es facilísimo olvidar que cambiaste una línea y se rompe todo en silencio.

Por qué esto importa más de lo que parece

El subtexto del debate en HN no era técnico, era político. Hay gente que usa los .onion como infraestructura de resistencia: periodistas, organizaciones de derechos humanos y mirrors de emergencia cuando un gobierno bloquea el acceso normal. Para un sitio como este, un .onion no es postura estética: es el punto de publicación que sobrevive.

Y ojo con la subestimación del riesgo al otro extremo. Publicar un .onion no te vuelve invisible si tu contenido es identificable. Una captura de pantalla, un tema demasiado específico, un error de servidor que menciona tu nombre, un fingerprint de navegador. La red oculta el transporte, no tu comportamiento.

El otro punto que los comentarios destrozaróon: la escala. Un hidden service no escala, y no está pensado para alto tráfico. Un sitio con mucho contenido pesado, imágenes o descargas va a arrastrar la red entera. Tor es para leer y publicar texto, no para ser tu CDN.

El ángulo que nadie pone sobre la mesa

El autor escribió esto en un servidor propio, con un dominio público al lado. La publicación dual no es un acto de rebeldía, es un acto de ingeniería. Tienes dos versiones del mismo contenido con dos perfiles de exposure distintos: una optimizada para SEO y otra que no depende de ningún registro que pueda caerse.

Para la región LATAM esto tiene una lectura directa. Cuando un dominio se bloquea por una orden judicial, cuando un CMS te manda a la quieteza por un artículo, cuando un hosting te corta el servicio por contenido que viola sus términos, el .onion es tu salida de emergencia barata. No te salva de nada legal. Sí te quita el poder de un solo botón que decide si existes o no.

¿Legal? Lee las leyes de tu país antes de tocar esto. Publicar contenido es una cosa; operar un servicio de acceso anónimo es otra.

Resumen práctico

Si quieres probarlo esta tarde:

1. Instala el Tor Browser y confirma que la red funciona.
2. En un servidor, instala Tor y define un HiddenServiceDir dedicado con permisos 700.
3. Mapea un puerto a 127.0.0.1 con tu web server.
4. Construye el sitio con la URL .onion como baseURL.
5. Compra un dominio, pide TLS normal, y deja de obsesionarte con el SSL del onion.

Media hora de trabajo para una segunda puerta de salida que nadie puede cerrar. Con miles de artículos publicados desde una PC de casa, no voy a decirte que no vale la pena.

Mi opinión

Todo el ecosistema de "privacidad" vive en el navegador: bloqueadores, VPN, Privacy Badger, extensiones de por vida. El salto real no está en la extensión, está en mover la infraestructura. Un sitio que se sirve a sí mismo desde un onion no le pide permiso a nadie para existir, y esa es la diferencia entre privacidad como configuración y privacidad como arquitectura.

Ahora hay una incomodidad que toca decir en voz alta: los hidden services siguen siendo la puerta de entrada favorita de las redes del crimen organizado. Publicar con un .onion te mete en una categoría que no elegiste. Nadie que lea tu blog va a asumir que el dueño está haciendo algo turbio. Asumirá lo peor y te demó. Es el precio de esa puerta extra, y depende enteramente de quién lea.

Con todo, el balance gana. La infraestructura abierta no significa nefasta: significa que cada persona puede montar la suya. El momento en que esto deje de sorprender es el momento exacto en que deja de ser peligroso para el otro.

Comparte esto si crees que la privacidad debería venir por defecto en el servidor y no como un botón que el usuario tiene que acordarse de pulsar. Y dinos en los comentarios: ¿túlerverías la infraestructura de tu sitio, o prefieres depender de un hosting que puede caerse cualquier martes?