Link alla notizia: http://www.hwupgrade.it/news/sicurezza/14780.html

Vi proponiamo questo articolo relativo alle tecnologie SSL Secure Socket Layer 3.0, a cui oggi giorno è affidata la sicurezza di gran parte dei dati traferiti in internet

Click sul link per visualizzare la notizia.

...
molto interessante
...

Complimenti!

Ora vado a leggere l'articolo, spero che risponda a una mia domanda. cioé durante l'handshake ci si tresmettono le chiavi in modalità nn protetta? E nn possono essere intercettate?

la domanda è sicuramente stupida, ma cmq nn ho avuto risposta.

a parte che io non sono proprio sicuro che venga usata una chiave simmetrica con SSL, mi ricordavo che facesse uso esclusivamente di chiavi asimmetriche (pubblica+privata)... ma in ogni caso ci sono algoritmi per scambiarsi una chiave su un canale non protetto, un esempio è il Diffie Hellman. L'algoritmo è piuttosto sicuro, fa uso di calcolo logaritmico e impedisce di scoprire in tempo utile la chiave che ci si scambia (occorrerebbero probabilmente anni per decrittare i dati).

Non ci si trasmettono mai "le chiavi" almeno quelle private.

La prima fase di SSL è lo scambio di Diffie-Hellman (o varianti ed equivalenti) con cui si riesce a generare una nuova chiave simmetrica sui due lati senza doversela scambiare e senza scambiare informazioni che permettano ad uno che è in ascolto di generarla identica.

Poi di solito si usa questa chiave di sessione per cifrare simmetricamente il traffico ed all'interno del canale cifrato ci si scambiano chiavi pubbliche o certificati e quant'altro.

mi correggo SSL non usa comunque Diffie-Hellman, almeno non solo

cmq come al solito la wikipedia è utilissima quando non ti ricordi le cose :D http://en.wikipedia.org/wiki/Secure_Sockets_Layer

hai rinfrescato la memoria pure a me, sono decisamente arrugginito :)

Una volta completato l'handshake tutto il traffico viene crittato tramite chiave privata (simmetrica) perchè più veloce. Questa chiave privata(simmetrica) è stata "spedita" da un client all'altro non in chiaro ma crittografata usando la crittografia a chiave Pubblica; cioè una volta che un client ha generato una chiave privata(simmetrica) la critta usando la chiave pubblica del destinatario e gliela spedisce. In questo modo nessuna chiave è mai transitata in chiaro sul canale.
La proprietà fondamenttale della crittografia a chiave pubblica è proprio il fatto che per comunicare in modo "sicuro" non devo mai spedire la chiave in chiaro (e anzi non la devo spedire proprio!)

Vorreste far capire anche a me che in crittografia sono molto indietro ?
Io non comprendo come è possibile accordarsi su una chiave senza che un eventuale ascoltatore non riesca a fare altrettanto.
Cioè, a livello teorico: la due macchine si trovano in uno stato iniziale noto al terzo ascoltatore che può replicare sulla sua terza macchina. La prima macchina invia dati alla seconda e qusta cambia stato in base a questi dati e alo stato iniziale. Perchè anche la terza macchina non può cambiare il suo stato nella stesso modo della seconda avendo stesso stato iniziale e stesso input, e quindi sostituirsi ad essa ? Anche se l'operazione avviene in più passi, la terza macchina dovrebbe sempre poter replicare la situazion della seconda macchina basando sullo stato iniziale e sugli input.
Grazie di eventuali chiarimenti.

Vorreste far capire anche a me che in crittografia sono molto indietro ?
Io non comprendo come è possibile accordarsi su una chiave senza che un eventuale ascoltatore non riesca a fare altrettanto.

Usando la crittografica asimmetrica per scambiarsi la chiave da usare con un algoritmo simmetrico.

In una versione molto semplificata, il server, ad esempio, sceglie una chiave in base ad un qualche algoritmo di generazione di numeri random non riproducibile (ad esempio basandosi sulla temperatura nel case in quel momento). Generata la chiave, il server la crittografa con la chiave pubblica del client e la trasmette. Il client riceve la chiave crittografata che puo' essere letta solo se in possesso della sua chiave privata che nessun altro puo' avere. Quando la chiave di trasmissione e' stata scambiata, puo' iniziare la trasmissione sicura dei contenuti crittografati.

La crittografia asimmetrica si basa su queste proprietà:

Esiste un algoritmo per generare, a partire da una chiave privata, una chiave pubblica, che appunto deve esssere nota, per cui crittografando con questa chiave, solo chi possiede la chiave privata può decrittografare. E' teoricamente possibile ottenere la chiave privata dalla pubblica, ma occorre moltissimo tempo... E' per questo che i certificati (che contengono le chiavi pubbliche) scadono...

oopps.. abbiamo risposto assieme... ;)

oopps.. abbiamo risposto assieme... ;)

Meglio, la tua risposta e' piu' precisa della mia :)

(devo studiare crittografia)

non ho mica capito bene il tuo discorso... cmq ti spiego brevemente un algoritmo usato (il diffie hellman)... saltando un po' si passaggi si arriva ad avere una cosa di questo tipo:
Ka = (Yb)^Xa = (a^Xb)^Xa = (a^Xa)^Xb = (Ya)^Xb = Kb
dove Ka=Kb=K è la chiave condivisa per criptare (è il modo che usano i due computer che si scambiano informazioni per criptare i dati), a è la radice primitiva di un numero primo molto grande, Ya e Yb sono le rispettive chiavi pubbliche e Xa e Xb sono le rispettive chiavi private. Da questo si osserva che pur usando chiavi diverse, i due terminali cifrano i dati allo stesso modo.
Alla fine si deduce che per poter risolvere l'equazione e quindi per poter decifrare i dati, bisogna essere in possesso di almeno 3 elementi: le due chiavi pubbliche ed una privata, così girando l'equazione si può ottenere l'altra chiave privata... I due terminali coinvolti hanno la propria e l'altra chiave pubblica ed hanno entrambi la propria chiave privata; per una terza parte è impossibile risolvere l'equazione (se non andando per tentativi e sicuramente non in tempo utile) siccome non ha nemmeno una delle due chiavi private.

m'avete preceduto :)

Io non comprendo come è possibile accordarsi su una chiave senza che un eventuale ascoltatore non riesca a fare altrettanto.
Su come un terzo ascoltatore non può inserirsi nella comunicazione te l'hanno già spiegato ;)
Comunque è sempre possibile, agendo sui DNS (qualche buco si trova sempre :p) redirigere la comunicazione di un client su un altro host che si spaccia come server. In questo caso servono i certificati, che permettono di identificare in modo univoco l'host. Anche in questo caso c'entrano le chiavi pubbliche/private, in particolare il certificato contiene una firma (codificata con la chiave privata di una società di certificazione, come verisign) che viene controllata dal browser (con la chiave pubblica della società di c.) prima di essere accettata.

aLLaNoN81 adesso mi leggo con clalma la tua risposta e cerco di capirla per bene. Per gli altri che mi hanno risposto grazie a tutti però mi rimane un dubbio. Per quello che so io, le chiavi private delle due macchine devono essere preventivamente concordate in altre sede fra i due. Eppure dalle vostre risposte questa condizione non si evince. Non capisco quindi se sono io che faccio confusione oppure è una condizione necessaria ma passata sempre sottobanco perchè fa cadere la possibilità di una comunicazione sicura tra due host che non si sono mai conosciuti.

OK ancora non ho capito bene ma questa frase mi lascia perplesso:
siccome non ha nemmeno una delle due chiavi pubbliche.
come mai non la può conoscere ? Le chiavi pubbliche non si chiamano pubbliche perchè sono conosciute da tutti?

[...] Per gli altri che mi hanno risposto grazie a tutti però mi rimane un dubbio. Per quello che so io, le chiavi private delle due macchine devono essere preventivamente concordate in altre sede fra i due. Eppure dalle vostre risposte questa condizione non si evince. Non capisco quindi se sono io che faccio confusione oppure è una condizione necessaria ma passata sempre sottobanco perchè fa cadere la possibilità di una comunicazione sicura tra due host che non si sono mai conosciuti.

Per inviarti un messaggio cifrato ho bisogno di conoscere solamente la tua chiave pubblica, non la privata. La "forza" di questa architettura è proprio nel fatto che non occorre creare nessun canale protetto preventivo.

OK mi sono letto alcuni articoli sul'argomento e penso di aver capito, è chiaro che lo stato iniziale delle due macchine non sono note alla terza che tenta di inserirsi.
Grazie a tutti.

La "terza macchina" non avrà mai lo stesso "stato iniziale" di nessuna delle altre due semplicemente perchè non è in possesso della chiave privata( di una coppia chiave pubblica-privata) di nessuno degli altri due attori

La "terza macchina" non avrà mai lo stesso "stato iniziale" di nessuna delle altre due semplicemente perchè non è in possesso della chiave privata( di una coppia chiave pubblica-privata) di nessuno degli altri due attori

ops, sorry del doppio post

OK ancora non ho capito bene ma questa frase mi lascia perplesso:

come mai non la può conoscere ? Le chiavi pubbliche non si chiamano pubbliche perchè sono conosciute da tutti?

Ed infatti ho scritto una bestialità :D Nella fretta ho preso una svista, ho scritto pubbliche anzichè private ;)
Ora cmq dovresti aver capito, per un terzo incomodo non in possesso di una chiave privata, si tratterebbe di risolvere un'equazione in 2 incognite, cosa impossibile ;)

Salve...

per comprendere meglio il concetto di chiave pubblica e privata, si può fare un parallelo con chiave e lucchetto (quelli fisici intendo, non digitali).
La chiave pubblica è come un lucchetto, mentre la chiave privata è la chiave fisica per aprire il lucchetto.
In pratica Tizio invia a Caio un lucchetto (chiave pubblica), di cui solo tizio ne possiede la chiave per aprirlo (chiave privata). Caio a questo punto non può fare altro che confezionare una scatola (il codice da inviare crittografato con la chiave pubblica) e chiuderla col lucchetto di Tizio (criptazione), quindi invia la scatola inlucchettata ( il codice cifrato), ovviamente solo Tizio che è in possesso della chiave fisica (chiave privata) potrà aprire il lucchetto ed aprire la scatola (decriptare e leggere il codice in chiaro).

Se ho sbagliato vi prego di correggermi :)

Penso che di tutto questo la cosa che confonde di più è che se A e B si scambio dati criptati, A invia a B chiave, doppia pubblica di criptazione e B invia ad A una'altra chiave, anche questa doppia e pubblica. Quindi alla fine nel sistema ci sono ben 8 chiavi, 4 pubbliche e 4 private

No, nel sistema ci sono sempre 4 chiavi: 2 pubbliche e 2 private. A e B non si scambiano mai le proprie chiavi private perchè non ce n'è bisogno! A cripta con la propria privata e con la pubblica di B, mentre B in ricezione decifra con la propria chiave privata e viceversa. Non si ha mai un invio di chiavi sul canale.

Mi riferivo al fatto che ciascuna chiave è doppia nel senso che è composta da due valori. Quindi 8 chiavi.

Io sapevo che per SSLv3 [ho omesso in questo post l'autentificazione del client da parte del server perchè è facoltativa] il client invia al server una serie di informazioni (algoritmi di crittografia e d'integrità supportati,esempio Des,Triple Des,RC4 per la crittografia e MD5 e SHA-1 per l'integrità,l'utilizzo di compressione) e un nonce generato localmente chiamiamolo Rclient.

Dopodichè il server comunicava gli algoritmi scelti fra quelli supportati dal client e sceglieva un nonce generato localmente (Rserver) e spediva il tutto al client.

A questo punto il server invia il proprio certificato (firmato da una CA,basta guardare nelle proprie opzioni del broswer per vedere le CA presenti) con la propria chiave pubblica e poi comunica al client che è arrivato il suo turno (transazione server conclusa).
Il client risponde scegliendo una chiave casuale di 384 bit detta Premaster Key che invia al server in forma crittografata utilizzando la chiave pubblica (certificata) del server.
La Session Key vera e propria però non è la Premaster Key ma è ricavata da i 2 nonce (Rserver e Rclient) e la stessa Premaster Key.
Entrambi calcolano la Session Key.
A questo punto il client spedisce 2 messaggi per indicare che da qui in avanti si utilizzerà la chiave e che il protocollo di handshake è terminato.
Il server risponde con 2 messaggi per confermare i precedenti.
Adesso è terminato completamente l'handshake fra client e il server.
Talvolta potrebbe esserci anche l'autentificazione del client da parte del server (non è obbligatoria),ho omesso questa parte.

Da qui in poi si cripta i dati provenienti dallo strato applicativo oltre che un controllo d'integrità.
Infatti si utilizza un altro protocollo di SSLv3 (il precendente definiva le regole per l'handshake) per la crittografia e l'integrità.
I msg provenienti dallo strato applicativo (si pensi a SSLv3 come a uno strato intermedio fra strato applicativo e strato di trasporto o meglio del solo TCP visto che funziona solo con quest'ultimo) vengono suddivisi in blocchi di 16kbyte ciascuno (se è abilitata la compressione ogni unità è compressa singolarmente).
Poi si calcola con l'algoritmo scelto per l'integrità (esempio MD5) un Hash sul blocco+la Session Key concatenata a quest'ultimo.
Poi l'hash viene aggiunto al blocco come MAC (Message Autentication Code) e compresso.
Poi viene cifrato con l'algoritmo a chiave simmetrica scelto (di solito per transazioni commerciali viene calcolata l'Xor fra la KeyStream di RC4,a sua volta generata utilizzando come seme la Session Key,e il blocco in questione).
Infine viene aggiunta un'intestazione a questo blocco finale cifrato e passato allo strato di trasporto (il quale lo inserirà come carico utile in un segmento TCP).

Da notare che il migliore algoritmo per l'integrità è SHA-1 e per la crittografia il Triple DES con chiavi a 168Bit.
Altrimenti un altro per la crittografia è l'RC4 con chiavi a 128Bit (se non sbaglio in alcuni paesi è necessario però che i primi 88Bit siano pubblici per ragioni di governo....) e per l'integrità invece un alternativa a SHA-1 è MD5.

Da notare che quando si utilizza http su ssl prende il nome di https.
Inoltre non è possibile (almeno su Apache) utilizzare la funzione di "VirtualHost" basati su i nomi perchè prima di scambiare qualsiasi dato (quindi anche i msg http) si autentifica il server con un certificato firmato da una CA dove è presente il "nome logico" del server web.


Spero di non aver detto qualcosa di errato se sì ditemelo :fagiano: .


Edit :
I 2 protocolli di SSLv3 sono SSL Handshake Protocol (il primo per l'handshake) e SSL Record Protocol (per il trasporto crittografato dell'informazione e il controllo di integrità) come scritto anche nell'articolo.

Ho visto adesso questa news... Decisamente interessante... Apache ha gia' un'implementazione per SSL 3.0?