Perché non è possibile decodificare il traffico SSL solo con la chiave privata del client?

Questo perché in una connessione SSL / TLS lo scambio di chiavi asimmetriche utilizza la chiave pubblica del server per scambiare il segreto pre-master. Un certificato client viene utilizzato solo per l'autenticazione del client se il server lo richiede. Il segreto pre-master è ciò che viene utilizzato per generare le chiavi di sessione. Ecco perché è necessaria la chiave privata del server, non quella del client.

Scambio chiave SSL / TLS tipico :

Sinoticomenelloscambiodicuisoprasoloilserverinviailpropriocertificato.Ilmessaggiodiscambiochiavedelclientèilsegretopre-mastercrittografatoconlachiavepubblicadelserver.

Scambio chiave SSL / TLS con autenticazione client

Nello scambio sopra riportato vediamo che dopo che il server ha inviato il suo certificato, fornisce anche un messaggio di richiesta di certificato. Questo messaggio chiede al client il suo certificato pubblico. Risponde al messaggio ClientKeyExchange come avviene in un tipico handshake e quindi invia un messaggio ClientVerify che firma i dati di scambio della chiave hash. Il server utilizza quindi questa firma per verificare il client.

Il client o il server non utilizza mai la chiave pubblica del client per crittografare le informazioni nell'handshake. Pertanto non è necessario per la decrittazione della sessione.

Poiché il client utilizza la chiave pubblica del server per crittografare le comunicazioni durante la fase 4 della negoziazione (wikipedia):

4 - Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

Alla fine della negoziazione, entrambe le parti generano una chiave di sessione per la crittografia delle comunicazioni.

Penso che wireshark, con la chiave privata del server, possa prendere questa chiave di sessione durante l'handshake.

Cedric.

La chiave privata dei client viene utilizzata solo quando si utilizza l'autenticazione del certificato client e lì viene utilizzata solo per la firma e non per la decrittografia. (se si usano le chiavi RSA / DSA) (Se si utilizza il DH statico, potrebbe essere possibile, ma il DH statico non è supportato da alcun server o client TLS)

Assuming an appropriate setup of the SSL/TLS parameters on the side of the server (or theoretically client, but that is harder and doesn't have to always work) having the servers private key should still not allow you to decrypt any traffic unless you are performing an active attack.

Dipende molto da se Forward Security (FS) è stato negoziato tra client e server. Non c'è alcuna garanzia che il cliente negozi un algoritmo di sicurezza forward. IE è notoriamente pessima nella scelta dell'algoritmo di FS e si affida al server per dare la priorità alle varie opzioni. Quindi se stai molto attento nell'impostare le tue opzioni SSL sul server, E il tuo server supporta la prioritizzazione di un algoritmo rispetto a un altro, allora è possibile negoziare la Sicurezza in avanti anche su IE.

(Qualsys ha uno strumento eccellente che simula le principali negoziazioni del browser con i siti Web.) link

Essenzialmente tutti gli altri browser principali (Chrome, Firefox, Safari, ecc.) in genere scelgono la sicurezza di inoltro se il server lo supporta, quindi la decrittazione con solo la chiave privata del server non è possibile.

La risposta di Raz offre un'ottima panoramica della tua situazione particolare. Va tuttavia ricordato che, se la chiave privata del server consente di decrittografare effettivamente la comunicazione senza eseguire un attacco MITM, SSL / TLS è impostato male.

Supponendo una configurazione appropriata dei parametri SSL / TLS sul lato del server (o teoricamente il client, ma che è più difficile e non deve sempre funzionare) avere la chiave privata dei server non dovrebbe comunque consentire di decodificare qualsiasi traffico a meno che tu non stia effettuando un attacco attivo.

L'utilizzo di DHE (scambio Diffie-Hellman) o ECDHE (le stesse curve ellittiche sopra) per lo scambio di chiavi (in realtà lo scambio del segreto principale da cui vengono generate le chiavi) porta un marcato aumento della sicurezza quasi senza costi per prestazioni o usabilità .