Perché gli handshake SSL sono protetti e perché un hacker non può esaminarlo e decifrare i dati? [duplicare]

5

Se capisco bene, c'è una "stretta di mano" in cui sia il server che il browser verificano chi sono e concordano su una chiave di crittografia. Perché un hacker non può solo guardare la rete per controllare i tasti?

Perché un hacker non può solo guardare l'handshake, raccogliere i dati ed eseguirlo attraverso un software facile da scrivere?

    
posta Anonymous Penguin 25.02.2014 - 01:49
fonte

2 risposte

3

Vedi la sezione Handshakes della risposta di Thomas Porrin su Come funziona SSL? per i dettagli completi, ma per Risposta molto breve:

Perché la prima stretta di mano di una sessione finisce con l'usare la crittografia asimmetrica per crittografare una chiave simmetrica sulla chiave pubblica dell'altro lato (che è effettivamente disponibile tramite lo sniffing dei pacchetti), e poi l'altra parte usa la propria chiave privata per decrittografarla. Questa chiave privata non viene trasmessa tra i due, e senza di essa è proibitivamente difficile decrittografare il messaggio contenente la chiave simmetrica (escludendo difetti di implementazione o di progettazione).

Una volta trasferita la chiave simmetrica, è possibile utilizzare un codice simmetrico poiché esiste una chiave "segreto condiviso".

    
risposta data 25.02.2014 - 04:15
fonte
3

Esistono due tipi di crittografia. Simmetrico e Asimmetrico.

In Simmetrico , la stessa chiave viene utilizzata in entrambe le parti per crittografare / decrittografare i dati. Gli esempi includono algoritmo AES. Se il MITM conosce la chiave simmetrica utilizzata dal client e dal server, può facilmente decifrare i messaggi.

In Assymetric , viene utilizzata una coppia di chiavi public-private. Un modo per arrivare a un segreto comune usando la crittografia asimmetrica è il seguente:

Il server genera una coppia di chiavi pub / pri usando l'algoritmo RSA. Mette la chiave pubblica in un certificato e la invia al client.

Il client genera un segreto pre-master casuale e lo crittografa utilizzando la chiave pubblica ricevuta dal certificato del server e invia il segreto pre-master crittografato nel messaggio "scambio chiavi del client".

Il server decodificherà quindi il messaggio crittografato usando la sua chiave privata associata alla chiave pubblica.

Ora sia server che client hanno lo stesso segreto pre-master. Useranno questo e alcuni altri valori casuali (come clientHelloRandom, serverHelloRandom che vengono inviati in testo normale durante le stringhe di mano clientHello e serverHello) per ricavare la stessa chiave master.

Questa chiave master viene utilizzata per derivare le chiavi di sessione utilizzando le quali i dati delle applicazioni sono crittografati / decrittografati.

Si noti che un MITM non può impersonare un client perché la chiave pre-master generata dal client legittimo viene inviata crittografando con la chiave pubblica. il MITM non può decodificarlo finché non conosce la chiave privata e solo il server lo sa (la chiave privata non è condivisa). E poiché il MITM non conosce la chiave privata, non può impersonare anche il server .

Quindi, quando viene utilizzata una suite di crittografia come TLS_WITH_RSA_AES128_CBC_SHA, RSA viene utilizzato per generare una coppia di chiavi pub / pri, il DSA viene utilizzato per firmare il certificato inviato dal server e una volta che le chiavi simmetriche (stesse) master-secret e di sessione sono derivato da client e server, AES128 (algoritmo di crittografia / decrittografia a chiave simmetrica) viene utilizzato per crittografare / decrittografare i dati dell'applicazione.

Spero che questo chiarisca.

    
risposta data 09.02.2015 - 19:13
fonte

Leggi altre domande sui tag