Historia de Tor: del onion routing hasta hoy

Historia de Tor, en resumen

La historia de Tor comienza en 1995 en el U.S. Naval Research Laboratory, un laboratorio de investigación de la U.S. Navy. David Goldschlag, Michael G. Reed y Paul Syverson desarrollaron allí los primeros prototipos de onion routing. La cronología del Tor Project indica que la pregunta que plantearon era si «había una forma de crear conexiones a Internet que no revelaran quién se comunicaba con quién». La red que se utiliza actualmente se implementó en octubre de 2002 y su código se publicó con una licencia de software libre y abierto. Tor Project, Inc. se fundó como organización sin ánimo de lucro en 2006.

Todas las fechas siguientes proceden de la cronología publicada por Tor Project, de sus notas de versión o de sus propias páginas de soporte. Cuando una afirmación es objeto de controversia, como quién financia el trabajo, esta sección indica cuáles son las pruebas y dónde puede comprobarlas por su cuenta.

Qué hace realmente el enrutamiento cebolla

El enrutamiento cebolla separa dos datos que Internet normalmente mantiene unidos: quién es usted y qué ha solicitado. Su cliente Tor selecciona tres relays y crea un circuito a través de ellos. Envuelve el tráfico en tres capas de cifrado, una por relay. Cada relay elimina una capa, obtiene sólo la dirección del siguiente salto y reenvía el paquete. De ahí procede el nombre.

El primer relay, denominado guard, ve su dirección IP, pero no el destino. El último relay, el exit, ve el destino, pero no su dirección IP. El relay intermedio no ve ninguno de los dos datos. Ningún relay individual contiene ambas partes. Ese es todo el argumento de seguridad. Por eso los relays deben estar operados por personas no relacionadas entre sí. Si una organización operara su guard y su exit, la separación desaparecería y el cifrado no le aportaría ninguna protección.

La debilidad conocida es la correlación del tráfico. Un observador que pueda supervisar ambos extremos de un circuito al mismo tiempo puede relacionar el momento y el tamaño de los paquetes entrantes con los de los paquetes salientes. Tor no protege frente a un atacante capaz de supervisar Internet completo de forma simultánea. El documento de diseño de 2004 escrito por Roger Dingledine, Nick Mathewson y Paul Syverson, "Tor: The Second-Generation Onion Router", lo indicó en su modelo de amenazas.

Por qué una red privada habría sido inútil

Esta es la parte que omiten los resúmenes breves y explica todo lo demás de esta página.

Una organización militar o de inteligencia no puede obtener anonimato de una red que transporta únicamente su propio tráfico. El anonimato depende de una multitud, no de un cifrado. Si todas las conexiones que salen de la red pertenecen a una sola oficina, un observador que vea salir una conexión ya habrá obtenido la respuesta. El cifrado seguirá funcionando perfectamente. El anonimato no existirá, porque no habrá nadie con quien confundirla.

Por tanto, el diseño debía ser público y el tráfico debía mezclarse con el tráfico de otras personas. El código se publicó con una licencia de software libre en octubre de 2002, y cualquiera podía ejecutar un relay. Periodistas, activistas, investigadores y personas que simplemente querían evitar una red publicitaria formaron la multitud que protege a todos los demás usuarios. Dingledine y Mathewson expusieron este argumento en 2006 en un artículo titulado "Anonymity Loves Company: Usability and the Network Effect", presentado en el Workshop on the Economics of Information Security. La conclusión es que el tamaño y la diversidad de la base de usuarios son propiedades de seguridad del sistema. No son una cifra de marketing.

Del código alfa a una organización sin ánimo de lucro

La cronología de The Tor Project y sus artículos publicados documentan estos pasos:

• Octubre de 2002: se despliega la red Tor con el código «bajo una licencia de software libre y abierto».
• Finales de 2003: la red funciona con «aproximadamente una docena de nodos voluntarios, principalmente en Estados Unidos, y uno en Alemania».
• 2004: Dingledine, Mathewson y Syverson publican el artículo de diseño «Tor: The Second-Generation Onion Router».
• 2004: la Electronic Frontier Foundation (EFF) comienza a financiar el trabajo en Tor.
• 2006: se funda The Tor Project, Inc. como organización sin ánimo de lucro 501(c)(3) para mantener el desarrollo.
• 2007: comienza el trabajo en bridges, porque los firewalls nacionales han empezado a bloquear la lista pública de relays.
• 2008: comienza el desarrollo de Tor Browser.

Dos fechas posteriores son importantes para entender cómo se usa la red actualmente. La cronología de The Tor Project sitúa el uso de Tor durante la Primavera Árabe, a finales de 2010, para proteger la identidad y acceder a sitios bloqueados. También registra los documentos de Snowden de 2013 como el momento en que la función de Tor pasó a conocerse ampliamente, y afirma que los documentos demostraron que Tor no había sido vulnerado en ese momento. Ninguno de estos acontecimientos modificó el protocolo. Ambos cambiaron quién lo instalaba.

Quién financia Tor y cómo comprobarlo

The Tor Project responde a esta cuestión en sus propias páginas de soporte: «The Tor Project is supported by a mix of government grants, private foundations, and individual donors». La financiación pública forma parte de esa mezcla desde el principio. La página de patrocinadores menciona al U.S. Department of State junto con Ford Foundation, Open Technology Fund, Craig Newmark Philanthropies y empresas como Brave, DuckDuckGo, Mullvad VPN y Fastly. Los estados financieros auditados se publican como entradas de blog; la publicación más reciente, de diciembre de 2025, cubre el ejercicio financiero de 2023 a 2024. La posición declarada del proyecto es que «hablar abiertamente sobre nuestros patrocinadores y nuestro modelo de financiación es la mejor forma de mantener la confianza de nuestra comunidad».

La pregunta útil no es quién pagó. Es qué se podría comprar con ese dinero. Tor no es un servicio en el que se inicia sesión. Es una especificación de protocolo, un cliente cuyo código fuente se puede leer y una red de relays operados por terceros. Quien quisiera introducir una puerta trasera tendría que hacerlo en uno de tres lugares, y cada uno se puede comprobar.

• En el código fuente. El cliente es open source y el protocolo está especificado públicamente. Los investigadores académicos publican ataques contra Tor con regularidad y tienen todos los incentivos profesionales para encontrar primero cualquier fallo.
• En el binario. Las compilaciones de Tor Browser son deterministas desde agosto de 2013, de modo que un compilador independiente puede reconstruir una versión y compararla byte a byte con la descarga publicada. Un binario que no coincide con su código fuente se puede detectar sin confiar en la persona que lo distribuyó.
• En los relays. The Tor Project no opera la red. «The Tor network relies on volunteers to donate bandwidth», y los guards, relays intermedios, exits y bridges pertenecen a miles de operadores sin relación entre sí. Comprometer a un financiador no compromete esos relays.

La declaración del propio proyecto es breve: «Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering». Esa frase sólo tiene valor porque cada afirmación identifica algo que se puede comprobar directamente.

Existe una salvedad real, relacionada con las prioridades y no con la integridad. La financiación mediante subvenciones determina qué trabajos se realizan primero, por lo que la elusión de la censura ha recibido financiación de forma más constante que, por ejemplo, el rendimiento de la red. Es una crítica legítima al proyecto. Es distinta de afirmar que «el código está comprometido», y se responde leyendo los informes financieros, no confiando en las garantías de nadie.

Los servicios ocultos pasaron a llamarse servicios onion

Un servicio onion es un servidor que nunca revela su dirección IP. El cliente y el servidor construyen su propio circuito hasta un punto de encuentro dentro de la red, por lo que ninguno conoce la dirección del otro. La dirección no es un nombre que un registro haya asignado a alguien. Se deriva de la clave pública del servidor. Por eso una dirección .onion parece una cadena de caracteres aleatorios.

La cronología de los servicios onion recoge las versiones:

• 8 de abril de 2004: los servicios ocultos se implementan por primera vez en Tor 0.0.6pre1.
• 21 de septiembre de 2007: llegan los servicios ocultos de versión 2 en Tor 0.2.0.7-alpha.
• 19 de diciembre de 2016: comienza el desarrollo de la versión 3 en Tor 0.3.0.1-alpha.
• 9 de enero de 2018: se publica la versión 3 en Tor 0.3.2.9.

El cambio de nombre de "servicios ocultos" a "servicios onion" se produjo gradualmente y no en una fecha concreta. La documentación del Tor Project todavía utiliza ambos términos. El nombre antiguo describía el aspecto equivocado. Muchos sitios onion son públicos, están indexados y se anuncian. Lo que está oculto es la ubicación del servidor, no el sitio. El nombre original permanece en el archivo de configuración, como un vestigio útil. Esta sigue siendo la forma de declarar uno en torrc:

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

El directorio contiene las claves del servicio y un archivo hostname que contiene la dirección. La línea de puerto asigna un puerto de la dirección onion a una dirección local del mismo equipo. Así, el servidor web puede permanecer asociado a 127.0.0.1 y no escuchar nunca en una interfaz pública. La versión 3 es la opción predeterminada. Por tanto, un servicio creado hoy con estas dos líneas obtiene una dirección v3. En un servidor alquilado, el procedimiento consiste principalmente en mantener nginx en la interfaz de loopback y cerrar las fugas que podrían relacionar la dirección con la IP pública. Eso es lo que explica paso a paso alojar un sitio .onion en su propio VPS.

Una dirección onion tampoco es un nombre de dominio. RFC 7686, publicado en octubre de 2015, reservó .onion como nombre de dominio de uso especial para que los resolvers normales dejaran de filtrar estas consultas al DNS público (sistema de nombres de dominio). La norma establece una regla directa: "Los servidores autoritativos DEBEN responder a las consultas para .onion con NXDOMAIN." Compárelo con cómo se resuelve un nombre de dominio normal. La diferencia es precisamente esa. Un registro le asigna un nombre DNS y este se consulta mediante servidores que usted no controla. Una dirección onion es una clave pública, por lo que se autentica por sí misma y no necesita ninguna consulta.

Por qué las direcciones .onion antiguas dejaron de funcionar

Los dos formatos de dirección no son compatibles, y el formato antiguo se desactivó de forma permanente.

[
  {
    "version": "v2 (retired 2021)",
    "address_length_chars": 16,
    "service_key": "RSA-1024",
    "address_hash": "SHA-1, truncated to 80 bits"
  },
  {
    "version": "v3 (current)",
    "address_length_chars": 56,
    "service_key": "Ed25519",
    "address_hash": "SHA3-256"
  }
]

Una dirección v2 tenía 16 caracteres porque sólo incluía los primeros 80 bits del hash SHA-1 de una clave pública RSA-1024. Una dirección v3 tiene 56 caracteres porque incluye una clave pública Ed25519 completa, además de una suma de comprobación y un byte de versión. La dirección v3 es más larga porque dejó de truncar estos datos. Por tanto, la propia dirección es ahora la identidad completa del servicio.

La obsolescencia se aplicó según un calendario anunciado:

• 15 September 2020, Tor 0.4.4.x: Tor empieza a advertir a los operadores y clientes de que v2 está obsoleto.
• 15 July 2021, Tor 0.4.6.x: se elimina la compatibilidad con v2 del código fuente.
• 15 October 2021: las nuevas versiones estables del cliente para todas las series compatibles desactivan v2.

El motivo indicado era criptográfico. "A medida que evolucionó el conocimiento de la humanidad sobre las matemáticas y la criptografía, la base de la versión 2 se volvió frágil y, en ese momento, insegura." Un hash SHA-1 truncado a 80 bits y una clave RSA de 1024 bits estaban por debajo de un nivel razonable en 2021. Además, el formato de dirección no dejaba espacio para cambiar ninguno de los dos.

La consecuencia para el lector es sencilla, por lo que conviene expresarla claramente. Todos los enlaces .onion de 16 caracteres publicados antes de 2021 están permanentemente inactivos y no existe ninguna redirección. Una dirección v2 no se podía actualizar porque la dirección era la clave antigua. Los operadores tenían que crear un servicio nuevo y publicar la nueva dirección mediante algún canal en el que sus usuarios ya confiaran.

Puentes y transportes conectables: la censura siguió cambiando

La lista de relays públicos se publica de forma intencionada para que el cliente pueda elegir su propia ruta, en lugar de confiar en que un servidor la elija. Esa misma lista pública es una lista de bloqueo preparada para cualquier país que quiera detener Tor. El trabajo en los puentes comenzó en 2007. Un puente es un relay que no aparece en la lista pública. Puede solicitar un número reducido de ellos por web o por correo electrónico, y un censor no puede bloquear direcciones que no puede enumerar. Esa oferta existe sólo porque los voluntarios siguen añadiendo puentes, y ejecutar un puente obfs4 en un VPS económico requiere unas pocas directivas de torrc y una regla de firewall, no un proyecto completo.

Después, el bloqueo pasó de las direcciones a la forma del tráfico. La inspección profunda de paquetes reconoce el protocolo Tor en la red, independientemente de la dirección IP a la que se dirija. La respuesta fueron los transportes conectables: una envoltura que cambia el aspecto del tráfico de Tor sin cambiar su funcionamiento. En las versiones actuales de Tor Browser, se distribuyen como un único binario llamado lyrebird, sucesor de obfs4proxy, y el lado del cliente requiere tres líneas de torrc:

UseBridges 1
ClientTransportPlugin meek_lite,obfs4,snowflake,webtunnel exec [PATH]/lyrebird
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Sustituya [PATH] por el directorio que contiene el binario lyrebird y copie la línea Bridge completa del sitio de puentes de Tor Project, en lugar de escribirla manualmente. Cada transporte resuelve un método de bloqueo distinto:

• obfs4 hace que el tráfico parezca irreconocible, sin una cabecera de protocolo que un filtro pueda detectar. La recomendación de Tor es probarlo primero, porque es un transporte aleatorio que funciona para la mayoría de los usuarios.
• snowflake le conecta mediante proxies de corta duración ejecutados por voluntarios dentro de navegadores web normales, por lo que la dirección a la que se conecta cambia continuamente. Llegó a la versión estable de Tor Browser en la versión 10.5, el 6 de julio de 2021.
• meek encamina la conexión a través de un proveedor de nube grande, de modo que el tráfico parece dirigirse a ese proveedor; bloquearlo también implicaría bloquear al proveedor.
• webtunnel adopta el enfoque opuesto a obfs4. En lugar de parecer irreconocible, parece una conexión HTTPS normal con un servidor web, al «envolver la conexión de carga útil en una conexión HTTPS similar a WebSocket». Tor Project lo incluyó en la versión estable de Tor Browser el 12 de marzo de 2024, para redes que sólo permiten una lista breve de protocolos.

Esta secuencia refleja la evolución real de los últimos veinte años. Cada transporte nuevo existe porque una técnica de bloqueo concreta empezó a funcionar, y las fechas de esas versiones registran lo que hacían los censores durante ese año.

Tor no es una VPN, y un VPS tampoco

Muchas personas llegan a Tor después de leer sobre VPN, por lo que conviene ser precisos. Una VPN (red privada virtual) envía el tráfico a un servidor administrado por una empresa, y esa empresa ve la dirección real y el destino al mismo tiempo. Tor envía el tráfico a través de tres relays administrados por personas diferentes, por lo que ninguno de ellos tiene ambos datos. Son modelos de confianza distintos, con modos de fallo distintos. La diferencia entre un VPS y una VPN explica dónde encaja cada uno.

Si lo que quiere es un túnel privado entre máquinas que controla, y no anonimato dentro de un grupo de usuarios, necesita una VPN administrada por usted. Puede autoalojar una VPN WireGuard en un VPS con unas cuarenta líneas de configuración. Esto protege el tráfico frente a la red local y el proveedor de Internet. No proporciona anonimato frente a la empresa que aloja el servidor, porque alquiló ese servidor con sus propios datos de pago. La cuestión independiente de si el alojamiento VPS es seguro trata otra amenaza: quién más puede acceder a su servidor.

Ejecutar un relay es la otra dirección, y la red depende de ello. Los bridges, guards, middle relays y exits necesitan operadores, y la guía de relays del Tor Project deja claro que «ejecutar un relay requiere conocimientos técnicos y compromiso». Los exits implican exposición legal, porque el tráfico de otras personas sale a Internet con su dirección IP y el proveedor de alojamiento recibirá notificaciones al respecto. Lea esa guía antes de iniciar uno, no después.

FAQ

¿Tor fue creado por el gobierno de Estados Unidos?

El encaminamiento cebolla comenzó en el U.S. Naval Research Laboratory en 1995, donde David Goldschlag, Michael G. Reed y Paul Syverson crearon los primeros prototipos. Tor fue el diseño de siguiente generación, iniciado alrededor de 2001 y 2002 por Roger Dingledine, Nick Mathewson y Paul Syverson. La red se puso en funcionamiento en octubre de 2002 con una licencia de software libre. Tor Project, Inc. es una organización sin ánimo de lucro independiente 501(c)(3) desde 2006. El origen gubernamental es real, y también es la razón por la que la red tuvo que abrirse a todo el mundo: una red que transporta el tráfico de una sola organización no proporciona anonimato a esa organización, porque cada conexión que sale de ella identifica al remitente por el simple hecho de usarla.

¿La financiación gubernamental significa que Tor tiene una puerta trasera?

La respuesta de Tor Project es: «Tor no tiene puertas traseras. El software es de código abierto, su código puede auditarse de forma independiente y cada versión está firmada para protegerla contra manipulaciones». Lo que hace que esto pueda comprobarse, en lugar de ser una promesa, es la estructura que lo respalda. El protocolo está especificado públicamente, las compilaciones de Tor Browser son deterministas, de modo que un compilador independiente puede reconstruir una versión y compararla con el binario publicado, y los relays están gestionados por voluntarios, no por ningún financiador. La financiación sí influye en qué trabajos se realizan primero, y los informes financieros auditados del blog de Tor muestran de dónde procede el dinero. Es una cuestión de prioridades, no del código.

¿Por qué dejó de funcionar mi antigua dirección .onion?

Era una dirección de versión 2, y los servicios onion v2 se retiraron en 2021. Tor empezó a advertirlo el 15 de septiembre de 2020, eliminó v2 del código fuente en Tor 0.4.6.x el 15 de julio de 2021 y lo deshabilitó en las versiones estables el 15 de octubre de 2021. Una dirección v2 tiene 16 caracteres antes de .onion y una dirección v3 tiene 56. No existe ninguna redirección ni una ruta de actualización, porque la dirección se derivaba de la clave antigua. Por tanto, el operador tuvo que crear un servicio nuevo y publicar la nueva dirección.

¿Tor es lo mismo que una VPN?

No. Una VPN envía el tráfico a un único servidor gestionado por una empresa, y esa empresa puede ver conjuntamente su dirección IP real y su destino. Tor envía el tráfico a través de tres relays gestionados por personas diferentes. El primer relay ve su dirección, pero no el destino, y el último ve el destino, pero no su dirección. Tor es más lento y está diseñado para proporcionar anonimato frente a un observador que no supervisa toda Internet. Una VPN es más rápida y está diseñada para proteger la privacidad frente a la red local y el proveedor de Internet.

¿Qué es un transporte modular y necesito uno?

Un transporte modular es una envoltura que cambia el aspecto del tráfico de Tor en la red sin cambiar el funcionamiento de Tor. Así, un filtro que reconoce el protocolo de Tor no puede identificarlo mediante ese patrón. Sólo necesita uno si Tor no logra conectarse directamente, lo que normalmente significa que la red o el país está bloqueando Tor. Tor Browser incluye obfs4, snowflake, meek y webtunnel en un único binario llamado lyrebird. Empiece por obfs4, porque es un transporte que aleatoriza el tráfico y funciona para la mayoría de las personas. Si la conexión nunca se completa, pruebe webtunnel o snowflake.