Cómo se distribuyen los puentes de Tor: BridgeDB, rdsys, Moat y la lógica de la escasez
Un puente es un repetidor de Tor no publicado: no aparece en la lista pública de repetidores, así que un censor debe descubrirlo antes de poder bloquearlo. Esa propiedad solo se mantiene mientras el puente siga siendo difícil de obtener, lo que convierte al propio sistema de distribución en parte de la resistencia a la censura de Tor. En octubre de 2024, el Proyecto Tor retiró BridgeDB, el sistema que llevaba más de una década repartiendo puentes, y completó la migración a rdsys, su sistema de distribución de nueva generación. Cómo deciden estos sistemas quién recibe cada puente explica mucho sobre por qué los puentes siguen funcionando en redes fuertemente censuradas.
De BridgeDB a rdsys
BridgeDB se publicó hace más de once años como un prototipo y siguió funcionando mucho más allá de su vida útil prevista. Según los ingenieros tras la migración, ofrecía solicitudes web, solicitudes por correo electrónico y una API del navegador Tor llamada Moat, y los tres canales acabaron bajo presión: los censores raspaban los sitios web de solicitud de puentes, saturaban el sistema de correo para cosechar direcciones y saltaban los captchas recurriendo a servicios humanos de resolución de CAPTCHAS. Años de parches contra esas tácticas se convirtieron en deuda técnica, así que el proyecto empezó hacia 2020 a desarrollar un reemplazo: rdsys. rdsys, siglas de resource distribution system (sistema de distribución de recursos), es deliberadamente más amplio que su predecesor. Reparte recursos para eludir la censura de muchos tipos: puentes de Tor, proxies de Snowflake, puntos de VPN, incluso enlaces de descarga de software para eludir bloqueos. En cuanto a la arquitectura, es un proceso backend que recopila recursos y varios procesos distribuidores que los entregan. El backend lleva el inventario y asigna cada recurso a exactamente un distribuidor; la tarea del distribuidor, como dice la documentación de rdsys, es repartir los recursos con criterio, ofrecer una interfaz usable y frustrar los ataques Sybil. Los canales de distribución
La documentación de soporte del Proyecto Tor resume la premisa sin rodeos: "Como las direcciones de los puentes no son públicas, tendrás que solicitarlas tú mismo". Hoy existen varios canales paralelos, cada uno con su propio filtro de acceso. - Moat está integrado en el navegador Tor: el usuario pulsa "Solicitar puentes" en los ajustes de conexión, resuelve un captcha y los puentes se añaden automáticamente.
- El distribuidor HTTPS opera el sitio web de puentes, que ofrece una opción de un clic ("Just give me bridges!") junto con opciones avanzadas como el tipo de transporte o direcciones IPv6.
- El distribuidor de correo responde a los mensajes enviados a bridges@torproject.org desde una dirección de Gmail o Riseup con "get transport obfs4" en el cuerpo.
- El distribuidor de Telegram entrega puentes a través del @GetBridgesBot, con comandos como /obfs4 o /webtunnel. Para distinguir a los usuarios reales de las cuentas creadas en masa, pondera el historial de la cuenta y separa las antiguas de las recién registradas; el Proyecto Tor lo describe como una respuesta a la creciente censura en Rusia.
- Lox, todavía en desarrollo, es un mecanismo que preserva la privacidad y se basa en la reputación: detecta puentes bloqueados y recompensa a los usuarios cuyos puentes siguen sin bloqueo.
También hay dos no-canales que conviene conocer. Un grupo reservado (Reserved) se aparta para distribución manual a ONG y personas con necesidades especiales, y los puentes marcados como None quedan en manos de sus operadores para distribuirlos por su cuenta. Un puente recién registrado muestra None durante aproximadamente un día antes de incorporarse a su grupo asignado. Moat y el compromiso del captcha
Moat merece un vistazo más de cerca porque es el camino que la mayoría de los usuarios nuevos encuentran primero. El captcha era la forma que tenía el sistema de demostrar que una petición venía de un humano y no del rastreador de un censor, y resolver uno sigue siendo el flujo documentado dentro del navegador Tor. Pero la propia evaluación del Proyecto Tor es que los captchas se han vuelto un mal trato: son frustrantemente inaccesibles para quienes usan lectores de pantalla o dispositivos antiguos, a veces imposibles por barreras de idioma, y cada vez menos eficaces porque los censores emplean herramientas automatizadas o servicios de resolución humana que los atraviesan sin esfuerzo. Por eso rdsys está abandonando los captchas, y por qué Moat está siendo sustituido por el distribuidor Settings, una API que configura automáticamente los ajustes de elusión, incluido el tipo de puente a probar, según el país del usuario. Por qué la escasez es la clave
Cada puente entregado es un puente que un censor podría aprender, así que la distribución se raciona deliberadamente en lugar de publicarse. El backend de rdsys solo entrega recursos que se sabe que funcionan: el servicio bridgestrap prueba los transportes conectables de cada puente y los marca como funcionales o defectuosos, un servicio aparte mide el ancho de banda, y cada puente de Tor se vuelve a probar cuando caduca su temporizador de dieciocho horas. Los operadores pueden consultar el estado de su propio puente en una página de estado pública mediante la huella digital. Los puentes bloqueados o rotos se retiran de la circulación en lugar de ofrecerse a más usuarios de la misma región, y un mecanismo como Lox está diseñado precisamente para detectar puentes bloqueados y llevar puentes frescos a quienes aún los necesitan. Un problema abierto de investigación
La tensión de fondo es antigua. En un artículo de 2016, los investigadores detrás del protocolo TorBricks lo dijeron sin rodeos: los métodos actuales de distribución de puentes son vulnerables a usuarios maliciosos que obtienen y bloquean direcciones de puentes. Su propuesta racionaba un presupuesto logarítmico de puentes por usuario adversario, de modo que incluso con un número desconocido de solicitantes controlados por el censor, los usuarios honestos pudieran conseguir un puente funcional tras unas pocas rondas de comunicación. Una década después, el problema general sigue sin resolver; la respuesta de rdsys es pragmática más que matemática: muchos canales pequeños, cada uno con heurísticas distintas, para que ni un raspado ni una inundación aislada agoten el fondo. Para la contraparte práctica de este artículo, nuestra guía sobre puentes en regiones censuradas cubre cómo solicitarlos y configurarlos hoy. La conclusión
La distribución de puentes es un acto de equilibrio entre alcanzabilidad y escasez. Publicar demasiado libremente permite que los censores recopilen la lista; filtrar demasiado estrechamente deja fuera a usuarios legítimos. El paso de BridgeDB a rdsys no puso fin a ese intercambio, pero hizo el sistema lo bastante modular para seguir probando canales nuevos, de Telegram y Lox a valores predeterminados según la ubicación, a medida que los antiguos se erosionan. Para los usuarios censurados, el consejo no ha cambiado: solicita algunos puentes, pruébalos y prepárate para pedir más.
