Re: [ml] Post Conclusivo (Xorro Chat)

Aggiungo qualche mio commento ai punti giustamente esposti da MultiTaskinG

MultiTaskinG wrote:
> [cut]
>
> 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)
>   
Forse non tieni conto che all'interno di un'azienda esistono delle
REGOLE che si cerca di rispettare. Se l'admin in questione ti è
risultato un po bastardo perchè ti bloccava le porte e tu non potevi
lanciare MSN,ICQ e avviare i 35 download con bittorrent, beh lasciamo
dire che le sue scelte sono pienamente condivisibili.  Personalmente
farei la stessa cosa visto che mi pagano per far rispettare determinati
regolamenti (sempre e comunque nel limite del vivere civile, non manerò
mai affanculo un utente che gentilmente mi chiede un favore, ma potrei
farlo con uno che viene a lamentarsi perchè non riesce a chattare con
ICQ e il suo amico in brasile). D'altra parte...BOFH rulez!
>  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
>   
Partendo dal presupposto che sia paermessa la navigazione in internet al
personale non vedo perchè dovrei bloccare SSL visto che può essere
utile. Piuttosto cercherei di creare delle regole snort/squid per
bloccare o segnalare quello che potenzialmente NON è traffico HTTP-SSL.
> [cut]
>
> 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...) 
>
> [cut].
>   
Infatti non si criticava il protocollo HTTP ma il concetto con cui XORRO
cifrava i messaggi e l'eventuale overhead introdotto dal protocollo HTTP
nel trasportare informazioni diverse da quelle per cui è nato.
> 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.
>   
Appunto...perchè non "integrare" (parola molto in voga ultimamente)
soluzioni già collaudate per creare comunque qualcosa di nuovo e diverso
> 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.
>   
Se SSL è bloccato in "quella particolare" lan probabilmente è perchè c'è
un regolamento che lo impone. Vedi sopra.
> 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)
>   
Se leggi bene viene specificato che Jabber + SSL non è una forma certa
di sicurezza perchè non essendo end-to-end non ti garantisce che tu stai
parlando esattamente con l'interlocutore di ieri. End-to-end vuol dire
anche che io sono sicuro di parlare sempre con la stessa persona. Non
c'è modo di verificare l'autenticità del destinatario del tuo messaggio,
ma in ogni caso i dati viaggiano cifrati...esattamente come fa XORRO.
Quindi non vedo la differenza...
> 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.
>   
Decisamente comprovato da chi? Con che strumenti? Come faccio a
comprovare la bontà di un qualcosa se non posso "smontarla" e vederne la
reale bontà. E' come comprare una macchina con il cofano sigillato.
Tanto che serve aprirlo - può dirti il concessionario - c'è il libretto
delle istruzioni! Basta guardare quello, ci son tutte le figure anche!
> 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 ?
>   
Non li considero valori aggiunti le faccine che sorridono, mi fanno le
pernacchie e mi fanno il dito o la sinfonia n°5 che parte alla ricezione
del messaggio. Personalmente partendo con lo sviluppo di un nuovo
programma mi concentrerei sulle funzionalità "core" piuttosto che
rendere una "scatola vuota" molto user friendly (cfr. Microsoft Windows,
che cattivo che sò)
> OBIEZIONI ERRATE ########   (sez 2 di 3)
> [cut]
>> non rinventiamo costantemente la routa!
>>     
> 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)
>   
Scusa la cattiveria, ma sono state persone che han dedicato parte della
loro vita anche come lavoro allo studio di un singolo progetto, di una
singola parte, e soprattutto hanno documentato matematicamente
l'affidabilità del loro studio. Poi si sà dalla carta
all'implementazione informatica si perdono spesso i pezzi per strada....
> 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 ;-)
>   
Non mi pare uno scopo molto "nobile" quello di creare un programma solo
per il gusto di fare fesso un admin diligente. Più che altro perchè
sembra che vi poniate allo stesso livello dei cosiddetti script-kiddie:
"Cosa faccio oggi? Boh, una chat per far fesso quello str... dell'admin
che mi sta sulle balle"
>>  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 sostanza non cambia. Anzi, ancora meglio perchè ho un pattern fisso
da poter confrontare e bloccare più facilmente. Un buon BOFH non è
proprio fesso.
> [cut]
>>  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
>   
Come? Ma non era per fregare gli admin BOFH?? Adesso è diventato amico?
E se è amico perchè non usare ICQ allora? ;-)
>>  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 ????
>   
Se ci son delle regole che impongono agli utenti di non utlizzare client
IM non si fà e basta. Si chatta a casa! Al max si possono chiedere altre
spiegazioni in merito...
>>  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".
>   
Basta imparare a commentare! Per le modifiche esiste CVS o SVN. Fanno
tutto quello che serve per mantener traccia....basta andare su
sourceforge e ce l'hai gratis! :-)

[CUTTONE]

Mi fermo qui perchè i messaggi lunghi non mi piacciono e già questo è
troppo lungo (non me ne voglia l'Ing. Zanero)
Ripeto queste son mie considerazioni viste anche da uno che purtroppo o
per piacere deve spesso "combattere" questo tipo di "abusi".

Ciao

Davide