dubbi su SSL

71104 · 03-01-2007, 17:40

sto lavorando ad un programma sul quale userò connessioni SSL, ma non è questo il punto :P

lavorandoci mi sono tornati vecchi dubbi su SSL (sta storia della crittografia asimmetrica non m'ha mai convinto più di tanto...

)

in SSL la generazione delle due chiavi asimmetriche si basa su un problema matematico non risolto e che forse non avrà mai soluzione, ovvero la generazione di numeri primi giganteschi. ora, anche ammettendo che le due parti connesse siano in grado di generare tali numeri primi e che il man-in-the-middle non lo sia (cosa che già mi lascia un tantino perplesso), ciò che stavo pensando è che nessuno costringe il man-in-the-middle ad effettuare l'intercettazione a livello Transport, ma potrebbe anche farlo al disopra dell livello SSL.

spiego in termini pratici: A vuole connettersi a B passando per C, e quindi A vuole connettersi tramite SSL in modalità client sapendo che B ascolta in modalità server (cioè B genera le chiavi asimmetriche). C logga tutto quanto avvenga a livello Transport e giustamente di quello che si dicono A e B non capisce una beneamata perché non ha saputo decriptare la chiave simmetrica inviata da A durante l'handshake (non aveva la chiave asimmetrica privata per decriptare). e vabbè.

ora mettiamo invece che C sia un tantinello scafato

ordine degli eventi:

A chiede a B di connettersi tramite SSL (apre una connessione TCP su una porta sulla quale B ha un server che usa SSL)
C vede ciò e permette ad A di connettersi
B invia a C la chiave pubblica
C col cavolo che la passa ad A: genera altre due chiavi asimmetriche e passa ad A questa seconda chiave pubblica
C elabora una chiave simmetrica sua, la cripta con quella asimmetrica pubblica inviata da B e la manda a B (in sostanza, C stabilisce una connessione SSL con B)
nel frattempo A elabora una chiave simmetrica, la cripta con quella pubblica elaborata da C e la manda a C
C col cavolo che la manda a B se la tiene per se' e finge di essere B, stabilisce insomma una connessione SSL con A
C ha stabilito due connessioni SSL, una con A e una con B; la prima in modalità server e la seconda in modalità client.
A manda a C dati criptati pensando di mandarli a B
C se li logga in chiaro e li manda a B sull'altra connessione (li ri-cripta quindi)

ebbene? ho detto un mare di cavolate senza senso o cosa?

grazie per le risposte

71104 · 03-01-2007, 19:00

up!!! e dai su, non vorrete lasciare senza risposta un topic così interessante

kingv · 03-01-2007, 21:50

SSL/TSL non garantisce solo la confidenzialità delle informazioni, ma gestisce anche l'autenticazione (generalmente solo del server).

A si aspetta da B un certificato che C non puo' fornire, per cui il tuo scenario non puo' realizzarsi.

71104 · 03-01-2007, 22:08

Quote:

Originariamente inviato da kingv

A si aspetta da B un certificato che C non puo' fornire, per cui il tuo scenario non puo' realizzarsi.

e perché C non lo può fornire?

kingv · 03-01-2007, 22:26

Quote:

Originariamente inviato da 71104

e perché C non lo può fornire?

un certificato (che sia X.509 o OpenPGP è lo stesso) contiene il nome del soggetto a cui è intestato e il nome dell'issuer di quel certificato.
il client A controllerà che all'interno del certificato che l'host a cui intende connettersi (ovvero B) ci sia il nome di B. in caso contrario abortirà la connessione, presumendo che qualcuno stia impersonando B.
perchè il tuo scenario abbia successo C deve essere in grado di fornire un certificato ad A che contiene il nome di B emesso da una certification authority che A considera attendibile e questo non è solitamente possibile.

71104 · 04-01-2007, 00:03

Quote:

Originariamente inviato da kingv

un certificato (che sia X.509 o OpenPGP è lo stesso) contiene il nome del soggetto a cui è intestato e il nome dell'issuer di quel certificato.
il client A controllerà che all'interno del certificato che l'host a cui intende connettersi (ovvero B) ci sia il nome di B. in caso contrario abortirà la connessione, presumendo che qualcuno stia impersonando B.
perchè il tuo scenario abbia successo C deve essere in grado di fornire un certificato ad A che contiene il nome di B emesso da una certification authority che A considera attendibile e questo non è solitamente possibile.

ok, allora diciamo che quando C riceve da B il certificato lo manda anche ad A, ma per il resto le connessioni sono due. ovvero, C stabilisce con A una connessione SSL dandole il certificato ricevuto da B, quindi fingendosi di fatto B. è possibile?

kingv · 04-01-2007, 05:47

Quote:

Originariamente inviato da 71104

ok, allora diciamo che quando C riceve da B il certificato lo manda anche ad A, ma per il resto le connessioni sono due. ovvero, C stabilisce con A una connessione SSL dandole il certificato ricevuto da B, quindi fingendosi di fatto B. è possibile?

uhm uhm.... no non è possibile perchè C puo' servire ad A il certificato di B (che è pubblico ), ma poi non possedendo la chiave privata corrispondente a quel certificato (che solo B possiede) non è in grado di continuare la comunicazione TLS con A.

per qualche giorno non rispondo sul forum, se non trovi qualcuno iù bravo di me a spiegare ritorniamo poi sull'argomento

71104 · 04-01-2007, 13:33

Quote:

Originariamente inviato da kingv

uhm uhm.... no non è possibile perchè C puo' servire ad A il certificato di B (che è pubblico ), ma poi non possedendo la chiave privata corrispondente a quel certificato (che solo B possiede) non è in grado di continuare la comunicazione TLS con A.

cioè le chiavi asimmetriche sono associate al certificato? quindi sono sempre le stesse??

e il certificato in base a cosa è considerato attendibile dal client? insomma non è possibile produrre un certificato falso che il client consideri attendibile?

Quote:

per qualche giorno non rispondo sul forum, se non trovi qualcuno iù bravo di me a spiegare ritorniamo poi sull'argomento

doh ^^

^TiGeRShArK^ · 04-01-2007, 14:54

Quote:

Originariamente inviato da 71104

cioè le chiavi asimmetriche sono associate al certificato? quindi sono sempre le stesse??

e il certificato in base a cosa è considerato attendibile dal client? insomma non è possibile produrre un certificato falso che il client consideri attendibile?

doh ^^

no ke non è possibile perchè per firmare il certificato serve la chiave privata del fornitore del servizio, e quindi non può essere in nessun modo falsificato in quanto usando un altra chiave non sarebbe decrittabile usando la chiave pubblica del fornitore del servizio.

71104 · 04-01-2007, 15:03

che vuol dire "firmare il certificato"?

^TiGeRShArK^ · 04-01-2007, 15:36

Quote:

Originariamente inviato da 71104

che vuol dire "firmare il certificato"?

ehm..
nel senso ke x generare il certificato è necessaria la chiave privata di chi lo richiede

71104 · 04-01-2007, 15:41

Quote:

Originariamente inviato da ^TiGeRShArK^

ehm..
nel senso ke x generare il certificato è necessaria la chiave privata di chi lo richiede

e se io ad A gli rifilo un certificato farlocco come fa a capire che l'ho generato io con la mia chiave privata e non B con la sua visto che la chiave privata di B non la sa?

^TiGeRShArK^ · 04-01-2007, 16:30

Quote:

Originariamente inviato da 71104

e se io ad A gli rifilo un certificato farlocco come fa a capire che l'ho generato io con la mia chiave privata e non B con la sua visto che la chiave privata di B non la sa?

xkè sa la chiave pubblica di B

tu con gli algoritmi asimeetrici puoi ottenere il risultato originale e/o autenticare qualcuno utilizzando la sua chiave pubblica, mentre lui a crittografato e/o firmato tutto con la sua chiave privata

è proprio questo il punto di forza della codifica asimmetrica rispetto a quella simmetrica

71104 · 04-01-2007, 19:34

aspetta un attimo, sto certificato viene inviato ad A in forma criptata? non ho mica capito tanto bene... allora, abbiamo detto che per generare un certificato si usa la chiave privata... di preciso a cosa serve la chiave privata nella generazione? si usa per criptare o decriptare il contenuto vero e proprio del certificato stesso?

poi mettiamo che quando C riceve il certificato da B lo manda così com'è ad A; come fa A, conoscendo una chiave pubblica (generata da C, ma credendo che appartenga a B) a capire che la chiave privata che ha generato quel certificato non corrisponde alla chiave pubblica che conosce?

71104 · 04-01-2007, 19:36

Quote:

Originariamente inviato da 71104

poi mettiamo che quando C riceve il certificato da B lo manda così com'è ad A; come fa A, conoscendo una chiave pubblica (generata da C, ma credendo che appartenga a B) a capire che la chiave privata che ha generato quel certificato non corrisponde alla chiave pubblica che conosce?

ok, qui mi rispondo da solo: le due chiavi hanno un pezzo in comune, perciò può capirlo. niente falsificazione. ma cosa impedisce piuttosto a C di generare un certificato suo? come mai A è in grado di discriminare il certificato di C da quello di B? in teoria, per quanto ne sa A, C potrebbe tranquillamente essere B, in tutto e per tutto!

EDIT: supponiamo che io, programmatore non malizioso, voglio programmare un redirector SSL. senza intenzione maliziosa, ribadisco: io rappresento un server fidato, però mi è necessario vedere in chiaro i dati inviatimi dal client sulla connessione SSL, e poi devo redirigerli su un'altra connessione SSL al server finale. come mai non è possibile? le due connessioni SSL sono totalmente indipendenti tra loro!!

^TiGeRShArK^ · 04-01-2007, 19:52

Quote:

Originariamente inviato da 71104

ok, qui mi rispondo da solo: le due chiavi hanno un pezzo in comune, perciò può capirlo. niente falsificazione. ma cosa impedisce piuttosto a C di generare un certificato suo? come mai A è in grado di discriminare il certificato di C da quello di B? in teoria, per quanto ne sa A, C potrebbe tranquillamente essere B, in tutto e per tutto!

EDIT: supponiamo che io, programmatore non malizioso, voglio programmare un redirector SSL. senza intenzione maliziosa, ribadisco: io rappresento un server fidato, però mi è necessario vedere in chiaro i dati inviatimi dal client sulla connessione SSL, e poi devo redirigerli su un'altra connessione SSL al server finale. come mai non è possibile? le due connessioni SSL sono totalmente indipendenti tra loro!!

ehm..
ma hai capito come funziona la crittografia a chiave asimmetrica almeno ?

Le due chiavi non hanno NULLA in comune.
Esse sono semplicemente due fattori primi che moltiplicati danno un numero MOLTO grande.
Esistono degli algoritmi di crittazione e decrittazione basati proprio su questo concetto...
Mettiamo caso ke tu A vuoi inviare qualcosa a B.
In mezzo si mette X a rompere le palle cercando di sostituire il flusso di dati ke gli arriva da A.
Come fa a inviare un flusso di dati congruente a B?
Non può perchè X non conosce la chiave privata di A ma solo la sua chiave pubblica.
Quindi non può in alcun modo generare un flusso di dati ke B scambierà con quello di A in quanto quando B, tramite l'algoritmo di decrittazione, utilizza la chiave pubblica di A vede ke "i conti non gli tornano", ovvero non riuscirà a decrittare correttamente il messaggio.
L'unico modo per X di nuocere è di scoprire la chiave privata di A e quindi codificare il suo flusso di dati applicando all'algoritmo crittografico la chiave privata di A.
spè ke vedo se trovo qualke link col classico esempio di Alice ke non la da a Bob

^TiGeRShArK^ · 04-01-2007, 20:02

http://www.networkworld.com/news/64452_05-17-1999.html
http://en.wikipedia.org/wiki/Public-key_cryptography
http://www.aspencrypt.com/crypto101_public.html
Nell'ultimo in particolare viene spiegato il classico attacco di tipo man in the middle ke è quello proposto da te.
E in pratica si dice ke viene impedito dall'autorità 3rd party ke fornisce il certificato

EDIT:
però non ho trovato nessun esempio di Alice ke la desse a me...

71104 · 04-01-2007, 20:50

aaaaaaaaaaaaaaaaaa ma cioè aspè fateme capì

nella cifratura del certificato le due chiavi vengono usate al contrario... quella pubblica per decriptare e quella privata per criptare

(l'ho capito leggendo il link)

cmq non c'era bisogno che mi spiegassi come funziona la cifratura asimmetrica, almeno quella l'avevo capita

tu invece dovresti ripassarla, visto che non sai come si generano le due chiavi

le due chiavi non sono di per se' i due numeri primi: i due numeri primi vengono elaborati per generare altri 3 numeri differenti, di cui 1 andrà a far parte di entrambe le chiavi (ed è il pezzo in comune) e gli altri due andranno ciascuno in una chiave. vedo se riesco a ritrovarti su Wikipedia la procedura esatta...

71104 · 04-01-2007, 21:04

ehm però ancora non capisco...

allora, il certificato inviato da un server che usa SSL contiene un nome codificato da una chiave privata; il client SSL usa la chiave pubblica per decriptare il certificato e così può mostrare all'utente il nome contenuto in esso. se l'utente legge "eBay", o "Paypal", o "QualsiasiAltraFonteOnesta" si tranquillizza e continua la connessione, mentre se legge "HackerCheTiVuoleFormattareIlPCEPeggioAncoraFregartiISoldiDallaCartDiCredito" l'utente rifiuta la connessione

ora io mi sto ancora chiedendo: nel certificato inviato dal man-in-the-middle (criptato con la chiave privata del man-in-the-middle e da decriptare con quella pubblica sempre del man-in-the-middle), chi impedisce al man-in-the-middle di scriverci "NomeDiUnaFonteFidata" anziché "HackerCheTiVuoleEccEcc"???

beppegrillo · 04-01-2007, 21:23

Quote:

Originariamente inviato da 71104

ehm però ancora non capisco...

allora, il certificato inviato da un server che usa SSL contiene un nome codificato da una chiave privata; il client SSL usa la chiave pubblica per decriptare il certificato e così può mostrare all'utente il nome contenuto in esso. se l'utente legge "eBay", o "Paypal", o "QualsiasiAltraFonteOnesta" si tranquillizza e continua la connessione, mentre se legge "HackerCheTiVuoleFormattareIlPCEPeggioAncoraFregartiISoldiDallaCartDiCredito" l'utente rifiuta la connessione

ora io mi sto ancora chiedendo: nel certificato inviato dal man-in-the-middle (criptato con la chiave privata del man-in-the-middle e da decriptare con quella pubblica sempre del man-in-the-middle), chi impedisce al man-in-the-middle di scriverci "NomeDiUnaFonteFidata" anziché "HackerCheTiVuoleEccEcc"???

Il client non si tranquillizza leggendo il nome "ebay" o simili, ma si tranquillizza quando il certificato, che viene emesso esclusivamente da fonti note
Verisign,Thawte,InstantSSL ecc. ne assicura la corrispondenza ip.

03-01-2007, 17:40	#1
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	dubbi su SSL sto lavorando ad un programma sul quale userò connessioni SSL, ma non è questo il punto :P lavorandoci mi sono tornati vecchi dubbi su SSL (sta storia della crittografia asimmetrica non m'ha mai convinto più di tanto... ) in SSL la generazione delle due chiavi asimmetriche si basa su un problema matematico non risolto e che forse non avrà mai soluzione, ovvero la generazione di numeri primi giganteschi. ora, anche ammettendo che le due parti connesse siano in grado di generare tali numeri primi e che il man-in-the-middle non lo sia (cosa che già mi lascia un tantino perplesso), ciò che stavo pensando è che nessuno costringe il man-in-the-middle ad effettuare l'intercettazione a livello Transport, ma potrebbe anche farlo al disopra dell livello SSL. spiego in termini pratici: A vuole connettersi a B passando per C, e quindi A vuole connettersi tramite SSL in modalità client sapendo che B ascolta in modalità server (cioè B genera le chiavi asimmetriche). C logga tutto quanto avvenga a livello Transport e giustamente di quello che si dicono A e B non capisce una beneamata perché non ha saputo decriptare la chiave simmetrica inviata da A durante l'handshake (non aveva la chiave asimmetrica privata per decriptare). e vabbè. ora mettiamo invece che C sia un tantinello scafato ordine degli eventi: A chiede a B di connettersi tramite SSL (apre una connessione TCP su una porta sulla quale B ha un server che usa SSL) C vede ciò e permette ad A di connettersi B invia a C la chiave pubblica C col cavolo che la passa ad A: genera altre due chiavi asimmetriche e passa ad A questa seconda chiave pubblica C elabora una chiave simmetrica sua, la cripta con quella asimmetrica pubblica inviata da B e la manda a B (in sostanza, C stabilisce una connessione SSL con B) nel frattempo A elabora una chiave simmetrica, la cripta con quella pubblica elaborata da C e la manda a C C col cavolo che la manda a B se la tiene per se' e finge di essere B, stabilisce insomma una connessione SSL con A C ha stabilito due connessioni SSL, una con A e una con B; la prima in modalità server e la seconda in modalità client. A manda a C dati criptati pensando di mandarli a B C se li logga in chiaro e li manda a B sull'altra connessione (li ri-cripta quindi) ebbene? ho detto un mare di cavolate senza senso o cosa? grazie per le risposte

04-01-2007, 20:02	#17
^TiGeRShArK^ Senior Member Iscritto dal: Jul 2002 Città: Reggio Calabria -> London Messaggi: 12112	http://www.networkworld.com/news/64452_05-17-1999.html http://en.wikipedia.org/wiki/Public-key_cryptography http://www.aspencrypt.com/crypto101_public.html Nell'ultimo in particolare viene spiegato il classico attacco di tipo man in the middle ke è quello proposto da te. E in pratica si dice ke viene impedito dall'autorità 3rd party ke fornisce il certificato EDIT: però non ho trovato nessun esempio di Alice ke la desse a me... __________________ Ultima modifica di ^TiGeRShArK^ : 04-01-2007 alle 20:09.

04-01-2007, 21:04	#19
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	ehm però ancora non capisco... allora, il certificato inviato da un server che usa SSL contiene un nome codificato da una chiave privata; il client SSL usa la chiave pubblica per decriptare il certificato e così può mostrare all'utente il nome contenuto in esso. se l'utente legge "eBay", o "Paypal", o "QualsiasiAltraFonteOnesta" si tranquillizza e continua la connessione, mentre se legge "HackerCheTiVuoleFormattareIlPCEPeggioAncoraFregartiISoldiDallaCartDiCredito" l'utente rifiuta la connessione ora io mi sto ancora chiedendo: nel certificato inviato dal man-in-the-middle (criptato con la chiave privata del man-in-the-middle e da decriptare con quella pubblica sempre del man-in-the-middle), chi impedisce al man-in-the-middle di scriverci "NomeDiUnaFonteFidata" anziché "HackerCheTiVuoleEccEcc"??? Ultima modifica di 71104 : 04-01-2007 alle 21:07.

03-01-2007, 19:00	#2
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	up!!! e dai su, non vorrete lasciare senza risposta un topic così interessante

03-01-2007, 21:50	#3
kingv Senior Member Iscritto dal: Jan 2001 Città: Milano Messaggi: 5707	SSL/TSL non garantisce solo la confidenzialità delle informazioni, ma gestisce anche l'autenticazione (generalmente solo del server). A si aspetta da B un certificato che C non puo' fornire, per cui il tuo scenario non puo' realizzarsi.

04-01-2007, 15:03	#10
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	che vuol dire "firmare il certificato"?

04-01-2007, 19:34	#14
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	aspetta un attimo, sto certificato viene inviato ad A in forma criptata? non ho mica capito tanto bene... allora, abbiamo detto che per generare un certificato si usa la chiave privata... di preciso a cosa serve la chiave privata nella generazione? si usa per criptare o decriptare il contenuto vero e proprio del certificato stesso? poi mettiamo che quando C riceve il certificato da B lo manda così com'è ad A; come fa A, conoscendo una chiave pubblica (generata da C, ma credendo che appartenga a B) a capire che la chiave privata che ha generato quel certificato non corrisponde alla chiave pubblica che conosce?

04-01-2007, 20:50	#18
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	aaaaaaaaaaaaaaaaaa ma cioè aspè fateme capì nella cifratura del certificato le due chiavi vengono usate al contrario... quella pubblica per decriptare e quella privata per criptare (l'ho capito leggendo il link) cmq non c'era bisogno che mi spiegassi come funziona la cifratura asimmetrica, almeno quella l'avevo capita tu invece dovresti ripassarla, visto che non sai come si generano le due chiavi le due chiavi non sono di per se' i due numeri primi: i due numeri primi vengono elaborati per generare altri 3 numeri differenti, di cui 1 andrà a far parte di entrambe le chiavi (ed è il pezzo in comune) e gli altri due andranno ciascuno in una chiave. vedo se riesco a ritrovarti su Wikipedia la procedura esatta...

Strumenti
Mostra una versione stampabile Invia questa pagina per email