La tua descrizione è un po 'confusa; Vedo che stai parlando di "firmare con la chiave pubblica" che è analogo a "crittografia con la chiave privata", ovvero una spiegazione diffusa ma imperfetta che non funziona realmente con algoritmi crittografici asimmetrici reali come vengono usati nella pratica.
Tuttavia, si può affermare che ciò che sembra suggerire non fa ciò che credi; o, piuttosto, SSL è già più sicuro di quanto credi. Quando l'utente malintenzionato conosce la chiave privata del server, può impersonare il server: il client parla con l'autore dell'attacco, ritenendo che parli al server originale. Allo stesso modo, se l'utente malintenzionato conosce la chiave privata del client (supponendo che il client abbia una chiave privata e il server chieda l'autenticazione del client con un certificato), può impersonare il client quando parla con il server. Questo è generico. Tuttavia, al fine di ottenere un vero attacco Man-in-the-Middle , l'attaccante deve fare una doppia imitazione : deve impersonare simultaneamente il server (quando parla al client) e impersonare il client (quando parla al server).
Con SSL come definito dallo standard , quando il server richiede un certificato dal client, un vero MitM non è fattibile a meno che l'attaccante non conosca le chiavi segrete sia del client che del server. Il problema a cui alludi ("il server controlla solo l'autenticità del client") in realtà non esiste. Pertanto, la tua proposta non può risolverlo (non esiste una soluzione possibile per un problema inesistente).
In effetti, unire in qualche modo la chiave pubblica del client può peggiorare le cose. Idealmente, la chiave pubblica del server non dovrebbe essere utilizzata neanche per lo scambio di chiavi. Il motivo è spesso chiamato inoltro segreto (PFS). Se il server utilizza un classico scambio di chiavi basato su RSA e l'autore dell'attacco, in seguito , ruba una copia della chiave privata del server, quindi l'attaccante può decrittografare le sessioni registrate in passato. Questo non va bene. Ma c'è una correzione in SSL, chiamata "DHE" come "Ephemeral Diffie-Hellman". Quando si utilizzano le suite di crittografia DHE, lo scambio di chiavi effettivo utilizza coppie di chiavi DH che sia client che server generano al volo; il server semplicemente firma la sua chiave pubblica DH usando la sua chiave privata permanente. Questo fornisce PFS perché il server non memorizza mai la sua chiave privata DH da nessuna parte, rendendolo presumibilmente immune da ulteriori furti.
Potremmo notare che, in SSL, la chiave del client, quando usata, è solo per una firma; e questo è buono. Significa che se la chiave privata del client viene rubata, le sessioni precedenti rimangono riservate. L'utilizzo di una suite di crittografia DHE abilita la stessa proprietà desiderabile sul lato server. Questa maggiore sicurezza non si ottiene "utilizzando il certificato client per generare la chiave premaster"; anzi, al contrario. Si ottiene cessando di utilizzare il certificato del server per generare la chiave premaster.