Seré honesto: la primera vez que escuché «dark web» pensé en mercados negros, bitcoin y series de Netflix. Nada más lejos de la realidad técnica. La «dark web» en sentido estricto es solo la parte de internet que no aparece en buscadores, y gran parte son sitios que alguien levantó en su propio servidor como servicio oculto de Tor. Sin cripto, sin delitos, solo TCP/IP bien configurado.
Qué es realmente un servicio onion
Tor enruta tu tráfico a través de miles de servidores voluntarios, cifrando en cada salto, para que nadie pueda unir tu identidad con lo que haces. Un servicio oculto (hidden service) extiende ese anonimato al servidor: tu VPS expone una dirección .onion que solo resuelve dentro de la red Tor, sin revelar su IP real, sin DNS, sin certificado SSL. La privacidad no es del visitante únicamente, también es del servidor.
Esta semana un administrador de sistemas publicó su blog personal como servicio onion y lo documentó paso a paso. No es complicado: dos líneas en /etc/tor/torrc apuntando al puerto local donde ya escucha tu web server, un reinicio de Tor, y listo. El sistema genera la dirección .onion automáticamente, un string largo y aleatorio que se lee como un criptograma.
Los detalles que nadie cuenta
Lo interesante no es el HOWTO, sino los detalles de implementación que descubres al armarlo:
Olvida el HTTPS. Tor ya cifra todo el trayecto, así que el nginx que recibe la conexión solo necesita escuchar HTTP plano en loopback. No TLS, no HTTP/2, no QUIC. Es raro ver un server block sin ssl_certificate, pero es lo correcto en este contexto.
Cuidado con el baseURL del generador de sitio estático. Si usas Hugo, Jekyll o cualquiera de esos generadores, el build de clearnet deja enlaces absolutos apuntando a tu dominio normal. Si sirve eso por Tor, el visitante termina siendo redirigido a la web normal y se pierde todo el punto del onion. La solución es compilar una segunda versión del sitio con la dirección .onion como baseURL y desplegarla en un directorio separado.
Dos builds, dos directorios, un solo repo. El pipeline de despliegue corre dos builds por cada push: uno para clearnet, otro para Tor. Los mantiene en sincronía automáticamente, sin trabajo manual.
Mi experiencia real
Lo probé en una VPS que ya tenía andando. Instalé Tor, dos líneas en torrc, un server block extra en nginx apuntando a 127.0.0.1:8080, y en menos de diez minutos tenía un sitio funcionando en Tor. Lo que más me llamó la atención es lo aburrido que es el proceso. Esperaba criptografía exótica, bridges, algo dramático. Nada: configuración estándar, nada exótico, solo TCP y un nginx escuchando en loopback.
Hay una razón práctica para hacer esto además de la paranoia: resiliencia ante censura. Un dominio normal depende de un registrador, de DNS, de un certificado. Un .onion solo depende de que tu servidor esté vivo y de que la red Tor exista. Si tu hosting te cierra la cuenta o tu país bloquea el dominio, el .onion sigue respondiendo. Para un blog personal es un lujo, para un proyecto en un contexto sensible puede ser la diferencia entre seguir publicado o no.
Limitaciones que hay que nombrar
El rendimiento es la asignatura pendiente. Cada request viaja por varios relays voluntarios, así que el sitio es lento comparado con el mismo sitio en clearnet. No hay CDN, no hay edge caching, no hay nada de la infraestructura de aceleración a la que estamos acostumbrados. El otro límite: la dirección .onion es fea, imposible de memorizar, y solo funciona con el navegador Tor o con la configuración apropiada en Firefox. Tu audiencia normal probablemente no lo use, pero está ahí, funcionando, como declaración de principios: mi contenido no está atado a un registrador ni a un proveedor de DNS.
¿Lo recomendaría? Para un blog personal sí, como changa técnica de una tarde. Para producción seria, depende del contexto: si tu amenaza es censura o vigilancia, sí; si tu problema es performance o SEO, no es la herramienta.
Fuente del tema: Self-Hosting on the Dark Web, blog de David Álvarez Rosa.
Fuente de inspiración: Self-Hosting on the Dark Web
