[ml] Post Conclusivo (Xorro Chat)

Salve a tutta la ML,
quanto segue è un riassunto conclusivo di ciò che è emerso (in alcuni
casi anche in maniera poco gentile), in compenso alcune osservazioni
sono state ugualmente molto utili e fondate, e poi il bello della
crittografia è che incendia davvero gli animi :-)
Ad ogni modo sono state ugualmente sollevate FALSE obiezioni e GIUSTE
osservazioni e grazie a quest'ultime adesso ci daremo da fare per
sistemare quello che c'è da sistemare.

Devo fare però ancora alcune premesse nelle quali cercherò di essere il
più sintetico possibile anche a scapito della forma espositiva per non
annoiarvi oltremodo.


PREMESSE ########   (sez 1 di 3)

1) Perchè è nato Xorro ?
Io ero in una lan aziendale strablindata (niente SSL su nessuna porta in
barba al curriculum di qualsiasi ingegnere qui presente che abbia i suoi
dogmi di fede a riguardo, solo protocollo HTTP su porta 80, qualsiasi
sito con porta diversa dalla 80 e protocollo diverso da HTTP non andava)

 A riguardo ecco una cosa che tornerà utile a tutta la ML e che gli
esperti i sikurezza non dicono, anzi preferiscono negare che SSL possa
essere bloccato, bastano queste 3 semplici regolette nel file .conf di
SQUID per blokkare qualsiasi connessione SSL verso qualsiasi porta si
provi ad effettuarle:

 acl CONNECT method CONNECT
 acl All_ports port 1-65535
 http_access deny CONNECT All_ports


e volevo parlare con Formichiere di quanto fosse stupido l'admin :-D
evitando che sia l'admin della LAN sia il server del programma di chat
potesse leggere il mio testo. così per gioco.. mese dopo mese abbiamo
pensato a cosa poter fare.


2) Non facciamo confusione tra protocollo Xorro e HTTP.
E' errato dire "Xorro è una ciofeca" perchè se vai su bugtraq escono
tante di quelle vulnerabilità se scrivi "http server" .... (parimenti
uno potrebbe dire che SSL è stato patchato tante di quelle volte negli
ultimi anni...) Un client Xorro è per così dire un interprete di una
sintassi prestabilita. Il server è un qualsiasi HTTP server che può far
girare dei php. Non sono previste/consentite connessioni dirette tra un
client e l'altro. Quindi nessun client Xorro apre una porta 80 facendo
da WebServer. I php del server smistano solo delle richieste HTTP GET
fatte dai client Xorro mostrando l'output solo a dei client Xorro che
sono autenticati.


3) Volevamo procedere nel modo più semplice possibile in primis perchè
parafrasando Ford... "tutto quello che non c'è non ha BUG", e inoltre
perchè siamo ben consci che INVENTARE qualcosa di nuovo è una cosa
estremamente difficile e ci avrebbe preso molto più tempo di quello che
abbiamo deciso di destinare al progetto.


4) Perchè non abbiamo usato JABBER con SSL ?
Per due motivi:
a) SSL è bloccato in quella particolare LAN (e credo in tante altre).
Non è impossibile bloccare SSL come qualcuno afferma qui e mi stupisco
che nessuno intervenga per ribadirlo. Ho postato un esempio di Squid
che non è stato preso in considerazione da nessuno.
b) perchè JABBER non consente una cifratura END-2-END. utilizzando SSL
se io scrivo "ciao" a formichiere, "ciao" viaggia "protetto fino al
server che lo legge in chiaro e me lo reinvia protetto.

Qui c'è la prova (per chi è abituato a fidarsi dei bei curriculum  ;-)

http://arch.jabber.com/archives/2004/04/000096.html

(si certo si può ovviare,a tutto si può ovviare, ma mi pare di capire
che le soluzioni a questo problema siano a pagamento)

xorro non si paga e grazie ad eventuali e futuri contributi non è
escluso che appena raggiungerà un livello decentemente comprovato
possa eesere rilasciato open source.

Dunque questa soluzione non era soddisfacente.

La motivazione A e B è valida anche per IRC tramite CGI su SSL
irc non consente neanche la ricezione di messaggi offline a dirla
tutta... non si mette nel systray, non consente avatar, suoni e cose
carine a guardare ancora più attentamente. Anche l'occhio vuole la sua
parte no ?



OBIEZIONI ERRATE ########   (sez 2 di 3)

Ne sono state fatte tante e forse alcune sono dovute anche alla fretta
con cui abbiamo scritto le specifiche (che sicuramente non sono state
afferrate al volo da chiunque abbia provato a leggerle) riporto solo le
più vistose:


>  sinceramente non ho capito perchè dovrei usare xorro chat invece di,
>  ad esempio, irc in ssl con registrazione del nickname. è una domanda
>  seria, non una polemica.

seriamente la mia risposta è inclusa nelle motivazioni A e B di cui sopra.



>  non rinventiamo costantemente la routa!
>
>  Ovvero ci sono bellissimo algoritimi per criptare scritti da persone
>  hanno dedicato la vista allo studio della crittografia.


Io immagino che anche queste persone all'inizio credevano di reinventare
costantemente la ruota eppure.... Il fatto che ci sia già un protocollo
affermato per cifrare tra Client e Server non vieta di studiare qualche
altra soluzione "birichina" per coprire degli aspetti non previsti da
SSL. (leggasi opzioni A e B di cui sopra)





2)
>  1. da sistemista di rete mi chiedo che senso abbia costruire software
>  che "buchi" i firewall?

spirito di avventura, voglia di esplorare nuove possibilità di
comunicazione e se leggi le premesse anche quella di SFIDARE un Admin di
rete Antipatico ;-)

>  Se mi vedo transitare su porta 80 un protocollo che non è HTTP lo
>  droppo subito, perché posso pensare che sia qualsiasi cosa compreso
>  tra un attacco e/o un worm/virus.

Come nelle premesse... Xorro è semplicemente un client che fa delle
richieste GET ad un php e ne interpreta i valori. non è esclusa una
futura organizzazione delle risposte del php in XML.

>  La regola proposta da Stefano mi sembra ottima con un sistema di
>  snort/inline, ma qualsiasi apparato che è in grado di fare protocol
>  analysis ti droppa subito il tuo software.

Sinceramente questo è un aspetto che non conoscevo (mea culpa). nei
pacchetti TCP c'è scritta la provenienza dell'app ? (es. xorro.exe ?)

considera anche che "|OK" è la prima cosa che domani cambieremo  nelle
risposte del php ;-)

>  Ogni buon protocollo dovrebbe avere una sua porta. (non a caso esiste
>  un ente che gestisce queste cose).

Infatti HTTP usa la porta 80 e Xorro usa HTTP.

>  in una rete seria, se sono implementate le VLAN,

Parti dal presupposto che l'admin di rete sia un amico. è tutto diverso
quando invece ti sta sulle scatole e la cosa è reciproca :-D

>  Ok, andate dal sistemista di rete e concordate con lui una porta UDP
>  attraverso cui far passare il tunnel VPN creato dal suddetto
>  software. Io credo che nessuno vi farà storie senza prima avervi
>  chiesto cosa ci dovete far passare dentro.

Così non è stato e credo che non sia capitato solo a me nel mondo !!! A
voi altri non è mai capitato ????


>  non ho ancora capito cosa deve fare di più di un qualsiasi programma
>  IM che già esiste.

Funzionare senza chiedere il permesso a nessuno. jabber su SSL e IRC
over CGI & SSL non vanno bene per i motivi di cui sopra... oltre al
fatto che Xorro potrebbe essere riconosciuto come un "esercizio di stile".

>  rilasciando i sorgenti non ci si riesce più a concentrare sulla
>  sicurezza? e io che pensavo il contrario :)

Questa non è errata... è vera :-D
Il punto è che nei commenti dei sorgenti ci sono tante di quelle
bestemmie e maledizioni che mi pare brutto metterli online :-) , inoltre
spesso e volentieri modifico i sorgenti più volte al giorno...
Metterli online ogni volta non mi pare possibile. Questa decisione sarà
presa quando i sorgenti saranno "maturi".


> > nessuno che sa tornare indietro da una stringa MD5 alla password da
> > cui la stringa è stata generata?
>  Hmm.... a parte la risposta banale (http://www.openwall.com/john/)
>  direi che con poco sforzo si può adattare il sistema a rainbow tables
>  per MD5 unsalted (per la versione salted usata nello shadow ci hanno
>  già pensato...) e a questo punto basta solo un po' di spazio su disco
>  e una macchina che adesso oscilla sui 350 euro per fare del cracking
>  efficiente


Una macchina da 350 euro ci mette un bel po' per craccare un hash MD5 di
una password di oltre 20 caratteri. mi sa che neanche i tuoi pronipoti
farebbero in tempo a vedere il risultato. Inoltre Poichè Xorro è
destinato ad una fascia di utenti "smanettoni" si presume che
l'impostare delle password lunghe sia una cosa assodata.
 Oltretutto su passcracking vendevano tutti gli hash md5
di pass ALFANUMERICHE (lettere e numeri e non altro) fino a 8
caratteri... occupava 80gb il database. (dichiaravano).
Pertanto non è attualmente possibile craccare password md5 di circa
40-120 caratteri in pochi secondi (il tempo tra lo scambio di un md5 e
l'altro).

>  a filtrare un qualsiasi altro protocollo over HTTP non ci si mette
>  ne' uno ne' due...

parliamone:
>  drop tcp any 80 -> $HOME_NET any (content:"\|OK\|"; msg:"Xorro";)

questa cosa blocca ? una qualsiasi pagina HTTP con il testo "|OK"
presente all'interno ? Non mi pare una cosa furba sinceramente. Bloccare
arbitrariamente pagine utili agli utilizzatori del servizio http.
Oltretutto discutendone possiamo rendere pseudoRANDOM sia il testo OK
sia il | ("pipe").

Es.:
OK può essere una qualsiasi combinazioni di vocali, mentre KO può
essere una qualsiasi combinazioni di consonanti. Combinazioni
RANDOMIZZATE dal PHP. Oppure ancora meglio "OK" può essere un qualsiasi
TAG HTML utilizzatissimo tipo </body></html> o una stringa alfanumerca
con un numero di cifre random. Di certo non ci si può mettere a scrivere
regolette per bloccare "|00" o "$30agd" o "[02S3$r" e via verso
l'infinito e oltre :-P  Si rischia davvero di bloccare qualsiasi cosa
HTTP. Troviamo insieme tutti i punti bloccabili e riflettiamoci per
aggirarli no ? Ogni aiuto è ben accetto !!!






GIUSTE OSSERVAZIONI ########   (sez 3 di 3) complimenti se sei arrivato
sino a qui


I VERI problemi riscontrati con Xorro sono questi:

1) Filtrando tutti i contenuti con all'interno "|OK" si blocca l'uso del
programma, lo risolveremo così come detto sopra


2) La STR1 è inviata in chiaro in fase di registrazione. (ovviamente
prevedendo di registrarsi in lan questo fattore è stato del tutto
trascurato/sottovalutato/ignorato ). Lo risolveremo implementando la
registrazione tramite HTTPS. Su www.xorro.org/registrati.php mettiamo
una pagina che chiede nome, cognome etc etc e fa scaricare il setup.ini
già bello pronto da dare in pasto al programma :-D
più semplice di così... W SSL quando ci semplifica la vita ;-)


3) Il client attualmente viene autenticato ma lo deve essere anche il
server, GIUSTO! Il client è immune da MITM ma il server no. Ipotizzando
che io e formichiere volessimo parlare attraverso un proxy messo a punto
dall'Ing Zanero, il server potrebbe sempre risponderci facendo da MITM
per quel che riguarda la STR2 (quindi ottenendo quella legittima dal
verso server) ma sostituendo il contenuto della contact list e facendo
ad esempio apparire tutti i contatti offline. Risolveremo utilizzando la
stessa tecnica utilizzata adesso nel client per impedire che un MITM
possa modificare i valori delle variabili GET inviate al server.
L'attuale tecnica si basa essenzialmente sulla segretezza di STR1.

Se io aggiungo una variabile get ($md5check) che è l'hash md5 di : STR1
+ $TutteVarHttpGet + Str2 il MITM non può modificare nulla senza che la
trasmissione sia resa invalida dal server.

Nell'output del server ci sarà quindi un hash md5 nella forma STR1 (che
è segreta da pagina https quindi con SSL) + testo inviato + str2 (appena
generata dal server). Questa è una mutua autenticazione ;-) perchè in
effetti consente al client di sapere che la risposta viene dal server
che è a conoscenza della STR1 e SOLO DA LUI.

Il fatto che il tutto si basi sulla segretezza della STR1 non mi pare
una debolezza perchè anche il pgp si basa su una chiave "privata". La
STR1 potrà ad ogni modo essere sempre cambiata/allungata/aggiornata
dall'interfaccia web SSL predisposta.

Su questo punto gradirei ulteriore conferme/smentite sulla bontà del
metodo utilizzato. a me pare privo di difetti in quanto se il testo
arriva e l'hash md5 combacia si può essere CERTI che non è stato
alterato. se il testo non arriva vuol dire che qualcuno mi ha staccato
il cavo di rete :-D




4) Non essendo attualmente un vero Vernam, aggiungeremo a breve la
possibilità di utilizzare un keyfile di qualsiasi dimensione come
cifrario usa e getta per entrambi gli interlocutori, sarà poi l'utente
ad aver cura di utilizzare keyfiles decenti. Ovviamente questo keyfile
dovrà avere un contenuto di entropia altissima per essere un vero VERNAM
dico bene? Però siccome IMHO nel mondo digitale non esiste la Casualità
intesa nel suo concetto più astratto si accettano suggerimenti su come
procedere per generare tali files, così magari potremmo aggiungere a
Xorro un tool di generazione di Keyfiles il più possibile casuali.

Per lo scambio di tali files io preferirei sempre usare una bella
memoria USB durante l'impostazione della contact list ma anche fare una
zona in SSL nel sito xorro dove possono venire uppati e scaricati due
file dai rispettivi utenti della contact list non potrebbe essere una
idea assurda (forse un po' ridondante questo si). Ma il problema di
fondo è che se uno ha SSL potrebbe non avere bisogno di usare Xorro.
se uno non ce l'ha si registra dove SSL è possibile e si scambia i
keyfiles
file sempre via web o via memorystick.

Con queste modifiche direi che lo scopo del programma si conclude.


Scopo del programma ########   (sez 4 di 3) si è una sezione Bonus :-D

Chattare in riservatezza ovunque non sia possibile una connessione SSL
(ma sia attiva una connessione HTTP) mantenendo tutte le tipiche
funzionalità di un programma di instant messaging e implementando una
protezione al testo END-2-END.
Il server non deve poter vedere il testo smistato





grazie a tutti per gli spunti e le riflessioni tecniche scaturite.


MultiTasking & Formichiere.


ps.
in relazione all'ultima email di chi ci "accusa" amichevolemente di
difendere il nostro lavoro a spada tratta... spero che sia chiaro che
TUTTE le critiche sono state ben accette ed infatti sono servite per
farci capire come procedere. Gli "insulti" però oltre ad essere mal
sopportati, provengono spesso anche da gente che non ha il curriculum
del Ing. Zanero. ;-)



--
< :-O >
I believe that every right implies a responsibility; every
opportunity, an obligation; every possession, a duty.
< /:-O >