DH è vulnerabile a un attacco man-in-middle a causa dell'assenza di autenticazione del server; e RSA non ha il segreto in avanti.
Le persone suggeriscono la DH effimera usata, ma quali sono le differenze tra DH effimera e DH ordinaria? Perché è più adatto? Che ne dici di utilizzare il protocollo di password remota sicura per lo scambio di chiavi?
In sintesi, quale di questi è migliore e perché:
TLS_EDH o TLS_SRP
Perfect Forward Secrecy , nel contesto di TLS, significa che la chiave utilizzata per decrittografare le cose non viene salvata da nessuna parte , e quindi è immune da ulteriori furti.
Nelle semplici suite DH, il certificato del server contiene la chiave pubblica DH e la chiave privata corrispondente è quella salvata in un file da qualche parte sul server. Se qualcuno ruba quella chiave (ad esempio da un vecchio disco rigido dismesso o un nastro di backup fuori posto), può usarla per decrittografare le connessioni passate che ha registrato (passive intercettazioni sulla linea) prima del furto della chiave. Lo stesso problema si applica alle semplici suite di crittografia RSA, che sono molto più comuni del semplice DH (i certificati contenenti un codice DH sono piuttosto rari).
Con le suite DHE, i certificati server contengono una chiave pubblica RSA o DSA. Quando si avvia (o ad ogni nuova connessione), il server crea una nuova coppia di chiavi DH che conserva solo nella RAM. Il server invia la chiave pubblica DH come parte dell'handshake TLS, e firma quella chiave pubblica con la sua chiave DSA o RSA (quella che memorizza in un file). Il nostro attaccante ladro, una volta che ha ottenuto una copia della chiave RSA o DSA, può falsificare le proprie firme, ma non otterrà la chiave privata DH, poiché quella non è stata memorizzata da nessuna parte. Pertanto, DHE impedisce al ladro di chiavi di decifrare le sessioni passate, che è il punto di PFS.
PFS è una proprietà desiderabile (se solo per le pubbliche relazioni), quindi usa DHE (o la sua variante di curva ellittica ECDHE) quando possibile. Potrebbe richiedere un po 'più di CPU e larghezza di banda, ma ci vorranno centinaia o persino migliaia di nuove sessioni TLS al secondo per notare la differenza.
SRP è qualcosa di completamente diverso. È un meccanismo di scambio chiave in cui non esiste alcun certificato. Invece, client e server condividono un valore segreto comune e si autenticano reciprocamente in relazione a quel valore segreto. È molto elegante in quanto tollera segreti ben condivisi di bassa entropia, noti anche come "password" (contrariamente ai pacchetti di crittografia "PSK" che sono più semplici ma richiedono un segreto condiviso ad alta entropia). Il principale svantaggio di SRP è che i normali browser non lo supportano (ancora).
Per le applicazioni web andrei con ECDHE_RSA come scambio preferito con DHE_RSA come fallback.
ECDHE è sicuro, efficiente e offre un alto livello di riservatezza (128 bit usando P-256). DHE è più lento e ha una sicurezza inferiore, ma alcuni browser (come Opera) non supportano ECC.
Userei ancora RSA per l'autenticazione. Il livello di sicurezza richiesto per l'autenticazione è inferiore, RSA a 1024 bit è abbastanza buono se utilizzato insieme a ECDHE. Potresti volerlo aumentare un po 'oltre il 1024, ma si tratta principalmente di PR e non di sicurezza attuale.
Con tali suite utilizzi PKI con RSA per assicurarti di parlare con il server giusto impedendo MitM e (EC) DH per lo scambio di chiavi, dandoti il segreto in avanti.
Leggi altre domande sui tag tls key-exchange