Richiedere a ogni utente Tor di essere un relay aiuterebbe a scalare la rete per gestire tutti i nostri utenti, e gestire un relay Tor può aiutare il vostro anonimato.
Tuttavia, molti utenti di Tor non possono essere dei buoni relay: ad esempio, alcuni client Tor operano dietro firewall restrittivi, si connettono via modem o non sono in grado di trasmettere il traffico.
Fornire un servizio a questi client è una parte critica della fornitura di un anonimato efficace per tutti, dal momento che molti utenti Tor sono soggetti a questi o simili vincoli e l'inclusione di questi client aumenta la dimensione dell'insieme di anonimato.
Detto questo, vogliamo incoraggiare gli utenti di Tor a gestire i relay, quindi quello che vogliamo fare è semplificare il processo di creazione e mantenimento di un relay.
Negli ultimi anni abbiamo fatto molti progressi per quanto riguarda la facilità di configurazione: Tor è bravo a rilevare automaticamente se è raggiungibile e quanta larghezza di banda può offrire.
Prima di poterlo fare, però, dobbiamo affrontare quattro fasi:
In primo luogo, dobbiamo ancora migliorare la stima automatica della giusta quantità di larghezza di banda da consentire.
Potrebbe essere che passare al trasporto UDP sia la risposta più semplice - che ahimè non è affatto una risposta semplice.
In secondo luogo, dobbiamo lavorare sulla scalabilità, sia della rete (come smettere di richiedere che tutti i relay Tor siano in grado di connettersi a tutti i relay Tor) che della directory (come smettere di richiedere che tutti gli utenti Tor conoscano tutti i relay Tor).
Cambiamenti come questo possono avere un grande impatto sull'anonimato potenziale e reale.
Si veda la Sezione 5 del documento Challenges per i dettagli.
Anche in questo caso, il trasporto UDP sarebbe utile.
In terzo luogo, dobbiamo comprendere meglio i rischi derivanti dal lasciare che l'aggressore invii il traffico attraverso il vostro relay mentre voi iniziate il vostro traffico anonimizzato.
Tre diversi ricerche descrivono modi per identificare i relay in un circuito facendo passare il traffico attraverso i relay candidati e cercando cali nel traffico mentre il circuito è attivo.
Questi attacchi di intasamento non sono così spaventosi nel contesto di Tor, a patto che i relay non siano mai anche client.
Ma se stiamo cercando di incoraggiare un maggior numero di client ad attivare anche la funzionalità di relè (sia come relè ponte che come relè normali), allora dobbiamo comprendere meglio questa minaccia e imparare a mitigarla.
In quarto luogo, potremmo aver bisogno di una sorta di schema di incentivi per incoraggiare le persone a inoltrare il traffico per altri e/o a diventare nodi di uscita.
Ecco i nostri pensieri attuali sugli incentivi di Tor.
Per favore, aiutatemi su tutti questi punti!
Sarebbe bello permettere agli operatori dei relay di dire cose come reject www.slashdot.org nelle loro politiche di uscita, piuttosto che richiedere loro di imparare tutto lo spazio degli indirizzi IP che potrebbero essere coperti dal sito (e quindi bloccare anche altri siti a quegli indirizzi IP).
Ci sono però due problemi.
Innanzitutto, gli utenti potrebbero comunque aggirare questi blocchi.
Ad esempio, si potrebbe richiedere l'indirizzo IP anziché l'hostname quando si esce dalla rete Tor.
Ciò significa che gli operatori dovrebbero comunque conoscere tutti gli indirizzi IP delle destinazioni in questione.
Il secondo problema è che permetterebbe agli aggressori remoti di censurare siti arbitrari.
Ad esempio, se un operatore Tor blocca www1.slashdot.org e poi un aggressore avvelena il DNS del relay Tor o cambia in altro modo l'hostname per risolverlo all'indirizzo IP di un importante sito di notizie, improvvisamente quel relay Tor blocca il sito di notizie.
Non ci si può fidare che sia la rete a scegliere il percorso.
I relay maligni potrebbero indirizzarvi attraverso i loro amici collusi.
In questo modo un avversario avrebbe la possibilità di osservare tutto il traffico da un capo all'altro.
Questo sarebbe utile per una serie di ragioni:
Renderebbe Tor più capace di gestire nuovi protocolli come il VoIP.
Potrebbe risolvere l'intera necessità di sockificare le applicazioni.
I relè di uscita non avrebbero bisogno di allocare molti descrittori di file per tutte le connessioni di uscita.
Stiamo andando in questa direzione. Alcuni dei problemi più difficili sono:
I pacchetti IP rivelano le caratteristiche del sistema operativo.
Avremmo ancora bisogno di normalizzare i pacchetti a livello IP, per bloccare attacchi come il TCP fingerprinting.
Data la diversità e la complessità degli stack TCP, insieme agli attacchi di fingerprinting dei dispositivi, sembra che la cosa migliore sia la spedizione di un proprio stack TCP per lo spazio utente.
I flussi a livello di applicazione devono ancora essere analizzati.
Avremo ancora bisogno di applicazioni lato utente come Torbutton.
Quindi non si tratterà solo di catturare i pacchetti e renderli anonimi a livello IP.
Alcuni protocolli continuano a far trapelare informazioni.
Per esempio, dobbiamo riscrivere le richieste DNS in modo che vengano consegnate a un server DNS non collegabile piuttosto che al server DNS dell'ISP dell'utente; quindi, dobbiamo comprendere i protocolli che stiamo trasportando.
DTLS (datagram TLS) non ha praticamente utenti, mentre IPsec è sicuramente grande.
Una volta scelto il meccanismo di trasporto, dobbiamo progettare un nuovo protocollo Tor end-to-end per evitare gli attacchi di tagging e altri potenziali problemi di anonimato e integrità, ora che sono consentite cadute, reinvio, eccetera.
I criteri di uscita per i pacchetti IP arbitrari significano costruire un sistema di rilevamento delle intrusioni (IDS) sicuro.
I nostri operatori di nodi ci dicono che le politiche di uscita sono una delle ragioni principali per cui sono disposti a utilizzare Tor.
L'aggiunta di un IDS per gestire le politiche di uscita aumenterebbe la complessità della sicurezza di Tor, e probabilmente non funzionerebbe comunque, come dimostrato dall'intero campo degli IDS e dei contro-IDS.
Molti potenziali problemi di abuso sono risolti dal fatto che Tor trasporta solo flussi TCP validi (al contrario di IP arbitrari che includono pacchetti malformati e IP flood).
Le politiche di uscita diventano ancora più importanti quando siamo in grado di trasportare pacchetti IP.
Abbiamo anche bisogno di descrivere in modo compatto le politiche di uscita nella directory Tor, in modo che i clienti possano prevedere quali nodi permetteranno ai loro pacchetti di uscire.
I client devono anche prevedere tutti i pacchetti che vorranno inviare in una sessione prima di scegliere il nodo di uscita!
Gli spazi dei nomi interni a Tor dovrebbero essere riprogettati.
Supportiamo gli indirizzi ".onion" dei servizi a cipolla intercettando gli indirizzi quando vengono passati al client Tor.
Fare ciò a livello IP richiederà un'interfaccia più complessa tra Tor e il resolver DNS locale.