Se il client accetta qualsiasi certificato come certificato di un server valido, un utente malintenzionato attivo può impersonare il server quando parla al client.
Se l'utente malintenzionato può rubare una copia della chiave privata del client, può impersonare il client quando parla al server.
Se entrambe le condizioni sono valide, l'attaccante può eseguire un attacco Man-in-the-Middle , per definizione: un attacco MitM non è altro che una doppia impersonificazione simultanea. L'utente malintenzionato si pone come client quando parla al server e come server quando parla al client; inoltra il traffico in entrambe le direzioni, ispezionando e modificando i dati a piacimento.
Se il client può assicurarsi che utilizzi il certificato del server originale (tramite la convalida da una CA radice affidabile riconosciuta o forse perché il client ricorda il certificato del server da una connessione precedente), quindi il client rifiuterà il tentativo di impersonificazione e il MitM non funzionerà. L'autore dell'attacco, che ha rubato la chiave privata del client, sarà comunque in grado di sostituire il client, ad es. dirottare le chiamate in entrata, ma questo non sarà un vero MitM (l'attaccante dovrà imitare la voce del normale proprietario del client).
Si noti che se l'utente malintenzionato non ha una copia della chiave privata del client, e il server convalida in qualche modo la chiave pubblica del client (ad esempio il server si ricorda chiave pubblica del client dopo un passaggio di configurazione iniziale), quindi l'utente malintenzionato non sarà in grado di impersonare il client. L'autenticazione del client in SSL è tale che anche se l'utente malintenzionato impersona il server, non può riutilizzare i messaggi da un client credulone per ingannare il server vero. Tecnicamente, il client usa la sua chiave privata per firmare una "sfida" che è un valore hash calcolato su tutto il client e il server si sono inviati l'un l'altro finora, e questo include il certificato del server; quindi, in caso di MitM, il client firmerà i messaggi contenenti la chiave pubblica dell'attaccante (il falso certificato del server inviato dall'attaccante), non il certificato inviato dal server vero e la firma non corrisponderà a ciò che il server vero si aspetta. / p>
Quindi, se il client può assicurarsi che usi il vero certificato del server, o il server può assicurarsi che usi il certificato del client vero, o entrambi , quindi un tentativo di MitM completo deve fallire. Tuttavia, anche senza un MitM, la rappresentazione (una "metà-MitM") è ancora possibile:
- Se l'utente malintenzionato ruba la chiave privata del server o il client non riesce a convalidare il certificato del server, l'autore dell'attacco può impersonare il server.
- Se l'utente malintenzionato ruba la chiave privata del client o il server non riesce a convalidare il certificato del client, l'utente malintenzionato può impersonare il client.
Infine, se l'autore dell'attacco ha una copia della chiave privata del server , e la suite di crittografia SSL / TLS è una delle suite RSA non DHE, quindi la l'attaccante può decrittografare tutti i dati dopo l'intercettazione passiva e può anche dirottare la connessione in qualsiasi momento dopo l'handshake, il che consente, di nuovo, un MitM. Lo stesso non vale per la chiave privata del client rubata; in SSL / TLS, il certificato client e la chiave privata vengono utilizzati solo per l'autenticazione, non per lo scambio di chiavi e non hanno alcuna influenza sul segreto risultante utilizzato per la crittografia dei dati effettiva.