L'autenticazione del client basata su certificato in SSL assume il seguente formato: il client mostra le proprie catene di certificati e calcola una firma su tutti i messaggi di handshake scambiati in precedenza. Questi messaggi di handshake includono il messaggio in cui il server invia la catena di certificati al client.
In questo modo, il server può assicurarsi che il client (colui che possiede il certificato client mostrato) abbia visto il certificato del server corretto, non uno falso. In questo senso, richiedere un'autenticazione client basata su certificati può impedire un vero Man-in-the-Middle (se il tuo "test" mostra altrimenti o hai rotto SSL, o c'è qualcosa di leggermente sbagliato nella tua situazione di test). Tuttavia, il diavolo è nei dettagli ...
Un attacco MitM è una doppia impersonificazione simultanea : l'attaccante esegue sia un server falso (quando parla al client) sia un client falso (quando parla al server). Un vero MitM viene impedito fintanto che il client o il server verifica correttamente il certificato dal peer, il che implica convalidare il certificato (verificando che sia stato emesso da una CA affidabile e così via) e anche usando il nome nel certificato come identità del peer (un client si connette a qualche indirizzo IP ma il certificato riguarda una garanzia per un nome del server ).
Tuttavia, ci sono altri tipi di attacco che, pur non essendo MitM in senso stretto, possono essere fastidiosi. Ad esempio, se il client non esegue una convalida corretta del certificato del server, l'utente malintenzionato può eseguire un server falso e parlare con il client. Il vero server non è affatto coinvolto! Questo genere di cose non è un MitM originale, ma può essere sufficiente per recuperare alcuni segreti del client (il client ritiene che sia connesso al server corretto e quindi invia dati sensibili attraverso il tunnel).
Non c'è nulla che il server possa fare per garantire che un client convalidi sempre correttamente il certificato del server - in particolare quando il server non è affatto contattato, perché il client si sta connettendo a un server falso, gestito da un aggressore. Nella migliore delle ipotesi, il server può assicurarsi, tramite autenticazione client basata su certificato, che il client per questa volta utilizzi la chiave pubblica server corretta per la sua crittografia.