Quanto è sicuro SSL?

6

Non è vero che SSL può essere decodificato semplicemente ascoltando l'attività di rete di un PC su una rete? (ad esempio, dalla prima volta che un PC casuale si connette a un bar, e continua ad ascoltare fino a quando l'utente non interrompe la navigazione e non ti interessa più per ulteriori dati) Non sono tutte le chiavi lì e gli algoritmi pubblicati in modo che possa essere decodificato senza alcuna forza bruta?

(Questa è una domanda si o no, ma citare una fonte sarebbe piacevole per la lettura di furthur)

    
posta George Bailey 11.07.2011 - 18:03
fonte

5 risposte

8

La risposta breve alla tua domanda è, nel caso generale *, no.

La risposta più lunga è che la ragione per cui ciò non è possibile dipende in gran parte dall'uso della crittografia a chiave pubblica-privata nella creazione della sessione SSL, il che significa che la chiave di sessione non viene trasmessa sulla rete in chiaro in qualsiasi momento durante la sessione.

* Esiste una serie di circostanze che possono comportare la decifrazione di una comunicazione crittografata SSL da parte di qualcuno, ma è improbabile che vengano applicate allo scenario generale della caffetteria.

    
risposta data 11.07.2011 - 18:44
fonte
6

È possibile creare un segreto condiviso comune senza trasferirlo sulla rete. Leggi su scambio di chiavi RSA e Diffie-Hellman in Wikipedia o altre fonti per ottenere un'intuizione su come funziona. Puoi anche eseguire un semplice calcolo dei test da solo (ma è sicuro solo per numeri estremamente grandi e diverse modifiche minori).

Una volta compreso questo, potresti voler dare un'occhiata agli (ugualmente semplici) attacchi Man-In-The-Middle contro questi algoritmi (probabilmente anche su wikipedia). Per evitare ciò, è necessaria l'autenticazione reciproca, ad es. Firmando le chiavi pubbliche DH / RSA e lasciando che il peer verifichi la firma.

Questa autenticazione a sua volta richiede alcune conoscenze comuni da parte della "firma emittente" (autorità di certificazione), ma tale informazione non è richiesta per essere segreta. Questo ingrediente finale ("certificato radice") viene quindi semplicemente spedito con ogni browser e ci sono procedure estese per crearlo e accettarlo.

Quindi, se ti fidi di queste autorità il cui certificato di origine che il tuo fornitore di browser inserisce nel tuo browser per emettere informazioni di autenticazione corrette (certificati), sarai in grado di creare connessioni crittografate + autenticate. (la crittografia è quasi inutile se non sai dove sei connesso!)

    
risposta data 11.07.2011 - 18:51
fonte
2

SSL non può essere decodificato con il metodo che hai menzionato.

Tuttavia, ciò che hai descritto è simile a un attacco su una chiave di rete wireless come WEP.

    
risposta data 11.07.2011 - 18:19
fonte
2

La chiave privata del server non viene mai trasmessa . Ciò significa che il client può inviare informazioni crittografate con la chiave pubblica del server e solo il server può decrittografarlo. Queste informazioni generano una chiave di sessione che è nota solo al client e al server e verrà utilizzata per crittografare il traffico.

Nota: questo è un sommario estremamente semplificato. C'è molta più "magia" in corso per garantire che stai usando la chiave pubblica del server giusto e il traffico non può essere riprodotto.

Wikipedia ha un buon articolo in grado Crittografia a chiave pubblica / privata

    
risposta data 11.07.2011 - 19:39
fonte
0

La magia che impedisce a un utente malintenzionato di decodificare tutti i dati in questo modo è denominata "crittografia asimmetrica". Poiché non è necessario che la chiave di crittografia e la chiave di decrittografia siano uguali, è possibile inviare uno di questi all'apertura, consentendo a tutti di crittografare i messaggi futuri e mantenere comunque l'esclusiva possibilità di decrittografarli (l'altro, privato, chiave della coppia). Quelle chiavi sono diverse (appena generate) in ogni sessione SSL.

Diventa più complicato quando l'attaccante è disposto a inviare attivamente chiavi "false", ingannando gli altri a usarle. Quindi l'altro argomento di cui potresti voler leggere è "infrastruttura a chiave pubblica". Ciò fornisce un livello iniziale di fiducia basato su precedenti comunicazioni dietro le quinte, tra parti quali autorità di certificazione, operatore di server, produttore di hardware e venditori di sistemi operativi. Già prima che il primo pacchetto venga trasmesso all'interno del coffee shop, tutti conservano vari certificati, chiavi e contatti per gli amici di fiducia reciproca, i quali saranno utili per autenticare l'altra parte per quello che dicono di essere.

SSL può autorizzare sia i server che i client, ma poiché il server ha più controllo sulla chiave di sessione e anche sulla logica di business dell'interazione, è normale non preoccuparsi di autenticare i client.

Occasionalmente puoi imbatterti in scenari in cui le normali ipotesi si guastano. Errori logici in protocolli, CA incompleti, interferenze governative, hardware compromesso dalla fabbrica , chiavi che sono trapelate senza che nessuno se ne accorga e generatori di chiavi casuali che sono molto meno casuali di quanto desideri. Per la stragrande maggioranza di tali buchi, la privacy nel coffee shop è a rischio solo se l'attaccante interferisce attivamente e aiuta a guidare la conversazione verso il buco in qualche modo.

    
risposta data 11.06.2015 - 23:04
fonte

Leggi altre domande sui tag