C-toxcore: Documentar preguntas y respuestas relacionadas con criptografía y redes p2p

Estás equivocado. Los nodos de arranque DHT existen para facilitar la unión al DHT. Si desea una explicación más detallada, puede consultar este artículo: https://en.wikipedia.org/wiki/Distributed_hash_table. Alternativamente, puede unirse a nosotros en IRC, en el canal #tox en Freenode, e intentaremos explicar las cosas lo mejor que podamos.

Su tráfico puede pasar a través de nodos de arranque que actúan como relés TCP mientras que tox usa TCP para la conexión de amigos. Es similar a TURN . Su tráfico aún está encriptado de extremo a extremo, por lo que la confidencialidad y la autenticidad de sus mensajes nunca se ven comprometidas. Esta retransmisión de TCP es probablemente lo que vio en su análisis de tráfico. Se describe en detalle en la especificación del protocolo tox .

Es un tráfico de voz. Está encriptado y ahora los terceros no pueden descifrarlo, pero eso no significa que sea imposible en el futuro.

Tengo una dirección IPv4/IPv6 directa. ¿Por qué debo enviar mis datos a los nodos?
Usted dice: 'Existen nodos de arranque DHT para facilitar la unión al DHT', pero no es cierto. En la captura de pantalla adjunta, el tráfico pasa a través de nodos, no directamente a mí.

'Tox es un software fácil de usar que te conecta con amigos y familiares sin que nadie más escuche. ' - ¿Es mentira? Tráfico encriptado, ok. ¿Pero está usando nodos para entregar? No sé, quién mantuvo estos nodos. ¿Qué sucede si uno o más nodos son falsos?

Entiendo cómo este punto puede parecer incorrecto, por lo que presenté un problema de documentación para mejorar nuestra presentación de eso. Gracias por explicar tus pensamientos.

Para explicar rápidamente su preocupación específica, lo parafrasearé. Por favor, hágamelo saber si entendí mal:

P: _Me preocupa el hecho de que los paquetes de datos que provienen de mi computadora no se entregan directamente a la computadora de mi amigo, sino que a veces (o todo el tiempo, dependiendo de las condiciones de la red) se transmiten a través de computadoras de terceros._

R: Primero, considere un paquete que va directamente desde su computadora a la computadora de su amigo, asumiendo que está conectado a un wifi local:

• Su computadora crea un paquete Tox encriptado (consulte los detalles de encriptación ), que envuelve en un paquete UDP que contiene los puertos de origen/destino (aleatorio/33445), luego en un paquete IP que contiene las direcciones IP de origen/destino (usted y su amigo) , luego una trama inalámbrica que contiene las direcciones MAC de origen/destino (usted y los puntos de acceso).
• Esta trama inalámbrica se envía a través de un canal cifrado AES (suponiendo WPA2).
• El punto de acceso inalámbrico, así como cualquier otro usuario de la red, lo recibe. Otros usuarios normalmente ignoran el paquete, pero no tienen por qué hacerlo. La lectura de paquetes que no están destinados a usted se denomina sniffing. Este es el primer punto en el que otros pueden leer el paquete.
• El punto de acceso inalámbrico está conectado a un enrutador WAN (internet) que establece una conexión con los enrutadores de su proveedor de servicios de Internet a través de algún medio (acoplamiento acústico, RDSI, ADSL, Cable, Satélite, fibra, ...). Esta conexión se puede cifrar (algunos satélites), pero normalmente no lo es. En este punto, el enrutador WAN al que envió su paquete creará una trama Ethernet que contiene su propia dirección MAC y la dirección MAC del siguiente enrutador al que se conecta, que es su enrutador ISP. En tránsito, es probable que las direcciones IP y MAC no estén encriptadas y cualquiera que huela la fibra óptica entre usted y el ISP puede leerlas. Este es el segundo punto en el que otros pueden leer el paquete.
• Una vez que el paquete llega al ISP, pasará por varios sistemas internos en sus centros de datos, posiblemente encriptados o no encriptados en varios momentos. El enrutador ISP luego decidirá el próximo enrutador al que debe enviar el paquete, determinado por la dirección IP. Para hacer esto, desenvolverá la trama Ethernet que recibió, la envolverá en una nueva y la enviará al siguiente enrutador. En cualquier momento durante el procesamiento en el ISP, los empleados del centro de datos o de la administración del sistema de ese ISP pueden acceder a su paquete. Tercer punto de acceso.
• Ahora su paquete saltará de un enrutador a otro (pruebe traceroute $your_friend_ip para ver a dónde va), cada uno de los cuales tiene libre acceso a la trama de Ethernet, el paquete IP y el paquete UDP, así como a su contenido. Muchos puntos de acceso, llamémoslo el 4to.
• Entonces tu amigo puede estar en una situación similar, en un wifi local en un lugar diferente. Nuevamente, su enrutador y los miembros de la red inalámbrica pueden leer el paquete. Quinto punto de acceso.
• Solo que ahora, finalmente, tu paquete llega a la computadora de tu amigo. Recibe una trama inalámbrica, la desenvuelve para encontrar un paquete IP, la desenvuelve para encontrar un paquete UDP, la desenvuelve para encontrar un paquete Tox, que luego es procesado por la implementación del protocolo Tox. Este procesamiento implica descifrar y descodificar el paquete y actuar en consecuencia, lo que generalmente da como resultado que el cliente de su amigo muestre el mensaje, reproduzca audio o video, o realice alguna otra actividad a nivel de la aplicación.

Como puede ver, hay muchos puntos durante la transmisión "directa" de usted a su amigo donde el paquete puede ser inspeccionado por personas arbitrarias. El cifrado de extremo a extremo significa que en ningún momento entre usted y su amigo nadie puede leer el contenido real que pretendía transmitir. Siempre solo pueden ver los datos cifrados.

Ahora, agregar un relé TCP en el medio simplemente alargará la ruta (teóricamente podría acortarla, pero eso no es probable). Cualquiera que ejecute el repetidor puede leer el paquete, como cualquier otra persona entre usted y su amigo. El protocolo criptográfico Tox garantiza que su comunicación sea segura.

Ahora, también veo una segunda preocupación:

P: _¿Qué sucede si uno de los nodos que transmiten mis datos es malo?_
R: Tox selecciona una serie de relevos TCP que puede usar para comunicarse en caso de que las conexiones UDP directas no sean posibles (por ejemplo, debido a NAT o firewall). Los relevos malvados pueden hacer muy pocas cosas para hacer el mal:

• Pueden optar por no enviar el paquete. En este caso, Tox volverá a intentarlo a través de un relé diferente. Solo si todos los nodos de arranque son malos, fallará una transmisión.
• Pueden enviar un paquete modificado. Gracias a los códigos de autenticación de mensajes, es probable que se detecte cualquier alteración de los datos. Si el remitente logra manipular de una manera que no es detectada por el software, el paquete descifrado será basura y la capa de aplicación (el decodificador del protocolo Tox) lo descartará. Por lo tanto, esto tiene el mismo efecto que no retransmitir el paquete en absoluto.

Eso es básicamente todo. En ningún caso el relé malvado podrá leer tus datos. Solo puede optar por no retransmitir, y solo si todos los nodos de arranque son malos, no puede comunicarse. Esto sería bastante molesto y no estaríamos contentos por ello, pero la información de nadie se ve comprometida en ningún momento.

Espero que esto aclare algunas cosas. No he revisado esta respuesta, pero me aseguraré de que esté correctamente representada en el sitio web para referencia futura. Avíseme si tiene alguna otra inquietud. Gracias de nuevo por mencionar esto.

Acabo de leer tu mensaje nuevamente y descubrí que me perdí una preocupación más:

P: Aunque ahora los datos están cifrados, ¿qué garantiza que no se descifrarán en el futuro?
R: El protocolo Tox implementa el secreto directo perfecto mediante el uso de claves efímeras. Esto significa que si una de esas claves se ve comprometida, se pueden descifrar algunos mensajes, pero no todo su historial de comunicación. La parte de "algunos mensajes" de esta oración se reducirá a "un mensaje" en el futuro. Si su clave secreta a largo plazo se ve comprometida, no se puede descifrar ninguna comunicación pasada.

Si las primitivas criptográficas que usamos están rotas, perdemos. Depende de qué manera se rompan, estos son los peores escenarios posibles:

• El cifrado ( salsa20 ) se puede revertir fácilmente sin una clave. En este caso, toda la comunicación pasada se ve comprometida.
• La primitiva de intercambio de claves ( curve25519 ) se rompe de manera que la clave secreta se puede recuperar fácilmente a partir de una clave pública. En este caso, también se compromete toda la comunicación pasada.

Es muy poco probable que estos escenarios se hagan realidad en un futuro cercano, o posiblemente para siempre. Según la comprensión actual en la comunidad de criptografía, solo la computación cuántica podría hacer que suceda el segundo escenario. El primer escenario se cree que es imposible.

Dicho todo esto, también noté que dijiste que tienes una dirección IPv4 directa. ¿Qué significa esto? Si tiene una dirección IPv4 pública asignada a su computadora y el puerto 33445 está abierto, Tox debería establecer conexiones directas muy rápidamente. Si no es así, es un error y deberíamos trabajar juntos para averiguar por qué elige usar TCP en su lugar.

Muchas gracias por esta explicación. Ahora entiendo un poco más.
No estoy seguro acerca de la dirección IPv4 directa... Uso WireGuard VPN. WireGuard instalado en un servidor virtual, que tiene direcciones IPv4 e IPv6 directas. Todo el tráfico está envuelto en el espacio de nombres.
Información de la red de portátiles: https://gist.github.com/DebugReport/1268e15c3bd1c99b56929d645d99392b
Si me equivoque, lo siento.
Tal vez IPv4 no sea directo, pero ¿qué pasa con IPv6? ¿Puedo usar conexiones directas si otro cliente también tiene IPv6?

Sí, si ambas partes tienen IPv6 y la configuración del firewall no bloquea el puerto 33445 (o algún otro puerto cercano, algo entre 33445 y 33545), debería funcionar. ¿Tu amigo está en la misma VPN?

No.
Hmm... Pregunta. ¿Necesitamos usar nodos siempre? ¿O solo si uno de nosotros no tiene IP directa (¿solo IPv4?)?
Para IPv6 (yo) <-> IPv6 (amigo) ¿son necesarios los nodos? ¿Si es así por qué?

(Manteniendo este problema abierto hasta que todas estas preguntas se respondan en la documentación)

Si uno de ustedes tiene una IP pública, entonces el otro puede arrancar utilizando la IP y el puerto del otro. Esto requiere atención al cliente. No creo que ningún cliente tenga actualmente:

• Obtenga la clave pública DHT del cliente con IP pública y puerto abierto ( tox_self_get_dht_id ) y su puerto ( tox_self_get_udp_port ).
• Envíe esta clave al otro de alguna manera (dictar por teléfono o mensaje en Skype o algo así).
• El otro ahora necesita arrancar usando la tupla (key, ip, port) .

Después de esto, tiene una red Tox personal de 2 personas. Entonces, en teoría, no necesita ningún otro nodo. Sin embargo, facilitan las cosas.

Si uno de ustedes tiene una IP pública y un puerto abierto, conectarse a los nodos de arranque también debería permitirle establecer una conexión directa. Los nodos de arranque DHT tienen poco que ver con si puede conectarse o no. Una conexión directa debería ser posible incluso si solo uno de ustedes tiene una IP pública y un puerto abierto. El otro se conectaría a él, lo que crearía una ruta en el enrutador local y le daría al cliente un puerto público aleatorio temporal.

Solo una nota: noté el mismo comportamiento con C-Toxcore. Una de las partes está en un VPS con una dirección IP pública y sin firewall, la otra está detrás de NAT pero tiene el puerto Tox reenviado, por lo que deberían ser accesibles mutuamente. El tráfico aún se enrutaba a través de TCP.

No veo esto como un problema de seguridad, pero ciertamente es un problema de escalabilidad si una red P2P transmite todo su tráfico a través de retransmisiones.