Autoalojamiento en la dark web

Artículo original ↗ Discusión en Hacker News ↗

Autoalojar sitios web como servicios onion de Tor promete una gran privacidad, sin IP ni DNS expuestos y un alojamiento sencillo incluso detrás de CGNAT, pero conlleva compromisos como alta latencia, direcciones difíciles de compartir y un sistema de nombres frágil que puede romperse masivamente cuando cambian los protocolos. Los comentaristas exploran consejos prácticos de configuración (encabezados Onion-Location, elección de puertos y sockets, monitorización, copias de seguridad de claves privadas), estrategias de rendimiento (reducir la verbosidad, SSR, recursos en línea) y preocupaciones de seguridad, incluidos los fronts de phishing, los DDoS y los riesgos de ejecutar nodos de salida. Varios argumentan que el diseño de Tor lo convierte en una alternativa más limpia y respetuosa con el usuario que la web actual, impulsada por la vigilancia, mientras que otros subrayan que su anonimato y sus prioridades de infraestructura hacen que los sitios onion sean inherentemente efímeros y poco adecuados como único hogar para comunidades duraderas.

Beneficios prácticos y casos de uso

  • Alojar un sitio onion evita DNS, CAs y la exposición de una IP pública; no hace falta redirección de puertos y funciona bien detrás de NAT/CGNAT.
  • Es popular para blogs personales y pequeños servicios desde casa, con privacidad de IP “por diseño”.
  • A algunos les gusta en parte por lo “ingenioso” de poder decir que administran un sitio de la dark web.

Configuración, herramientas y disponibilidad

  • Los servicios ocultos básicos de Tor se describen como sencillos; la principal fricción es la complejidad de la CLI para usuarios no técnicos.
  • Herramientas GUI como OnionShare y proyectos que crean servicios ocultos automáticamente buscan hacer posibles flujos de trabajo de “arrastra una carpeta, obtén un sitio”.
  • Se recomiendan ampliamente los encabezados Onion-Location para que Tor Browser pueda cambiar automáticamente a la copia onion.
  • La disponibilidad debe gestionarse con monitorización estándar; de lo contrario, las caídas pueden pasar desapercibidas durante mucho tiempo.
  • Los servicios onion recién creados o reiniciados pueden tardar en volverse accesibles; se necesitan bridges (obfs4, Snowflake) donde Tor está bloqueado.

Seguridad, anonimato y confianza

  • Los servicios ocultos no te convierten en un nodo de salida; no puedes ejecutar “por accidente” un exit. Se desaconseja combinar exit + servicio oculto.
  • Hay debate sobre si los gobiernos pueden desanonimizar Tor de forma fiable: algunos sostienen que normalmente solo se aprovechan malas prácticas de opsec; otros especulan con capacidades no reveladas.
  • El site fronting (proxies onion maliciosos) es un problema reconocido; las mitigaciones incluyen verificación de la dirección fuera del sitio, CAPTCHAs que codifican partes de la URL real, cadenas de confianza y direcciones onion vanity.
  • Hacer copia de seguridad de la clave privada onion es crítico; perderla obliga a usar una nueva dirección.

Rendimiento y decisiones de arquitectura

  • La latencia es alta; funcionan mejor los sitios estáticos o mayoritariamente SSR.
  • Recomendación: minimizar las solicitudes HTTP, mantener las conexiones activas, incrustar CSS en línea, usar CSS en lugar de JS para la interfaz y evitar frontends demasiado verbosos.
  • Hay opiniones distintas sobre los recursos incrustados en base64: útiles en Tor, menos en el clearnet moderno donde brillan el caché y HTTP/2.
  • HTTP/2 puede mejorar el rendimiento, pero requiere TLS; faltan certificados gratuitos para .onion, lo que lleva a debatir si los certificados autofirmados deberían tratarse como confiables para onion.

Limitaciones, riesgos y fugacidad

  • Las direcciones onion son difíciles de recordar o compartir oralmente, y no tienen significado humano.
  • La retirada de los onions v2 se cita como prueba de que “todo en .onion es efímero”; algunos lo ven como un avance de seguridad necesario, otros como una rotura catastrófica de enlaces, única en escala.

UX, accesibilidad y contexto web más amplio

  • Tor suele ser más lento, especialmente para sitios muy verbosos, aunque algunos informan velocidades aceptables una vez establecidos los circuitos.
  • Los usuarios no técnicos se enfrentan a una curva de aprendizaje pronunciada, pero algunos sostienen que aprender los comandos básicos es una expectativa razonable.
  • Las comparaciones con el “clearnet” critican el diseño impulsado por anuncios/vigilancia, los frontends agresivos anti-bot/CDN y el scraping para entrenar IA; los sitios onion son elogiados por ser ligeros, aptos para texto y libres de seguimiento.
  • Algunos prefieren términos como “free web” en lugar de “dark web”.