Newsgroup: it.comp.sicurezza.pgp
Titolo: Remailer e nym

Buongiorno a tutti,
volevo sapere se qualcuno fra voi usa correntemente e con successo i
server nym. Io sono riuscito a crearmi due nym, ma me ne sono riusciti
solo due su venti! Il problema č la catena di remailer. Ho creato 20
nym, ciascuno con una catena di tre remailer. Bene (anzi, male) Su
venti catene, solo due hanno funzionato: gli altri remailer vanno a
corrente alternata e basta che uno salti per far saltare la catena di
tre. Neppure i due nym creati perň funzionano sempre. A volte uno dei
tre remailer della catena non va e cosě il mio nym non riceve o non
spedisce i messaggi. Possibile che i remailer siano tutti cosě
inaffidabili? La lista l'ho tratta da
http://www.neuropa.net/~gretchen/rlist.html
un sito ritenuto affidabile.
Ripeto: c'č qualcuno che possa dirmi che usa da tempo e senza problemi
i nym?
grazie
hyper2   
m...@hyperreal.art.pl
             #*#*#*+*####    17:07
100.00%
noisebox 
rema...@noisebox.dhs.org
        ****-*+**###    43:20
100.00%
replay   
rema...@replay.com
              #*--#*+*###*  1:51:00
100.00%
squat    
mixm...@squat.net
              ######*#####     4:42
100.00%
arick    
ar...@arickaree.scd.ucar.edu
     ++++++++**+*  1:23:35
98.24%
foebud   
rema...@foebud.org
              +**+**+++*+*  1:19:14
98.24%
frog     
fr...@mageos.com
                  ***#*#+*#***    17:03
98.24%
gondolin 
m...@remail.gondolin.org
          ***-+*+*****    50:43
98.24%
gretchen 
gret...@neuropa.net
             ****++++++**  1:49:44
98.24%
lobemix  
mixm...@lobeda.jena.thur.de
    *+**+*******    31:53
98.24%
cracker  
rema...@gacracker.org
           +-+++++*++*+  1:34:42
96.49%
fitugmix 
mixm...@fitug.de
               ++*+++****++  1:31:31
96.49%
squirrel 
m...@squirrel.owl.de
              +*+++++*++++  2:12:35
96.49%
exonet   
rema...@exonet.org
              ---+-+-+*+-*  3:25:11
94.73%
fnulnu   
fnu...@pobox.com
                 +------+++++  5:06:23
92.98%
widow    
wi...@wol.be
                     --++++++-..+ 10:16:11
92.98%

 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).
---------------------
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 
x...@nym.alias.net
 sara' 
consistentemente meno affidabile dello stesso o simile reply-block per 
y...@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 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 genereando 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.
-- 
ciao
              putro
PGP key (2.6.3i) available
http://www.geocities.com/SunsetStrip/7966/index.html
Relax 'zine, Putrocorpse and Kryptosexual Cancroid pages

spedisce i messaggi. Possibile che i remailer siano tutti cosě

To Reply Remove 123 - Per rispondere Togli 123
ICQ: 52254640

Ti volevo anche chiedere che sito mi consigli per aggiornare le
pubkeys dei remailers ? grazie



Ho mancato la lettura  del gruppo per un po' di giorni.
Grazie per le interessantissime informazioni.

pubkeys dei remailers ? grazie
Usa Edit/Update URLs e inserisci gli indirizzi per le statistiche e
per le chiavi aggiornate.
Allora su questo sito trovi le statistiche rilevate da piů di una
fonte, puoi quindi scegliere quella che preferisci e metterla in PI32
http://drule.org/remailer/stats.html
Come programma uso la versione di Private Idaho a 32 bit (non quella
di CATS, ma quella di Alex Cameron) che trovi qui
http://www.ecn.org/crypto/soft/pi32v3216.exe
ciao