TOR es la red anónima más extendida, conocida (y atacada) del mundo y sin duda gran parte de su éxito se debe a que es una red que provee unos buenos niveles de anonimato y privacidad para cualquier usuario en Internet. Sin embargo, para nadie es un secreto que se trata de una red que se ha convertido en el principal objetivo de varios gobiernos y agencias en todo el mundo. Son muchos los que constantemente intentan realizar ataques contra la infraestructura de TOR, la cual se basa principalmente en la gente que “desinteresadamente” decide exponer su máquina como un repetidor y así, hacer que la red sea más grande y difícil de atacar.
2014 ha sido un año complicado para TOR, ya que se han descubierto varios ataques exitosos que han sido admitidos por el equipo del proyecto de los cuales aun no se conoce su impacto real, por este motivo, cuando hablamos de TOR, desafortunadamente ya no podemos hablar de un anonimato fuerte.
Hay varias cosas que personalmente me gustan del proyecto, es muy interesante interesante y cuenta con una comunidad de desarrolladores/contribuidores enorme, sin embargo hay otras que las considero no solamente mejorables, sino claro un fallo de diseño que ahora le esta pasando factura al proyecto. No pretendo criticar la arquitectura y diseño de TOR, aun así creo que hoy en día, con la cantidad de “rivales” y entidades con intenciones de romper el anonimato de los usuarios que usan esta red, ya es una cuestión de tiempo que su arquitectura y diseño se vuelvan indefendibles.
Mis razones para afirmar esto son las siguientes:
- Red centralizada: Las autoridades de directorio son servidores que se encargan de mantener viva la red, de gestionar y verificar el estado de cada repetidor participante, emitir los ficheros de consenso que son utilizados por los clientes para componer sus circuitos, mantener un registro de “Introduction Points”, “Rendezvous Points” y las tablas de servicios ocultos registrados en la red, entre muchas otras labores de administración que son completamente transparentes para los usuarios. Esto es mucho, pero que mucho poder para ser manejado únicamente 10 ordenadores. Esta claro que un ataque dirigido contra algunos de estos ordenadores (o todos) puede generar un caos en la red y esto es algo que ya ha pasado entre los meses de octubre y diciembre del 2014, en los que se llevaron acabo ataques de DoS distribuidos contra algunas de las autoridades de directorio de TOR. El resultado: Gran parte de la red se mantuvo saturada durante varias horas y era prácticamente imposible acceder a la web profunda de TOR.
Ahora bien, no tengo constancia de que existan campañas de APT contra dichos servidores, pero no me extrañaría, es más, hoy en día nadie puede garantizar con un 100% de certeza que todas las autoridades de directorio de TOR están siendo controladas única y exclusivamente por el equipo de TOR.
- Red basada en las buenas intenciones:
Cuando un cliente de TOR registra su instancia como un repetidor en la red, las autoridades de directorio se encargan de verificar varios parámetros relacionados con el rendimiento óptimo del repetidor y si se trata de una instancia maliciosa basándose principalmente en un mecanismo de listas negras. Sin embargo sino hay ningún problema, el repetidor es incluido en el consenso que emiten las autoridades de directorio cada hora y ahora, alguien que efectivamente no conoces pasa a ser el repetidor de salida del circuito que te permite conectarte con la web profunda de TOR. Tal como lo han demostrado la inmensa cantidad de ataques que se han llevado a cabo en el 2014, las autoridades de directorio de TOR no pueden saber si un repetidor concreto es malicioso hasta que es detectado y reportado, algo que puede tardar meses. Este es un problema que tiene difícil solución, pero que se convierte en una situación particularmente problemática dado que los circuitos en TOR son bidireccionales.
- Circuitos bidireccionales:
Cuando un cliente de TOR se conecta a la red, utiliza un circuito compuesto por 3 repetidores, uno de entrada, uno intermedio y uno de salida. Dicho circuito es bidireccional, lo que quiere decir que funciona tanto para enviar como para recibir paquetes de datos para y desde un destino determinado. Este modelo seria desastroso para una red anónima pequeña, pero ese no es el caso de TOR, ya que la cantidad de voluntarios en todo el mundo es enorme, pero tal como comentaba anteriormente cualquiera puede exponer su ordenador como un repetidor en la red y aunque las autoridades de directorio cuentan con rutinas para la detección de repetidores maliciosos, al final se basan en una relación de confianza y si no hay indicios que demuestren lo contrario, las autoridades de TOR se fían de los clientes que registran sus instancias como repetidores de cualquier tipo. Si hablamos de un adversario con suficientes recursos, puede registrar una gran cantidad de repetidores en la red de TOR y controlar gran parte del trafico de los usuarios y dado que los circuitos en TOR son bidireccionales, realizar ataques basados en los tiempos de las peticiones/repuestas, correlacionales y análisis de trafico para identificar a un usuario, es mucho más sencillo de implementar. Imaginaros por un segundo, ¿Qué pasaría si los circuitos fueran unidireccionales? Pues que este tipo de ataques dejarían de ser viables, dado que teóricamente no habría forma de correlaccionar el trafico de un circuito con otro basándose únicamente en las estadísticas, eso sin contar con que para el adversario seria necesario contar con el doble de recursos para controlar dos circuitos distintos.
- ¿Únicamente TCP?
La red de TOR únicamente soporta protocolos de red basados en TCP, como por ejemplo HTTP, FTP, SSH, etc. Sin embargo, si se utiliza cualquier otro servicio basado en un protocolo de red distinto, como es el caso de DNS, puede existir una fuga de información que posiblemente revelará la identidad del usuario, ya que es trafico que no pasará por medio de TOR. Dicho en otras palabras, si una de tus aplicaciones ejecuta peticiones DNS para resolver una dirección IP o un nombre de dominio, dichas peticiones producirán una fuga de información, es más, si simplemente haces un “ping” contra otra máquina, también se producirá una fuga de información. TOR solamente soporta TCP, y peticiones DNS (UDP) o un simple “ping” (ICMP) pueden arruinar tu anonimato. Si bien es cierto que existen aplicaciones como “torsocks” que permiten hacer un “torify” de de las aplicaciones para que todo pase por medio de TOR, la realidad es que las fugas de información siguen siendo un problema bastante común.
- Servicios ocultos. ¿Cuándo va a terminar de cargar mi página?!
En TOR no solamente existen servicios ocultos del tipo HTTP, los hay de todo tipo (siempre y cuando se basen en TCP), pero independiente del tipo de servicio que usemos siempre hay una característica que es común a todos: Son LENTOS. Alguna vez te has preguntado ¿por qué demonios los servicios ocultos en TOR son tan lentos? Probablemente alguien te habrá dicho que es porque el trafico se replica entre varios nodos, por esos son lentos. Eso es FALSO, los servicios ocultos son lentos no solamente porque existan repetidores de por medio, son lentos porque cada servicio oculto se encuentra registrado en una base de datos (hash) que comparten las autoridades de directorio para mantener un registro de las direcciones onion de cada servicio con su correspondiente “Introduction Point”. Dado que dicho proceso es centralizado y el número de direcciones onion es gigantesco, es perfectamente normal presenciar una demora cuando se solicita acceso a un servicio onion, eso sin contar que para preservar el anonimato en ambas partes (tanto para el cliente como para el proveedor del servicio) existen dos circuitos independientes que se conectan entre si para la transferencia de datos entre cliente y servidor. Todo esto ya os lo contaba en un articulo anterior
Ahora bien, es un problema que no tendrá una solución a corto plazo, ya que el tamaño de la red es tan grande que no es de extrañar que las autoridades de directorio se vean colapsadas por la cantidad de peticiones que reciben en picos puntuales del día, así que lo mejor que podéis hacer si navegáis por la web profunda de TOR es respirar profundo y llenaros de mucha paciencia.
Sin embargo no todo en TOR son problemas, eso está claro, ya que sino tuviera las virtudes que tiene nadie la usaría. Una de esas virtudes es la cantidad de usuarios que aportan a la red y el número de personas que crean herramientas, librerías, sitios con documentación, etc. Son aportes que ayudan a todo el ecosistema de la red y que desde luego le han permitido estar en la posición en la que está actualmente.
No obstante, existen otras redes anónimas que si bien llevan prácticamente el mismo tiempo de desarrollo que TOR (entre los años 2003 y 2005) no han tenido las repercusiones ni el impacto que ha tenido TOR. Tal es el caso de redes como I2P y FreeNet, siendo la primera la que desde mi punto de vista puede aportar una solución elegante y eficiente a los problemas que he descrito anteriormente en TOR. Seguramente te preguntaras ¿Y por qué I2P no es tan conocido si es tan bueno? Francamente no me lo explico, pero desde mi punto de vista es una cuestión de propaganda y moda, algo que desafortunadamente mueve muchas cosas en la industria de la seguridad y en la informática en general. Creo que I2P no ha llegado a recibir el reconocimiento que se merece porque en los medios solamente se habla de TOR, es el referente de anonimato por excelencia a cualquiera que se lo preguntes! lo cual es una pena. Por ese motivo me he animado a escribir este articulo, hablando de las desventajas que tiene TOR y como una red como I2P puede aportar una solución real.
- Red descentralizada.
Ya no hablamos de autoridades de directorio, hablamos de máquinas que se conectan a una red privada en la que todos “hablan el mismo idioma” y no existen entidades que gobiernen el funcionamiento general de la red. Tu te conectas y automáticamente ya eres parte de la red, no necesitas descargarte ficheros con información sobre la red o cosas similares, todos los usuarios son repetidores potenciales y están ahí para construir tus propios túneles de comunicación con otros usuarios. Se acabo eso de depender de 1 o 10 ordenadores para poder navegar en la web profunda o para construir circuitos.
- ¿Buenas intenciones? De eso nada, todos juegan con las mismas reglas.
A diferencia de TOR, en I2P no se ruega a nadie que por favor aporte un poco de su ancho de banda y que convierta su instancia de TOR en un repetidor para los circuitos de los usuarios. No, en I2P todos los usuarios que se conectan actúan como repetidores. Esto quiere decir que si te conectas a I2P, una parte de tu ancho de banda será utilizada por otros repetidores en la red, eso si, tu puedes decidir cuanto puedes o quieres aportar. Esto es una característica que en mi opinión es de las más acertadas, ya que hace que los ataques “sybil” sean prácticamente inviables.
- Circuitos en doble sentido y túneles unidireccionales
En TOR los túneles que construyen los clientes están compuestos por tres máquinas y dichas máquinas se utilizan para enviar y recibir información. En I2P esto también cambia, ya que no existen los circuitos como tal, en su lugar se crean túneles de comunicación en un solo sentido. Si un emisor quiere enviar un mensaje a un destinatario contará con un túnel compuesto por “x” repetidores que se encargarán de enviar el mensaje y por otro lado, si el emisor quiere recibir mensajes provenientes de la red, contará con otro túnel compuesto por “z” repetidores que se encargarán de recibir el mensaje y enrutarlo. Este modelo es simplemente genial, ya que los túneles pueden contar con un número configurable de repetidores y solamente se encargan de una única tarea que es enviar o recibir datos. Este modelo no solamente dificulta los ataques de análisis de trafico, sino también los ataques de correlación, ya que los túneles de entrada y salida no guardan ningún tipo de relación entre ellos, son completamente independientes y solamente la instancia que ha construido sus túneles sabe cuales son las máquinas que se utilizan para enviar y recibir datos.
Por otro lado, a diferencia TOR, todas la comunicación va cifrada en todos los puntos, desde el principio hasta el final, utilizando un proceso de cifrado que en el mundo de I2P se conoce como cifrado “Garlic”.
- TCP, UDP, ICMP, el protocolo que quieras.
En I2P no nos limitamos a utilizar protocolo TCP, podemos utilizar cualquier protocolo de red sin temor a perder nuestro anonimato. Esta característica facilita enormemente las cosas a la hora exponer servicios, ya que no solamente no nos limitamos a protocolos conocidos que utilizan TCP, sino a cualquier protocolo de red como UDP. Esta es otra de las razones por las cuales en I2P es posible implementar servicios P2P y descargar torrents y en TOR no.
Servicios ocultos. Por fin, mi página carga rápido!
Los servicios ocultos en I2P no solamente son más eficientes y rápidos, son muchísimo más ricos en términos de funcionalidades, ya que la arquitectura de I2P permite crear sitios web que permitan la ejecución de aplicaciones web 2.0 con Javascript, HTML5, CSS3 y frameworks para mejorar la experiencia de usuario (vease Dojo, NodeJS, AngularJS, etc) de hecho, I2P cuenta con un sistema de plugins que permite desplegar aplicaciones aplicaciones de forma rápida e intuitiva. Tenemos ante nosotros una amplia gama de alternativas que no existen en TOR, eso sin contar con que dado que la red es completamente descentralizada no existen las demoras y molestos retrasos a la hora de acceder a los servicios ocultos en TOR.
I2P es un serio candidato a aquellos que buscan privacidad y niveles fuertes de anonimato. Además, para aquellos como yo, que les gusta ver cómo funcionan este tipo de tecnologías, puede resultar tanto o más interesante que TOR, ya que su arquitectura es tan compleja como genial.
Para no terminar este articulo sin un contenido practico que puedas probar en tu ordenador, me gustaría dejar una referencia a algunos artículos que he escrito sobre I2P en este sitio:
– http://thehackerway.com/2011/11/28/preservando-el-anonimato-y-extendiendo-su-uso-conceptos-basicos-sobre-el-uso-de-i2p-parte-xxii/
– http://thehackerway.com/2011/11/30/preservando-el-anonimato-y-extendiendo-su-uso-conceptos-basicos-sobre-el-uso-de-i2p-parte-xxiii/
– http://thehackerway.com/2011/12/02/preservando-el-anonimato-y-extendiendo-su-uso-administracion-de-i2p-aplicaciones-y-servicios-incluidos-parte-xxiv/
– http://thehackerway.com/2011/12/05/preservando-el-anonimato-y-extendiendo-su-uso-administracion-de-i2p-aplicaciones-y-servicios-incluidos-parte-xxv/
– http://thehackerway.com/2011/12/07/preservando-el-anonimato-y-extendiendo-su-uso-servicios-anonimos-eepsites-y-ssh-en-i2p-parte-xxvi/
– http://thehackerway.com/2011/12/09/preservando-el-anonimato-y-extendiendo-su-uso-servicios-anonimos-plugins-en-i2p-parte-xxvii/
– http://thehackerway.com/2011/12/12/preservando-el-anonimato-y-extendiendo-su-uso-arquitectura-y-protocolos-utilizados-en-i2p-parte-xxviii/
– http://thehackerway.com/2011/12/16/preservando-el-anonimato-y-extendiendo-su-uso-estructura-de-i2p-parte-xxx/
– http://thehackerway.com/2011/12/21/preservando-el-anonimato-y-extendiendo-su-uso-hacking-i2p-desarrollo-de-aplicaciones-usando-streaming-library-parte-xxxii/
– http://thehackerway.com/2012/01/18/preservando-el-anonimato-y-extendiendo-su-uso-hacking-i2p-desarrollo-de-aplicaciones-usando-bob-parte-xxxiii/
Si bien es cierto que son artículos que he escrito hace un poco más de 3 años, siguen teniendo vigencia y son bastante útiles para entender en detalle el funcionamiento de I2P.
Finalmente, no creas nada de lo que he dicho, ve y compruébalo por ti mismo!. La invitación es clara, es el momento de comenzar a utilizar I2P y conocer de primera mano los beneficios que nos puede aportar.
Un saludo y Happy Hack!
Adastra.