Certificato client in SSL HandShake non protetto?

Il certificato contiene solo la chiave pubblica: si tratta di dati pubblici. La parte importante non è il messaggio Certificate inviato dal client, ma il messaggio CertificateVerify che il client invia anche. Quel messaggio contiene una firma digitale che il cliente calcola usando la sua chiave privata e i precedenti messaggi di handshake. L'utente malintenzionato può annusare tutto ciò che desidera, non riceverà la chiave privata, che non viene inviata e non sarà in grado di calcolare un'altra firma, applicabile su un altro scambio SSL.

Anche quando il certificato del cliente è visibile, la firma fatta usando la chiave privata non può essere falsificata. Le risposte precedenti hanno fornito maggiori dettagli sul messaggio Certificate Verify , ma il principio della chiave pubblica / privata è lo stesso dei certificati server (o meccanismi crittografici asimmetrici in generale): se non si dispone della chiave privata, non è possibile impersonare l'entità a cui è stato rilasciato il certificato.

Un problema secondario dell'autenticazione del certificato client è che, se eseguito durante l'handshake iniziale, il certificato stesso è visibile agli intercettatori in chiaro. In alcuni casi, questo potrebbe non essere soddisfacente, poiché questo potrebbe rivelare l'identità dell'utente (ad esempio CN=Bob Smith ).

Un modo per mitigare questo è usare l'autenticazione client solo in un handshake rinegoziato.

Il client firmerà il proprio messaggio con la propria chiave privata che può essere decifrata usando la chiave pubblica che è condivisa apertamente e considerata attendibile come corrispondente al client. Poiché il server può decodificare queste informazioni con la chiave pubblica del client, conosce le informazioni provenienti dal client. Nel caso in cui il prossimo passo della negoziazione sia RSA, il contenuto del pacchetto è una parte di una chiave crittografata con la chiave pubblica del server, quindi solo il server può decodificare il secondo livello di crittografia.

Come per un utente malvagio che si accinge al certificato e tenta di dirottare la sessione, il server ha la chiave pubblica per l'utente e l'attaccante non sarà in grado di generare informazioni che decodificheranno con quella chiave pubblica, quindi la connessione è garantito che l'originatore della connessione continuerà ad essere il client della connessione.

Se il certificato client non è pre-condiviso, sarebbe possibile impedire che una sessione si formi con il client e sostituire la chiave pubblica di un utente malintenzionato, ma a quel punto l'utente di destinazione non si troverebbe nella sessione e non lo farebbe avere le informazioni chiave per la sessione. La stessa prevenzione MITM si applica come normale certificato server SSL dopo l'iniziale handshake, la fornitura di un certificato client garantisce semplicemente che l'identità del client rimane la stessa su una o più sessioni.

Anche qualcos'altro da considerare. Per rendere illecito il certificato di un cliente è necessario un certificato che è stato firmato da un'Autorità di certificazione - che è molto lavoro garantire per quello che sei. Il client dovrebbe fidarsi solo dei certificati che sono stati firmati da una rispettabile CA.