Detalles de diseño de cifrado TOR en profundidad

Question

Detalles de diseño de cifrado TOR en profundidad

#1 de RoraΖ (3 votos)

3

Actualmente me cuesta entender los detalles de una conexión en Tor, principalmente porque trato de entender PCTCP . En este artículo, los autores afirman que los cambios son locales en el enrutador de cebolla que utiliza PCTCP y que IPSec reemplaza completamente a TLS en el sentido de integridad, confidencialidad y autenticidad de los objetivos de seguridad.

Bien. Entendí el principio básico de enrutamiento de cebolla, entendí Tor (supongo) y entendí la intención en PCTCP, pero al reemplazar TLS con IPSec, los cambios pueden no ser locales al enrutador de cebolla utilizando PCTCP a menos que tenga una comprensión errónea de la arquitectura de seguridad TOR.

Tor usa enrutamiento de cebolla, lo que significa que el proxy de cebolla (OP) ha negociado tres claves simétricas (K1-3) con cada uno de los enrutadores de cebolla (OR1-3) en el circuito con el intercambio de claves Diffie-Hellman. Estas son las claves para las "pieles de cebolla" que son envueltas en los datos que fluyen por el circuito mediante los proxies de cebolla. (No veo la posibilidad de introducir IPSec aquí)

¿Pero es este el único cifrado en TOR, o las conexiones entre los enrutadores de cebolla también están cifradas? (TLS, sería reemplazable por IPSec) Si es así, ¿por qué es necesario?

Además, PCTCP establece que para evitar que un adversario cuente las conexiones, se presentará IPSec. Pero el modelo de hilo definido en TOR supone que un adversario puede ejecutar su propio enrutador de cebolla, con el que Él podría contar la conexión incluso con IPSec habilitado.

Estaría bien si alguien pudiera explicar el diseño de la conexión como un todo, incluidos todos los lugares donde se utilizan los mecanismos de seguridad. Supongo que la bonita ilustración citada en cada segundo subproceso En la web no está todo hecho de.

encryption tls tor

pregunta ManuelSchneid3r 17.01.2015 - 17:23

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption tls tor

fortalecimiento de la seguridad de Python muchos ataques csh http shellshock

score 3 · Accepted Answer

Conexiones TCP de TOR

El documento PCTCP afirma que TOR utiliza una única conexión TCP con datos multiplexados de varios usuarios. El único búfer de salida requiere que un programador cifre / descifre los datos de cada usuario y se asegure de que todo el procesamiento de cada flujo de datos sea correcto. Esto puede llevar a la caída de datos en un paquete, lo que provoca la retransmisión de ese paquete y causa una latencia general en TOR.

PCTCP está cambiando la forma en que se realizan las conexiones. Están proponiendo que, en lugar de multiplexar a los usuarios en una sola sesión TCP, cada usuario tendrá su propia conexión TCP dedicada entre los enrutadores de cebolla (OR). TOR tiene su propio protocolo para establecer claves entre ORs. Esta operación todavía se puede realizar como de costumbre, pero ahora con una conexión TCP dedicada. El objetivo aquí es intentar reducir la corrupción de datos y la posterior retransmisión de paquetes.

TOR Protocol Communications

TOR usa TLS entre ORs para proteger su comunicación de protocolo TOR. Una vez que se completan los mensajes y se han establecido las claves, los datos cifrados pasan a través de la conexión TCP multiplexada.

PCTCP no cambia la forma en que se intercambian las claves, solo genera una nueva sesión TCP para cada nuevo usuario. Podría usar sesiones TLS para estas conexiones TCP si quisieran. La falla en su diseño es que un adversario puede presenciar la cantidad de conexiones TCP, y podría realizarse un análisis de tráfico en un nodo PCTCP. Para contrarrestar este PCTCP envuelve toda la comunicación entre OR en un túnel IPSec. Esencialmente, mover la multiplexación de datos en el nivel de transporte al nivel de IP. Dado que IPSec se realiza en la capa IP, al origen y al destino no les importa cuáles son los datos TCP. Los paquetes serán descifrados / encriptados, y las conexiones TCP individuales serán procesadas normalmente por el demonio TOR. El documento PCTCP indica que esto hace que el uso de TLS entre ORs sea redundante. Lo que hace. Ahora estarías haciendo un túnel dentro de un túnel.

Tenga en cuenta que esto es solo entre las RUP. Los datos entre el OP y el nodo de entrada continuarán utilizando una conexión TLS para asegurar sus comunicaciones. Aún puede obtener un rendimiento significativo ya que la mayoría de los datos eliminados y las retransmisiones se deben a la ineficiencia de las RUP.

Así es como pueden afirmar que los cambios solo deben ocurrir en las RUP. El OP utiliza su mismo método de comunicación con el nodo de entrada. Los RUP deben habilitar IPSec y usar PCTCP para establecer conexiones TCP dedicadas por usuario. IPSec está habilitado de forma predeterminada en todas las distribuciones de Linux ahora. Mientras el OR esté configurado correctamente, se puede establecer este túnel.

Realmente no indican cómo manejan una conexión si se rechaza el túnel IPSec. Supongo que su cliente PCTCP volvería por defecto a una conexión TLS. También eluden el hecho de que incluso un solo nodo actualizado a PCTCP en un circuito mejorará el rendimiento. Pero me parece que para que IPSec funcione, necesitaría al menos dos OR adyacentes configurados con PCTCP. En sus experimentos siempre tienen al menos dos.

Creo que abordé cada una de tus preguntas.