Messaggio originale di Putro nella mailng-list cyber-rights@ecn.org:

 

:Possibile che i remailer siano tutti cosė inaffidabili?

La cosa comunque mi lascia perplesso, soprattutto dopo aver letto un msg che e' girato in alt.privacy.anon-server qualche settimana fa, che pur avendo dei toni anche un po' troppo "paranoidi", e' interessante, per cui posto qui una traduzione che ne ho fatto alla buona e che soprattutto nella prima parte mi sembra offra qualche spunto di riflessione: L'autore del messaggio e' colui che ha scritto software quali Potato e JBN, ossia 2 dei piu' quotati client per remailer e nym al momento disponibili per DOS e Win, nonche' di un remailer (server) che gira sotto Win (Reliable).

--
ciao putro


Quella che segue e' una discussione di quelle che io considero essere alcune delle vulnerabilita' dei remailer cypherpunk e mixmaster, e di come penso queste vengano sfruttate.

COSA HO OSSERVATO

recentmente, ho osservato la stessa cosa che molti utenti hanno notato, la perdita di mail. Alcune mail spedite attraverso i remailers spariscono. Questo era stato spiegato in termini di software/hardware/reti non affidabili, comunque trovo queste spiegazioni insufficienti per spiegare le mie osservazioni.

Uno degli scopi per cui ho scritto Potato (e similmente JBN), era fornire un client per i remailer che fosse preciso e affidabile, e che quindi fornisse un modo per produrre mail formattate in modo compatibile col formato richiesto dai remailer. Permettendo all'utente di salvare modelli della costruzione dei messaggi, questo consente la rimozione di parecchi errori umani. Fornisce anche una memoria artificiale per cui un utente puo' verificare se un messaggio andato perso e' stato costruito nel modo giusto.

Allo stesso modo, Reliable (come il nome stesso suggerisce) era stato progettato per fare tutto cio' che era possibile per eliminare la perdita di messaggi. Reliable e' molto riluttante a scaricare i messaggi, e ha molti strati di messaggi disponibili, con la possibilita' di rimettere in coda messaggi non processati per problemi di configurazione o altro. In piu', i remailer Freedom e Mixmaster hanno subito parecchie revisioni da parte di J.Kroeger e U.Moller che credo li hanno resi molto piu' affidabili (e sicuri) rispetto ai remailer disponibili qualche anno fa.

Come risultato di questi miglioramenti noi abbiamo clients e servers che girano costantemente e con un ampio grado di affidabilita'. E allora perche' e' cosi' difficile generare un reply-block sicuro e affidabile ?

Alcune delle mie osservazioni:

Alcune mail spariscono, in modo particolare se "uniche" (non mandate attraverso un reply-block criptato precedentemente costruito.

Le mail che sono criptate in modo sicuro tendono a sparire o a essere ritardate piu' dei messaggi semplici.

Le mail che sono bene inserite in un reply block spariscono piu' facilmente, anche ammettendo l'aumentata probabilita' di errori seriali e altre cause, perfino quando tutti i remailer nella catena testata funzionano bene.

I messaggi di ping sono piu' affidabili della posta vera. La nuova versione 2 delle statistiche rivela che molti remailer sono costanti e affidabili nel processare i ping, e i server down sono un evento abbastanza raro. Eppure l'uso dei remailer in catena traccia una situazione molto diversa da quella rilevata da queste statistiche

Reply-block gia' utilizzati in precedenza possono lavorare senza difetti, mentre un reply-block nuovo con gli stessi remailers sara' ritardato o perso. Le catene nuove contenute nei reply block sono ritardate le prime volte che le si usa.

C'e' una corrispondenza tra nym account e inaffidabilita' dei nuovi reply-block (ad es. un nuovo reply block per xxx@nym.alias.net sara' consistentemente meno affidabile dello stesso o simile reply-block per yyy@nym.alias.net)

Gli operatori dei remailer si lamentano del fatto che le loro statistiche sono basse malgrado il loro remailer funziona normalmente.

Il passaggio di messaggi destinati ai newsgroup tra i server e' impedito oltre le aspettative.

Incidenti isolati possono essere visti come coincidenze, dovute al livello del traffico, e altre variazioni, ma passa il tempo e questa tendenza diviene sempre piu' chiara e fastidiosa, e le ragioni diminuiscono. Io penso che molti utilizzatori di remailer e nym server sono a conoscenza di questa situazione, al punto che la prendono come scontata, e io penso che qualcuno che lavora per fornire i servizi di remailing o il software ignora il problema semplicemente perche' non usa questi servizi in modo intensivo.

Penso che esistano tre possibilita' per spiegare questa inaffidabilita':

1) Software dei remailer inaffidabili (i server scaricano i messaggi a dispetto della destinazione e i client generano messaggi malformattati).

2) Reti inaffidabili che non distribuiscono i messaggi

3) Una terza influenza, deliberata o meno, che previene la distribuzione o il processing dei messaggi.

Ho gia' risposto alle mie domande riguardo il punto 1)
Mentre ammetto che i problemi per il software esistono, non sono cosi' diffusi da dover causare questa grossa perdita di mail in modo imprevedibile, e senza cause riconoscibili e riproducibili.

Riguardo la seconda possibilita', l'affidabilita' di internet e' aumentata. Quanto spesso le normali e-mail spariscono in un buco nero ? Raramente. E nemmeno questo spiega la natura "intelligente" delle perdite che io ho osservato.

Pur tentendo di resistere all'alternativa paranoica, sono giunto alla conclusione che la terza possibilita' e' quella piu' esatta - che qualcosa o qualcuno sta interferendo tra gli utenti e i remailer, e tra i remailers, mettendo in atto una forma molto sottile e selettiva di attacchi basati su Denial of Service.

DoS selettivi:

DoS si riferisce a Denial of Service. Un tipo di attacco su comunicazioni sicure o criptate implica il sabotaggio della comunicazione, o la negazione del servizio. Un esempio e' una mail bomb inviata a un remailer. Mentre recupera dal mail bomb il remailer e' impossibilitato a processare messaggi, e quindi agli utenti e' negato il servizio, non sono in grado di comunicare.

Per DoS selettivi mi riferisco all'abilita' di inibire o fermare alcuni tipi di messaggi trascurando gli altri. Se fatto con cura, e forse in congiunzione con chiavi compromesse, questo puo' essere usato per inibire l'uso di alcuni tipi di servizi promuovendo al contempo l'uso di altri. Un esempio:

L'utente X prova a creare un account nym usando i remailer A e B. Non funziona. Lui ricrea il suo account usando i remailer A e C. Questo funziona cosi' lui lo usa. Quindi lui ha scelto il remailer C e ha scartato il remailer B. Se l'attaccante gestisce i remailer A e C, o ha le chiavi di questi remailer, ma non e' in grado di compromettere B, puo' indurre l'utente a usare A e C sabotando i messaggi di B. Puo' fare questo gestendo il remailer A in modo che rifiuti certi tipi di messaggi in catena indirizzati a B, o puo' fare questo esternamente interrompendo le connessioni a B.

L'utente Y prova a creare un reply-block molto sicuro usando funzioni avanzati anti-tracciamento (magari lunga latenza, salti random, buona criptazione etc.). Il suo reply block non funziona affatto oppure e' cosi' inaffidabile che lui decide di non usarlo e lo cambia. Si dimentica di alcune delle funzioni avanzate per un reply- block piu' affidabile (e meno sicuro). Quindi l'attaccante ha indotto l'utente a usare funzioni meno sicure, o forse l'ha completamente scoraggiato dall'usare i remailer.

L'utente Z prova a creare un reply-block, o a mandare un messaggio. Ancora e ancora fallisce, cosi' si manda un messaggio di test usando gli stessi remailer, oppure se e' inesperto se lo manda direttamente al suo account. Inibendo la consegna del messaggio, l'attaccante ha fatto in modo che l'utente si esponga con test, ripetizioni e mancanze in termini di sicurezza.

Un'altro esempio: e' possibile dire quanto e' lungo un reply-block esaminando la dimensione del reply-block criptato. Quindi l'attaccante elimina alcuni o tutti i messaggi con catene lunghe, riducendo il loro uso.

Quindi attraverso DoS selettivi, si puo' ottenere:

una scelta di remailer influenzata
una scelta di funzioni dei remailer influenzata
necessita' di test e ripetizioni
inibizione delle catene lunghe
generale dissuasione dell'uso dei remailer dovuto a imprevedibilita'

CREDIBILITA'

Quanto e' credibile lo scenario che qualcuno stia facendo questo ? Penso che le organizzazioni piu' plausibilmente responsabili per un attacco di questo tipo sono le solite sospette - NSA, CIA, e le altre organizzazioni militari e di intelligence.

Loro hanno i mezzi e i motivi per far si' che valga la pena di effettuare questo tipo di attacco. Date operazioni come Echelon (diffusa intercettazione delle comunicazioni elettroniche in europa da parte dell'NSA), e altre reti di spionaggio come la CIA che hanno l'abitudine di mettere il naso dappertutto, e' ragionevole assumere che loro stanno facendo "qualcosa" nei riguardi dei remailer. I remailer potenzialmente permettono ad organizzazioni di comunicare in modo non tracciabile in tutto il mondo. Parecchio spionaggio e controspionaggio e' basato sull'interruzione di comunicazioni non tracciabili. Quindi e' ragionevole desumere che loro stanno facendo qualcosa.

Cosa e' probabile che stiano facendo ? Conoscendo le loro abitudini, e' probabile che vorrebbero fare qualcosa nel modo piu' sottile possibile. Preferirebbero che le loro intrusioni siano non rilevabili e non verificabili, senza tracce lasciate dietro di se. Preferirebbero lasciare l'illusione che il sistema non e' stato compromesso.

IL BUCO

Il buco nell'affidabilita' dei sistemi dei remailer fornisce un modo, forse il migliore, per ottenere questi scopi. Un messaggio perso fornisce solo l'evidenza della sua assenza, cosi' che non c'e' nessuna evidenza di terze parti al lavoro. Fornisce un modo per influenzare l'uso dei remailer, e usa altri autentici problemi dei remailer come copertura. Utilizza anche la difficolta' di produrre manualmente messaggi ben formattati destinati ai remailer come copertura, sebbene questo sia diventato un problema minore con la comparsa dei moderni clients.

Da quando esistono i remailer, l'inaffidabilita' e' stata un problema. Inoltre, da quando i remailer sono diventati piu' affidabili, l'affidabilita' delle catene ha iniziato a mostrare deficienze inesplicabili. Prendiamo la lista delle statistiche come scontata, ma perche' abbiamo bisogno di un punto di riferimento cosi' elaborato ? Perche' i problemi dei software e delle reti sono rimasti cosi' a lungo ? O lo sono ancora ? Dopo ampie analisi, vedo poche evidenze che siamo i problemi di software o reti a causare queste perdite, e l'unica spiegazione alternativa che resta e' l'interferenza deliberata.

Penso che gli utenti dei remailer e gli sviluppatori sono diventati compiacenti verso i problemi dell'affidabilita', accettandoli, e quindi accettando una grande vulnerabilita' nel sistema. Ma e' comprensibile, perche' e' un problema molto difficile da indicare con precisione e documentare.

COSA NON ABBIAMO OSSERVATO

Quali sono le alternative a un attacco DoS selettivo ?

Non diro' che queste cose non esistono o non sono state fatte, ma non ho osservato quanto segue, direttamente o indirettamente.

- Un attacco DoS non selettivo

- Un remailer o gruppi di remailer completamente spenti o bloccati

- Chiavi false - Distribuzione di chiavi false e false firme potrebbero essere usate in un attacco di tipo man-in-the-middle o altri attacchi, ma ancora questo lascia possibili evidenze che qualcuno ha compromesso il sistema o ha tentato di farlo.

- Attacchi di hacking - Ci sono poche evidenze che indicano un attacco di hacking coordinato.

- Trojan virus - Un software impiantato che puo' rubare chiavi o altrimenti danneggiare il sistema e' plausibile. Queste cose succedono nell'ambito del software piu' classico, ma non sono mai stato testimone di questi problemi legati direttamente o meno ai remailer. Da notare ancora che questi lasciano tracce.

ALTRI ATTACCHI

Ovviamente continueranno ad esserci altre vulnerabilita'. Chiunque puo' far girare un remailer, e logicamente un metodo per intercettare alcune mail, e cancellarle in modo selettivo, sarebbe per l'attaccante l'amministrare uno o piu' remailer.

C'e' anche l'argomento del furto delle chiavi. Basandomi su quello che ho osservato, credo ci sia una forte possibilita' che almeno qualche chiave e' disponibile per chi esegue quello che io sospetto essere un DoS selettivo. Dato che la locazione di nym.alias.net, al MIT, e' un computer universitario con una sicurezza solo accettabile, e dato che la chiave non e' stata cambiata da anni, posso trovare ragionevole supporre che la chiave e' stata rubata (copiata).

[...]

Trovo plausibile che le agenzie di spionaggio costruiscano una campagna per riportare e generare abusi, causando la chiusura dei remailer da parte degli ISP, etc., e generando mail bombs e altri attacchi quando utili ai loro scopi. Questo e' in generale accordo con la storia dei loro coinvolgimenti indiretti.

PERCHE' ESSERE PREOCCUPATI ?

[...]

Io credo che l'ipotesi della cospirazione sia delicata, ma nel caso dei remailer penso che si possa assumere con sicurezza che le agenzie di spionaggio sono implicate in qualche modo. L'unica domanda che resta da porsi e' come.

COSA POSSIAMO FARE:

Vorrei elencare diverse idee a breve e lungo termine per come i remailer possono essere migliorati e resi meno vulnerabili ad attacchi di tipo DoS o altri.

1) AFFIDABILITA'

Software o connessioni di rete inaffidabili forniscono una copertura per attacchi vari e DoS selettivi. I programmatori di remailer e client, nonche' gli operatori dei remailer, devono fare tutto il possibile per migliorare l'affidabilita' dei loro sistemi e ridurre la posta persa, e per assicurare il collegamento con gli altri remailer. Le giuste chiavi devono essere usate dai remiler che sempre piu' dipendono da repgp e remix. E' mia opinione che le funzioni anti- spam in alcuni remailer sono andate fuori controllo e contribuiscono alla perdita di messaggi, quindi queste funzioni devono essere applicate con cura e solo se necessarie. I remailer devono fornire chiaramente informazioni all'operatore sul perche' la posta e' stata scartata, e gli operatori devono stare attenti a queste informazioni. Sopratutto, chiunque sia coinvolto nel fornire servizi di remailing (programmatori, operatori etc.), deve diventare meno compiacente riguardo l'invulnerabilita'. E' un problema significativo e una minaccia per la sicurezza.

2) CHIAVI

L'abitudine di tenere sempre la stessa chiave per un remailer a tempo indefinito rappresenta una minaccia per la sicurezza. Le chiavi dovrebbero essere rimpiazzate e distrutte regolarmente, specialmente per i remailer localizzati in posti istituzionali o altre zone dove la gente va e viene. Chiavi piu' grandi dovrebbero anche essere usate quando possibile.

3) REMIX ai NYM-SERVERS

I remailer posti nei nym server devono supportare il Remix-To. Troppe informazioni circa la dimensione del reply-block sono visibili tra il nym-server cypherpunk e il primo remailer.

LA PROSSIMA GENERAZIONE

Poche parole su quello che dovrebbe essere l'indirizzo della prossima generazione di remailer.

L'idea di mandare messaggi individualmente tra remailer (e anche da/per individui ?) dovrebbe essere scartata. I pacchetti dei messaggi dovrebbero essere resi piu' piccoli (1k magari) o piu' grandi (digest da 2-10Mb) e costruiti in mnodo che sia impossibile rimuovere un pacchetto o messaggio senza rilevamento e correzione. Messaggi multipli per una destinazione finale potrebbero essere mandati in digest.

Un sistema automatico per rilevare e rimpiazzare, possibilmente con un re-routing, i pacchetti persi dovrebbe essere implementato.

Piu' dati random (ininterrotti se possibile) dovrebbero essere introdotti per coprire il numero e la dimensione dei messaggi. L'assunto che un'attaccante abbia la chiave segreta di un remailer o e' in grado di decriptare i suoi messaggi dovrebbe essere usato per costruire un modello che, sebbene non prevenga alcuni "origliamenti" in alcune circostanze, prevenga i DoS selettivi.

L'email come modo preferito di trasferimento tra i remailer dovrebbe essee discussa. Sebbene fornisce una alta interoperabilita' tra diverse piattaforme, una connessione diretta tra i remailer, con rilevamento di errore e correzione e' richiesta.

I client dei remailer devono avere la possibilita' (opzionale) di connettersi al remailer direttamente, senza passare attraverso SMTP e altri server, e devono ricevere l'immediato feedback riguardo l'accettazione dei dati da parte del remailer. E' necessario un metodo sicuro e automatizzato per distribuire e cambiare le chiavi dei remailer regolarmente, e un sistema per aggiornare la configurazione dei client (basato sulle funzioni supportare dai remailer).

I remailer devono essere meno dipendenti dai sistemi di DNS per prevenire dirottamenti ed estesi tempi di down (come quando nym.alias.net ha perso il suo dominio per mesi).

IN CHIUSURA

Non intendo insinuare che tutte le mail perse siano imputabili ad un coinvolgimento di terze parti. Specialmente se sei inesperto dei remailer, renditi conto che ci sono molti errori che possono legittimamente causare lo scarico del messaggio da parte dei remailer.

Voglio anche aggiungere che considero ancora gli anonymous remailer uno dei pochi metodi sulla rete per avere alti livelli di anonimato e sicurezza. E proprio per questo che considero plausibile che siano il bersaglio di un attacco cosi' sottile e intensivo in termini di risorse.