Comunicazione TOR dall'uscita all'origine

Question

Comunicazione TOR dall'uscita all'origine

#1 da (2 voti)
#2 da (0 voti)

0

spero che questa domanda non sia mai stata posta in questo modo - ho visto qualcosa di simile ma non ho capito il processo. Quindi la mia domanda è riguardo alla comunicazione TOR: origine - > destinazione e destinazione - > origine.

Da quello che capisco quando io come fonte (diciamo IP ABCDE) mando un pacchetto su twitter (diciamo IP 12345) tramite la rete tor, mi collego a un punto di ingresso nella rete tor. Quando il pacchetto lascia il punto di ingresso ad un altro server Tor, l'origine del pacchetto (il mio IP ABCDE) è scomparsa, decrittografata o cancellata. I nodi tor conoscono solo il target (twitter) e instradano il pacchetto tramite le tabelle di connessione del nodo, dove solo il passo successivo e quello precedente nella catena sono noti a un nodo. Anche se non è completamente corretto, da quanto mi risulta Twitter riceverà un pacchetto con il contenuto che ho inviato, ma dall'IP del nodo di uscita tor (diciamo IP 67890). A questo punto, twitter non ha alcuna conoscenza dell'origine.

Ora ecco la domanda: se twitter (o per essere più precisi, il server twitter che invia la risposta al pacchetto) non conosce la destinazione, come finisce il pacchetto nel mio browser client? Ad un certo punto nella rete tor, l'origine reale (mio IP) deve essere memorizzata e, in caso affermativo, a quale punto è memorizzata? Perché se ciò è vero, quando ottengo l'accesso al punto di ingresso e posso vedere tutto il traffico di rete, dovrebbe essere possibile identificare l'origine e la destinazione di un pacchetto. Quale parte non comprendo (o non completamente), poiché devo trascurare qualcosa ....

Sarei felice di una spiegazione abbastanza semplice con un esempio, se possibile, dato che sono abbastanza nuovo rispetto all'argomento (penso piuttosto ovvio).

Modifica Ho letto questo thread , ma non risponde alla mia particolare domanda. Citazione:

The webserver sends the packet to the exit node, because the exit node was the computer that connected to the webserver. The exit node uses a table (seems like the NAT table, but with more information) to decide where to send the response. So it will encrypt the packet again, and send it to the next node, which will do the same, until the packet reaches your computer, are decrypted locally, and sent to the application.

Qui non è specificato dove è memorizzato il mittente originale del pacchetto (me) e come sono identificato all'interno della rete tor. Ho capito che la navigazione dall'uscita originale tor (ora entrata per Twitter) sa come tornare al punto di ingresso iniziale dove ho inviato il mio pacchetto. Ma come fa questo nodo a sapere che io sono il mittente originale? E se il nodo di ingresso ha queste informazioni, la rete tor non è facilmente compromessa dall'hacking nel nodo di entrata (se è "etichettato" come tale)?

encryption tor

posta stillprettynew101 29.08.2017 - 23:11

fonte

2 risposte

Leggi altre domande sui tag encryption tor

lato server Https, così come la crittografia client? Come testare l'attacco DoS inviando pacchetti ARP non richiesti su Ethernet?

score 2 · Answer 1

Ciò che stai chiedendo riguarda la conoscenza dei dettagli del design del protocollo TOR. Il Libro bianco Tor spiega tutto in dettaglio. Guarda alla sezione 4 (4.1-4.3) che contiene le parti del disegno relative ai circuiti e ai flussi.

Il riepilogo è che al di sotto del livello di TLS ci sono 512 celle di byte che descrivono come i router Tor parlano tra loro. Ci sono celle di controllo e celle di inoltro che sono disposte come segue:

Cella di controllo

+---------------------------------------------------------+
| CircID | CMD |                 DATA                     |
+---------------------------------------------------------+

Cellula relay

+---------------------------------------------------------+
| CircID | Relay | StreamID | Digest | Len |     DATA     |
+---------------------------------------------------------+

Questo è il modo in cui ogni pezzo di dati conosce il flusso e il relè a cui è associato, così come il circuito. Ogni router Tor manterrà probabilmente un certo tipo di "politiche Tor" per garantire che tengano traccia di questi circuiti, relè e ID di flusso. Proprio come ISAKMP / IPSec gestisce il suo traffico. Qualsiasi cosa Tor usi come demone sul router gestirà questa gestione.

score 0 · Answer 2

Il tuo computer ( ABCDE ) apre una connessione al nodo di ingresso tor ( node1 ) e invia la richiesta (crittografata).
node1 apre una connessione al secondo nodo ( node2 ) e passa la sua richiesta.
node2 apre una connessione al nodo di uscita ( 67890 ) e passa la richiesta.
Il nodo di uscita 67890 si connette a 12345 (twitter) e lo invia alla richiesta finale.

Twitter non conosce l'origine altro che provenga da 67890 . Inoltre, 67890 sa solo che proviene da node2 e è passato a 12345 . node2 sa solo che proviene da node1 e è passato a node2 . node1 sa che proviene da ABCDE e è stato passato a node1 .

Nota che nessuno di loro sa che ABCDE ha voluto comunicare con 12345 , conoscono solo il proprio luppolo. Per capire tutti i dettagli, i nodi dovrebbero essere collusi per deanonimizzare te (qualcosa che le agenzie governative probabilmente stanno facendo, btw).

La risposta scorre semplicemente lo stesso canale nella direzione opposta: 12345 → 67890 → node2 → node1 → ABCDE

Ci sono alcuni altri dettagli, in quanto i nodi effettivi selezionati per una data comunicazione sono scelti da ABCDE , e la connessione a ciascun nodo viene crittografata in modo che quelli intermedi non possano leggere il contenuto (che significa solo 67890 può visualizzare la destinazione finale). Ma il modo di determinare è così semplice. I nodi sanno con chi stanno comunicando (fino a che non finisce), quindi non ci sono problemi nel rinviare la risposta.