Curso MIT "Seguridad de sistemas informáticos". Lección 19: "Redes anónimas", parte 2 (conferencia del creador de la red Tor)

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3
Lección 14: "SSL y HTTPS" Parte 1 / Parte 2 / Parte 3
Lección 15: "Software médico" Parte 1 / Parte 2 / Parte 3
Lección 16: "Ataques de canal lateral" Parte 1 / Parte 2 / Parte 3
Lección 17: "Autenticación de usuario" Parte 1 / Parte 2 / Parte 3
Lección 18: "Navegación privada en Internet" Parte 1 / Parte 2 / Parte 3
Lección 19: "Redes anónimas" Parte 1 / Parte 2 / Parte 3

Echemos un vistazo más de cerca a cómo funciona el protocolo. Porque sería una pena leer un artículo de una conferencia y no hablar sobre cosas sobre las que llama la atención. Quiero disculparme nuevamente por mi técnica de dibujar en la pizarra, pero la mayor parte del tiempo la paso en la mesa, escribiendo en una computadora.

Esta es una tecnología alienígena. Así que aquí está el repetidor. Y aquí está Alice. Aquí hay otro repetidor y aquí está Bob. Alice ahora quiere hablar con Bob, así que lo primero que hace es crear una cadena a través de estos repetidores para Bob. Digamos que ella eligió estos dos repetidores, R1 y R2. Alice primero hace un enlace TLS a R1, digamos que ya tiene un enlace TLS a R2. Luego, en primer lugar, Alice realiza la autenticación unidireccional, la coincidencia unidireccional de claves anónimas.



El antiguo protocolo Tor se llamaba TAP - Protocolo de autenticación Tor, el nuevo se llama NTor. Ambos tienen evidencia de seguridad. Esta es una evidencia correcta, aunque se han cometido errores en su descripción.

Después de la autenticación, Alice selecciona la identificación del circuito de identificación del canal, digamos 3, le indica al repetidor que cree el canal "3" - crea "3", y él le dice que el canal está creado - creado. Alice y el relé ahora comparten la clave simétrica secreta S1. Y ambos lo almacenan con un índice de "3", que es un enlace a este canal.



Alice ahora puede usar esta tecla para enviar mensajes R1. Ella dice que en la "troika", este es el identificador de canal, que se discute en el artículo de la conferencia, una celda extendida con contenido se envía al relé.



Una celda expandida contiene básicamente la primera mitad de un apretón de manos. Pero esta vez no se cifra con la clave pública R1, sino que se cifra con la clave pública R2. Esto indica que el mensaje se está enviando a R2. Por lo tanto, R1 sabe que es necesario abrir un nuevo canal en R2 y lo informa al relé R2 con el mensaje create (...), donde la misma mitad del apretón de manos que vino de Alice se coloca entre paréntesis. Al hacerlo, R1 crea su propia ID de circuito, ya que los identificadores de canal definen otros canales en esta segunda conexión TLS. Además, Alice no sabe qué identificadores de canal todavía se usan aquí, porque este es un "asunto personal" de R1 y R2.



Por lo tanto, el repetidor puede elegir, por ejemplo, ID 95. De hecho, esto es poco probable, porque el número de canal se selecciona aleatoriamente de 4 bytes de espacio, pero no quiero escribir todos los números de 32 bits hoy.

Después de eso, R2 responde al primer relé "creado", y R1 le devuelve a Alice una celda extendida, encriptada con la tecla S1. Ahora Alice y el relé R2 comparten S2 y Alice puede enviar mensajes, primero encriptados con S2 y luego con S1. Ella envía dicho mensaje, R1 elimina el cifrado de S1 y lo reenvía aún más.



El primer relé sabe que los mensajes del canal 3 deben enviarse al segundo relé en el canal 95. Después de recibir este mensaje, el segundo relé ve que la tecla S2 corresponde al canal 95, y con su ayuda descifra este mensaje: "¡Oh, dice conexión abierta con Bob"! Después de leer esto, el relé R2 abre una conexión TCP con Bob y le informa esto a Alice usando el mismo proceso de paso de mensaje inverso.

Después de todo esto, Alice dice: "genial, entonces dile a Bob algo como http: 1.0get /index.html", y luego la vida continúa.

Veamos lo que me perdí en el artículo de la conferencia ... así que ... esto, esto y esto. Bien, entonces, ¿qué estamos transmitiendo realmente? Algunas soluciones en esta área afirman que es necesario transferir paquetes IP de un lado a otro, es decir, este esquema simplemente debería ser una forma de transmitir paquetes IP. Uno de los problemas es que queremos admitir tantos usuarios como sea posible, lo que significa que debemos trabajar en todo tipo de sistemas operativos.

Pero las pilas TCP de diferentes sistemas operativos actúan de manera diferente. Si alguna vez ha usado Nmap o algún tipo de herramienta de análisis de tráfico de red, puede distinguir fácilmente Windows TCP de FreeBSD TCP o TCP Linux. Incluso puedes distinguir entre diferentes versiones. Además, si puede enviar paquetes IP sin procesar a un host seleccionado, puede provocar respuestas basadas en parte en lo que hace el host.



Entonces, si reenvía paquetes IP de un lado a otro, necesita normalización de IP. Dado que cualquier cosa más pequeña que la pila de IP completa no podrá funcionar en la normalización, no vienes a hacerlo.

En su lugar, elegimos la forma más fácil: simplemente aceptamos todo el contenido de las transmisiones TCP, suponiendo que sea confiable y que todo esté en orden. El programa analiza todos los datos transmitidos por Alice, acepta aceptar conexiones TCP provenientes de sus aplicaciones y simplemente transmite el contenido sin hacer nada complicado a nivel de red.

Podría intentar aumentar la productividad utilizando otros medios descritos en los materiales de la conferencia. Pero describí un esquema que realmente se puede implementar, porque al crear Tor, prestamos mucha más atención a las clases de seguridad y compiladores que a las clases de red. Ahora tenemos especialistas en redes, pero en 2003-2004 experimentamos una escasez de ellos.

El protocolo TCP parece ser un nivel muy apropiado y correcto. Los protocolos de nivel superior discutidos en algunos proyectos originales usan proxies separados en el lado de Alice para HTTP, FTP y parecen una mala idea. Esto se debe a que cualquier protocolo debe tener cifrado de principio a fin a lo largo de la conexión Alice-Bob, y si tenemos suerte, Alice podrá crear una conexión TLS entre R2 y Bob, que tiene características de integridad y seguridad.

Pero si este es el caso, cualquier transformación de anonimato que desee aplicar a los datos cifrados debe ocurrir en la aplicación que utiliza Alice antes de que la conexión TLS se cree completamente. Pero esto no es posible utilizando un servidor proxy, por lo que TCP es más adecuado para nosotros.

Alguien me preguntó, ¿dónde está nuestra evidencia de seguridad? Tenemos evidencia de seguridad para muchos de los métodos de encriptación que utilizamos, estas son versiones estándar de documentos. En general, para el protocolo hay evidencia de la seguridad de ciertos aspectos del enrutamiento de cebolla. Pero los modelos que deben usar para demostrar que esto proporciona el anonimato deben basarse en propiedades tan extrañas del universo, propiedades de la red o las habilidades del atacante que solo pueden satisfacer las comisiones de programación que se encuentran en algunas conferencias teóricas.
En resumen, estas propiedades de anonimato deben demostrar que un atacante que puede ver el volumen y los tiempos de los datos en la sección Alice-R1 no podrá identificarlos, observando solo los bytes de salida en la sección R2-Bob. Pero este no es un resultado satisfactorio. Digamos, ¿qué garantías de seguridad le gustaría de un sistema que no sabe cómo construir? Bueno, tengo que tener cuidado con tales declaraciones ... Recuerde que hay sistemas con fuertes garantías de anonimato, y usted sabe cómo crear tales sistemas, pero nunca querrá usarlos. Como, por ejemplo, la clásica red DC-Net, que proporciona anonimato garantizado, excepto que cualquier participante puede cerrar toda la red simplemente dejando de participar en ella. Además, este sistema no escala.

Pero para las cosas creadas en nuestro tiempo, las propiedades del anonimato son más probabilísticas y no están garantizadas categóricamente. Entonces, en lugar de preguntar si este sistema garantiza la seguridad de Alice, ¿valdría la pena preguntar cuánto tráfico puede enviar Alice de manera segura si quiere tener un 99% de posibilidades de que esta actividad de red no pueda asociarse con su actividad?

La primera pregunta que nos hicimos cuando comenzamos a crear Tor es, ¿quién manejará todas estas cosas? No sabíamos si nuestro sistema realmente "se pondría de pie", por lo que la única opción era tratar de ver qué sucedía.



Tuvimos suficientes voluntarios. Un buen número de organizaciones sin fines de lucro simplemente querían hacer donaciones y usarlas para comprar ancho de banda y lanzar sitios Tor. Algunas universidades y varias empresas privadas participaron en el proyecto, cuyos servicios de seguridad decidieron que sería divertido lanzar su propio servidor Tor.
En este caso, surgieron problemas legales, pero nuevamente, no soy un abogado y no puedo dar una evaluación legal de estas cosas. Sin embargo, cinco personas diferentes me preguntaron sobre la legalidad de nuestro sistema. Por lo que puedo decir, al menos en los Estados Unidos, no hay obstáculos legales para iniciar el servidor Tor. Y me parece que ocurre una situación similar en la mayoría de los países europeos. En países con menos libertad de internet, Tor es más restrictivo.

El problema no es cuán legal o ilegal es el uso del sistema Tor, sino que alguien puede hacer algo ilegal o no deseado con mi servidor Tor. Por ejemplo, ¿mi proveedor me desconectará de la red si proporciono mi computadora como un nodo Tor, las agencias de aplicación de la ley creerán que solo uso el servidor Tor o vendrán y recogerán mi computadora para asegurarse de esto?

Para tal caso, le aconsejaría que no inicie el servidor Tor desde su dormitorio, o más bien, que no use su computadora para transmitir una gran cantidad de tráfico de salida, suponiendo que esto permita la política de red. Honestamente, no tengo idea de qué es esta política ahora porque ha cambiado mucho desde mis días de estudiante. Pero en cualquier caso, un gran tráfico saliente desde su computadora en el albergue puede causar problemas. Sin embargo, comenzar un repetidor sin emitir tráfico a Internet será menos problemático. Pero si su proveedor le permite actuar de esta manera, entonces esto es algo bastante razonable.

Alguien me preguntó qué pasa si los usuarios no confían en un sitio en particular. Esto nos lleva al siguiente tema. Los clientes de la red usan el software a su discreción, y no puede prohibirles usar algunos de los programas y obligarlos a usar otros. Pero recuerda que el anonimato ama la compañía. Si uso tres nodos, usted usa otros tres nodos, y son otros tres nodos, nuestro tráfico no se mezclará en absoluto.



Mientras separemos las partes de la red que usamos, nos distinguiremos fácilmente entre nosotros. Ahora, si simplemente excluyo uno o dos nodos, y usted simplemente excluye uno o dos nodos, esto no será una división tan grande de la red en partes y complicará nuestra identificación. Pero sería óptimo para todos usar los mismos nodos tanto como sea posible. ¿Cómo logramos esto?

Entonces, en la primera versión de Tor, acabamos de entregar una lista de todos los nodos a los usuarios, había alrededor de 6 de ellos, de los cuales tres trabajaban en una computadora en el laboratorio de ciencias informáticas de Tech Square. Pero esta no fue una buena idea, porque la cantidad de nodos aumenta y disminuye, los nodos cambian y no querrá lanzar una nueva versión del software cada vez que alguien se une a la red.

Pero puede asegurarse de que cada nodo contenga una lista de todos los demás nodos que están conectados a él, y todos se "anunciarán" entre sí. Luego, cuando el cliente se conecta a la red, solo necesita conocer un nodo, y luego decir: "Hola, ¿quién está allí en la red"?

De hecho, muchas personas tienen proyectos basados ​​en este principio. Muchos de los primeros proyectos de anonimato entre pares funcionan de esta manera. Pero esta es una idea terrible. Porque si se conecta a un nodo y pregunta quién está en línea, y confía en la parte que responde, entonces puedo responderle: “Estoy en línea, y mi amigo está aquí en línea, y mi amigo también está en línea, y más ¡nadie está en línea! Es decir, puedo decirte cualquier cantidad de nodos falsos que administro y que interceptan todo tu tráfico. Esto es lo que se llama un ataque de captura rw, o un ataque de intercepción en el nodo de origen.

Por lo tanto, es posible que si solo tenemos un directorio administrado por una parte confiable, esto no sea tan bueno, así que supongamos que tenemos varias partes confiables. Los clientes acuden a estas partes de confianza, reciben de cada uno una lista de todos los nodos y la combinan en una lista común de nodos de red.

Esto no es bueno porque nuevamente estamos divididos en grupos de redes identificables. Si selecciono estos tres nodos, y usted selecciona otros tres nodos, entonces utilizaremos diferentes conjuntos de nodos, lo que no es bueno. Además, si uso la lista de nodos que me han pasado, cualquiera de las partes de confianza puede evitar que use un nodo que no le gusta, simplemente no lo especifica en la lista. Si uso una lista combinada, entonces alguien puede inundarme con 20 mil servidores falsos, indicándolos en la lista. Podría votar por su exclusión y de alguna manera resolver los dos últimos problemas, pero aún así estaré separado de todos los que usan diferentes partidos de confianza.



Podríamos crear un DHT mágico, o una tabla hash distribuida, una especie de estructura mágica distribuida que atraviese todos los nodos. Digo "magia" porque, aunque hay proyectos en esta área, y algunos son mejores que otros, ninguno de ellos tiene evidencia sólida de seguridad. Tan difícil que puedo decir con seguridad que es realmente seguro.

Entonces, aquí está la solución a la que llegamos como resultado. Nuestra red tiene varias autoridades confiables, administradas por partes confiables, que recopilan listas de nodos que votan cada hora sobre qué nodos pueden trabajar en la red y pueden votar para excluir nodos sospechosos. Todos trabajan en el mismo / 16, que hace cosas tan extrañas con el tráfico, y forman un consenso que se basa en el cálculo del resultado de la votación.
Y los clientes no usan el nodo si no está firmado por un número suficiente de "votos" de partes confiables.

Esta no es la versión final del proyecto, pero es lo mejor que hemos podido encontrar hasta ahora. Por cierto, todo lo que necesita distribuir entre los clientes es una lista de todas las claves públicas autorizadas y una lista de algunos lugares para recibir directorios. Desea que todos los nodos almacenen en caché estos directorios, porque si no lo hace, la carga de la red se volverá peligrosa y el ancho de banda de la red disminuirá drásticamente.

Tengo la intención de omitir la siguiente pregunta e ir directamente a cómo los clientes deben elegir qué rutas deben enrutar a través de la red. Me gustaría hablar sobre los problemas de usar y crear aplicaciones que no se traicionarían. Me gustaría hablar sobre abusos en la red, servicios ocultos y cómo funcionan, hablar sobre la resistencia a la censura, y también me gustaría hablar sobre ataques y protección. Pero solo nos quedan 35 minutos, así que no puedo hablar de todo lo que quiero. Le pido que vote sobre los temas que considere más importantes para la discusión.

Si cree que uno de los temas más importantes es la elección de rutas y nodos, levante la mano. Si uno de los temas más importantes son los problemas de la aplicación y cómo asegurarse de que las aplicaciones no violen su anonimato, levante la mano. Si el abuso es uno de los problemas más importantes y cómo se puede prevenir, levante la mano. Entonces, veo que este tema es popular, y lo marco.

Si es importante para usted cómo funcionan los servicios ocultos y cómo se puede hacer que funcionen mejor, levante la mano. , , . , . , ? , . ?



, . , , . , , — .

, . , IP-, , . , Whole stack, -, , Tor.

«» -, , , , , , , , .
, : , , , . , -, . , . , . . , .

, . , , – , -, . , BitTorrent, Gnutella . , , , .

, , , 80 443. , 80. IRC- - IRC. -, , , , .

, , - 80 443, , , . , Tor. - , . , , .

, - IRC- IP-.

, My Little Pony, IRC-, , , , – . , IP-, , IP- . Tor .



IP- ? , IP ? No , IP, . , IP-, .
IP- , , , , , , Tor -.

. - «» ? , IP, , IP IP-. , , IP-.

, , , , . – « ». , , , , , IRC – , , , .

, . , . , , , - IP, .

- . , 2013 , « 2» , Silk Road. « 2» , Tor, , , .

, - , OPSEC – . , , . Tor , .

, , , , , « ». : «, , . , , . , , — ». , , .

54:00

Curso MIT "Seguridad de sistemas informáticos". 19: « », 3 ( Tor)


.

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 veces más barato? Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los EE. UU. Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?