Perché i certificati client non sono protetti da una convalida del certificato server non valida

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.

Il punto chiave è che un server falso non può impersonare il client.

Supponiamo che vogliate connettervi a goodguy.com e inviare il vostro cert cliente. Ma a causa di un tentativo di attacco MITM, ci si connette effettivamente a badguy.com, e poiché non si controlla il certificato del server, non si nota, e si autentica utilizzando il certificato cliente. A questo punto, badguy.com può mostrarti qualsiasi pagina web che gli piace, in modo che possano fornirti informazioni fuorvianti e tentare di acquisire informazioni da te. Ma ciò che non possono fare è connettersi a goodguy.com e utilizzare il certificato client per impersonare te.

La ragione per cui badguy.com non può inoltrare la tua autenticazione è perché i certificati SSL sono basati sulla crittografia a chiave pubblica. Quando esegui l'autenticazione, provi che hai la chiave privata associata al certificato, ma non rivelerai la chiave privata.