Esto sería práctico por un número de razones: Haría que Tor fuera más capaz de manejar nuevos protocolos, como VoIP. Resolvería la necesidad completa de socksificar las aplicaciones. Los repetidores de salida tampoco necesitarían asignar un montón de descriptores de archivo para todas las conexiones de salida.

Nos estamos encaminando en esta dirección. Algunos de los problemas más tenaces son:

1. Los paquetes IP revelan características del SO. Aún necesitaríamos hacer normalización de paquetes a nivel de IP, para detener cosas como ataques de huella digital TCP. Dada la diversidad y complejidad de los stacks TCP, junto con los ataques de huella digital de dispositivo, parece como que nuestra mejor apuesta es hacer un paquete con nuestro propio stack TCP de espacio de usuario.

2. Los streams a nivel de aplicación aún necesitan un restregado. Aún necesitaremos aplicaciones del lado de usuario, como Torbutton. Por lo que no se convertirá solo en un asunto de capturar paquetes y anonimizarlos en la capa IP.

3. Ciertos protocolos aún filtrarán información. Por ejemplo, debemos reescribir las solicitudes DNS de manera que sean entregadas a un servidor DNS no vinculable, en vez de al servidor DNS en el ISP del usuario; por lo tanto, debemos entender los protocolos que estamos transportando.

4. DTLS (TLS en datagramas) básicamente no tiene usuarios, y seguro que IPsec es grande. Una vez que hayamos elegido un mecanismo de transporte, necesitamos diseñar un nuevo protocolo Tor de extremo a extremo, para evitar ataques de etiquetado y otras dificultades potenciales con el anonimato y la integridad, ahora que permitimos caídas, reenvíos, etcétera.

5. Las políticas de salida para paquetes IP arbitrarios significan construir un Sistema de Detección de Intrusión (SDI) seguro. Nuestros operadores de nodos nos dicen que las políticas de salida son una de las razones principales por las que están dispuestos a correr Tor. Agregar un SDI para manejar políticas de salida incrementaría la complejidad de seguridad de Tor, y de cualquier manera probablemente no funcionaría, como es evidenciado por el campo entero de boletines de SDI y contra SDI. Muchas dificultades potenciales de abuso son resueltas por el hecho de que Tor solamente transporta streams TCP válidos (en oposición a IP arbitrario, incluyendo paquetes malformados e inundaciones IP.) Las políticas de salida se vuelven aún más importantes en la medida en que somos capaces de transportar paquetes IP. También necesitamos describir compactamente las políticas de salida en el directorio Tor, de manera que los clientes puedan predecir cuáles nodos les permitirán salir a sus paquetes. ¡Los clientes también necesitan predecir todos los paquetes que querrán enviar en una sesión antes de elegir su nodo de salida!

6. Los espacios de nombres internos de Tor necesitarían ser rediseñados. Soportamos las direcciones ".onion" del servicio cebolla mediante la intercepción de las direcciones cuando son pasadas al cliente Tor. Hacer eso al nivel IP requerirá una interfaz más compleja entre Tor y el resolvedor DNS local.

No, no puedes confiar en que la red elija la ruta. Repetidores maliciosos podrían enrutarte a través de sus amigos en colusión. Esto le daría a un adversario la habilidad de observar todo tu tráfico de extremo a extremo.

Requerir que cada usuario de Tor sea un repetidor ayudaría a escalar la red para manejar a todos nuestros usuarios, y correr un repetidor Tor podría ayudar a tu anonimato. Sin embargo, muchos usuarios de Tor no pueden ser buenos repetidores — por ejemplo, algunos clientes Tor operan desde atrás de cortafuegos restrictivos, conectan vía modem, o no están de otra manera en posición de poder repetir tráfico. Proveer servicio a estos clientes es una parte crítica de proporcionar anonimato efectivo para todos, ya que muchos usuarios de Tor están sujetos a restricciones como estas o similares, e incluir a estos clientes incrementa el tamaño del conjunto de anonimato.

Dicho sea eso, sí queremos alentar a los usuarios de Tor para que corran repetidores, de manera que lo que realmente deseamos hacer es simplificar el proceso de configurar y mantener un repetidor. En estos pocos años pasados, hemos hecho una cantidad de progreso en lo que hace a la facilidad de configuración: Tor es bueno para detectar automáticamente si es alcanzable y cuánto ancho de banda puede ofrecer.

Sin embargo, hay cuatro pasos que necesitamos encarar antes de que podamos hacer esto:

• Primero, aún necesitamos mejorar para estimar automáticamente la cantidad correcta de ancho de banda a permitir. Podría ser que aquí cambiar a un transporte UDP sea la respuesta más simple — lo cual no es, ¡ay!, una respuesta muy simple en lo absoluto.

• Segundo, necesitamos trabajar sobre la escalabilidad, tanto de la red (cómo terminar de requerir que todos los repetidores Tor sean capaces de conectarse a todos los repetidores Tor) como del directorio (cómo terminar de requerir que todos los usuarios de Tor sepan acerca de todos los repetidores Tor). Cambios como este pueden tener un gran impacto en el anonimato potencial y real. Ver la Sección 5 del boletín Desafíos por detalles. De nuevo, aquí ayudaría el transporte UDP.

• Tercero, necesitamos entender mejor los riesgos de dejar que el atacante envíe tráfico a través de tu repetidor mientras al mismo tiempo estás iniciando tu propio tráfico anonimizado. Tres boletines de investigación diferentes describen maneras de identificar los repetidores en un circuito mediante el pasaje de tráfico a través de repetidores candidatos y la búsqueda de depresiones en el tráfico mientras que el circuito está activo. Estos ataques de taponamiento no dan tanto miedo en el contexto de Tor, siempre y cuando los repetidores nunca sean clientes también. Pero si estamos intentando alentar a más clientes para que también activen la funcionalidad de repetidor (tanto si es como repetidores puente o como repetidores normales), entonces necesitamos entender mejor esta amenaza y aprender cómo mitigarla.

• Cuarto, podríamos necesitar alguna clase de esquema de incentivos para alentar a las personas para repetir tráfico para otros, y/o convertirse en nodos de salida. He aquí nuestros pensamientos actuales sobre incentivos para Tor.

¡Por favor, ayúdanos con todo esto!

Estaría bien permitirles decir a los operadores de repetidores cosas como rechazar www.slashdot.org en sus políticas de salida, en vez de requerirles aprender todo el espacio de las direcciones IP que podría ser cubierto por el sitio (y luego también bloquear otros sitios en esas direcciones IP).

Sin embargo, hay dos problemas. Primero, los usuarios aún podrían pasar por alto estos bloqueos. Por ejemplo, podrían solicitar la dirección IP en vez del nombre de máquina cuando salen de la red Tor. Esto significa que los operadores igualmente tendrían que aprender todas las direcciones IP de estos destinos.

El segundo problema es que le permitiría a atacantes remotos censurar sitios arbitrarios. Por ejemplo, si un operador Tor bloquea www1.slashdot.org, y luego algún atacante envenena el DNS del repetidor Tor, o cambia de alguna otra manera ese nombre de máquina para resolver a la dirección IP de un sitio de noticias principal, luego repentinamente ese repetidor Tor está bloqueando el sitio de noticias.