In che modo Tor protegge contro un utente malintenzionato che esegue solo migliaia di nodi?

Tor fornisce privacy solo sotto il presupposto che almeno un nodo nella catena selezionata casualmente non sia controllato da un attacco (dal momento che stiamo parlando di analisi del traffico , semplicemente ascoltando il traffico che entra ed esce da questo nodo, senza tentare di decriptarlo, conta come" controllo "). Questo è probabilistico. Se l'attaccante controlla, ad esempio, il 50% di tutti i nodi e il browser utilizza una catena di lunghezza 5, l'attaccante vince con probabilità 0.5 ⁵ = 1/32.

Per mitigare tali attacchi, puoi configurare il tuo cliente per scegliere catene non uniformi, ma invece per imporre una "diffusione globale" in modo che la catena attraversi nodi in diversi paesi che non si apprezzano a vicenda.

Non è così, l'esecuzione di un gran numero di nodi è uno dei principali punti deboli di Tor. Il blocco consente di selezionare nodi specifici da utilizzare, ma è importante scegliere bene i nodi e cercare di evitare comportamenti anomali poiché un percorso indirizzato interamente attraverso i nodi collusi non è sicuro e ogni nodo colludere riduce la sicurezza effettiva di alcuni.

Ci sono sforzi per cercare di giudicare quali nodi si comportano bene in base a quanto tempo sono stati in giro, ma un attaccante paziente e abile potrebbe filtrare un sacco di nodi nel tempo pur essendo piuttosto difficile da rilevare.

Anche se l'intera catena di trasmissione non è compromessa, si può avere un certo grado di comprensione guardando i tempi dei pacchetti che entrano ed escono da un nodo. I ritardi sulle trasmissioni potrebbero aiutare, ma aumenterebbero la latenza e non sono attualmente supportati da Tor.

Are there any non-technical countermeasures, e.g. would someone intervene if 3000 new suspicious nodes would pop up on AWS?

Sì. Esistono sistemi e persone monitoraggio della rete, e la directory gli operatori dell'autorità bloccheranno le inondazioni di nuovi relè palesemente sospettosi. Ciò accade regolarmente, con discutibili progetti di ricerca accademici, insoliti generosi operatori di staffetta e altri attori nefandi .

In realtà, il tuo ipotetico scenario è accaduto quasi alla lettera nel dicembre 2014. Alcune persone sono andate e ha attivato 3300 relay sui server cloud di Google per una ragione o per l'altra. Non è successo niente. I relay sono stati bloccati ; non hanno quasi ricevuto traffico ; ed è difficile dire ciò che gli operatori stavano cercando di ottenere.

Il RELAY_EARLY attacco è probabilmente il peggiore esempio. Per la prima metà del 2014, un utente malintenzionato apparentemente americano accademico / governo ricercatori presso Carnegie Mellon University SEI CERT , unendo un centinaio di fast relay e un bug di sicurezza per deanonizzare gli utenti non raccontati, portando a migliosi arresti negli Stati Uniti e potenziali rischio da qualsiasi altra parte che registra il traffico al momento.

Oltre a eseguire migliaia di nodi, un utente malintenzionato dovrebbe eseguire quelle migliaia di nodi per un tempo lungo perché parte del processo decisionale su quali nodi utilizzare considera il peso consensus , che include il tempo di attività come fattore. Inoltre, vi sono dei flag che possono essere aggiunti ai nodi tramite i relè di livello più elevato (per consenso) che contrassegnano un relay come un relay difettoso, che influisce negativamente sull'utilizzo che otterrebbe.

La maggior parte delle protezioni di Tor contro questo tipo di attacco sarebbe correlata alle restrizioni su quanto deve essere vecchio un relay per ottenere una porzione considerevole di traffico.

Tutte queste risposte sono effettivamente errate, anche quelle più potenziate. Tor ha diverse caratteristiche specifiche che mitigano questo, chiamato attacco sybil. Mentre i relè centrale e di uscita sono in grado di cambiare ogni 10 minuti, il primo relè, la guardia, rimane con te per un tempo molto lungo. Ciò garantisce che, anche se un utente malintenzionato crea un numero elevato di relay, non sarà in grado di farti usare facilmente il relay.

Immagina che l'attaccante abbia la possibilità di controllare la tua guardia e il relè di uscita, e tale probabilità è determinata in base alla percentuale di relè che controllano. Preferiresti che abbiano una nuova possibilità di identificarti con una piccola probabilità di successo una volta ogni 10 minuti, o una volta all'anno? Quest'ultimo è il modo in cui Tor opera, nonostante tutta la disinformazione sopra.

link

Im un nuovo utente, e quindi non è possibile aggiungere questo come commento - ma è in risposta a user1535427

(come commentato da IceyEC per user1535427 post) Tor Utilizza 3 x hop in un circuito tra te e il server finale.

In alcune circostanze, userà di più, come quando ci si connette a un "servizio nascosto" o "Sito ionico", poiché questo utilizza 3 x hop tra di voi e quello che viene chiamato "punto di rendez-vous" (che è solo un altro nodo relay normale all'interno della rete Tor) più 3 x ulteriori saltelli dal "punto di rendez-vous" al server di destinazione finale.
Ma a parte questo, Tor è hardcoded per usare 3 x hop.

inizialmente, questo può sembrare contro-intuitivo - come ho pensato anch'io. tuttavia, esistono diversi motivi per mantenerlo a 3 x hop.
Alcuni di questi motivi (ma non limitati a) sono:

1 - l'aumento del numero di hop aggiunge latenza, che influisce negativamente sulla velocità e sull'usabilità e sull'esperienza utente.

2 - (tipo di seguito dalla ragione 1) Se l'aumento degli hop per tutti gli utenti rallenta le cose globalmente, ma potrebbe "potenzialmente" aggiungere ulteriori livelli di sicurezza, quindi, una risposta potrebbe non essere che Tor consente agli utenti di scegli quanti luppoli usano per creare il loro circuito a scapito di una latenza più elevata, se il particolare individuo considera accettabile il trade-off? Beh, in realtà no. Ciò significherebbe che diversi utenti avrebbero "lunghezze di percorso" differenti e quindi utilizzerebbero server come "un pezzo di informazione in più potenzialmente identificativo", ad esempio, forse sei l'unica persona che ha scelto di passare per dire 123 hop? se un utente malintenzionato può determinare il numero di hop, potrebbe essere in grado di identificare in modo univoco, o almeno di distinguerti dal traffico, da solo questo fattore.
In breve, aumentare il numero di hop per ogni circuito è negativo, e quindi è dare agli utenti la possibilità di variare il numero di hop stessi.

3 - che mi porta ad un altro motivo, apparentemente (e anche contro-intuitivo), i test hanno dimostrato che l'utilizzo di 4 o più luppoli nella pratica non offre in realtà più sicurezza di quanto si otterrebbe con il solo 3 x hop. Con il senno di poi, avere solo 3 offerte di luppolo, tecnicamente, garantisce la massima sicurezza e allo stesso tempo fornire le connessioni più veloci (il che è abbastanza semplice se ci pensi!)

la cosa importante da togliere è che:
- Finché un utente malintenzionato NON controlla ENTRAMBI i nodi "entrata" e "uscita",
- Oltre al tuo server finale che può essere sia un ".onion server" o "server web aperto con HTTPS"

allora sei relativamente sicuro. se l'attaccante conosce sia i nodi di entrata che quelli di uscita, il gioco è finito. sconfigge l'intero punto della rete Tor.

L'unico modo in cui questo può aiutare un utente malintenzionato è se hanno eseguito il nodo di trasmissione ogni e inoltre che erano sicuri di questo fatto. Il punto di forza di Tor è che un dato nodo non sa se il nodo al quale ritrasmette i dati è un altro nodo relay o l'utente finale. Non sono riuscito a trovare informazioni online se Tor utilizza un numero specificato di salti per connessione, perché se, ad esempio, un utente malintenzionato sapeva che Tor connette 5 nodi di relay tra un utente e un endpoint e l'attaccante ha visto 5 dei loro relay nodi in una catena, saprebbero l'IP dell'endpoint e dell'utente.

Per questo motivo, direi che Tor non usa un numero costante di salti.

Detto questo, se l'utente malintenzionato ha eseguito un nodo di uscita e l'hai usato per connettersi a un semplice sito di clearnet HTTP, sarebbe in grado di visualizzare tutti i dati inviati, anche se non è possibile visualizzare l'IP dell'utente.