Perché diverse tecniche di scambio di chiavi per lo scambio di chiavi SSL?

La distinzione non è tanto una questione tra Diffie-Hellman e lo scambio di chiavi RSA in generale, piuttosto si tratta di essere in grado di usare Ephemeral Diffie-Hellman, che usa ogni volta un parametro effimero (cioè nuovo) . (È anche possibile utilizzare i parametri fissi del DH, ma non sono sicuro di averlo mai visto.)

In sostanza, se registri il traffico crittografato e in seguito ottieni la chiave privata del server, una suite di crittografia RSA, puoi in seguito decifrare immediatamente l'intero traffico (ad esempio usando Strumenti SSL di Wireshark ).

Al contrario, usando EDH, i nuovi tasti DH casuali sono (o dovrebbero essere) generati ogni volta da ciascun lato. Questi parametri non sono registrati e non sono visibili sul filo, che fornisce Perfect Forward Secrecy (PFS). Ecco perché la decifrazione delle suite di crittografia EDH non è supportata in Wireshark. Le versioni ragionevolmente recenti di Wireshark possono decifrare il traffico che utilizza le suite di crittografia EDH, ma è necessario ottenere il segreto pre-master (ogni volta) . (Vedi " Utilizzo della sezione (Pre) -Master-Secret " della pagina wiki di Wireshark SSL e questa domanda qui .)

(Che sia effettivamente perfetto non è chiaro, ma aggiunge un altro spazio casuale che un utente malintenzionato potrebbe avere per forza bruta.)

Puoi trovare maggiori dettagli in questo documento RSA Security Inc. o alla fine di questa sezione del Specifiche TLS .

Penso che tu abbia frainteso ciò che hai letto, o hai delle cattive informazioni. La tua premessa non è accurata.

Hai detto che "l'invio della chiave simmetrica al server crittografato con la chiave pubblica del server" non è aggiornato. Non è accurato Non c'è niente di sbagliato in questo modo di fare lo scambio di chiavi. Infatti, la maggior parte delle sessioni SSL negoziate oggi utilizza esattamente questa tecnica. Non c'è niente di obsoleto o problematico con esso.

Hai anche detto "Adesso per lo scambio chiave Diffie Hellman e altre tecniche sono usate". Se volevi dire che Diffie-Hellman ha sostituito il metodo tradizionale di crittografia della chiave simmetrica sotto la chiave pubblica del server, non è nemmeno accurato. Diffie-Hellman non ha sostituito questi metodi. L'approccio Diffie-Hellman è valido e valido, ma non è corretto affermare che Diffie-Hellman sia in qualche modo più recente (in effetti, è più vecchio) o che ha sostituito altri metodi.

Immagino che al centro di esso, se non è messo sul filo, non può essere annusato, ed è più difficile da rompere. Posso immaginare uno scenario come questo: un utente malintenzionato si trova in qualche modo nel mezzo della comunicazione tra server e client e registra tutti i dati. Dopo un po ', l'utente malintenzionato è in grado di compromettere il certificato del server, ottenendo la sua chiave privata. Con questo, tutte le sessioni SSL acquisite possono essere compromesse, dal momento che il segreto condiviso può essere decodificato.

Diffie-Hellman lo impedisce, con ogni parte che ha un segreto e un altro bit di dati relativi a quel segreto che è considerato pubblico. Una volta che una delle parti ha ricevuto il pezzo pubblico dell'altra parte, viene eseguito un po 'di fantasia matematica che genera un numero correlato a entrambi i segreti, ma non è ottenibile dalle informazioni pubbliche. Quindi, in breve, lo scambio di chiavi DH può essere annusato, ma il segreto condiviso non può essere ottenuto.

Nello scenario sopra, a meno che l'utente malintenzionato non comprometta il server stesso e installi una versione modificata della suite SSL che registra i segreti condivisi (un'attività molto più complicata. Ottenere il certificato completo può semplicemente coinvolgere l'ingegneria sociale o compromettere un'altra casella ), le sessioni SSL catturate sono ancora sicure, dal momento che il segreto condiviso non viene mai messo in rete su nessun modulo.