Tu descripción es un poco confusa; Veo que está hablando de "firmar con la clave pública", que es análogo a "cifrar con la clave privada", es decir, una explicación generalizada pero defectuosa que no funciona con algoritmos criptográficos asimétricos reales como se usan en la práctica. p>
Sin embargo, se puede decir que lo que parece sugerir no hace lo que cree que hace; o, más bien, SSL ya es más seguro de lo que crees. Cuando el atacante conoce la clave privada del servidor, puede suplantar el servidor: el cliente habla con el atacante, creyendo que habla con el servidor original. De manera similar, si el atacante conoce la clave privada del cliente (asumiendo que el cliente tiene una clave privada, y el servidor solicita la autenticación del cliente con un certificado), entonces puede hacerse pasar por el cliente al hablar con el servidor. Esto es genérico. Sin embargo, para realizar un verdadero ataque Man-in-the-Middle , el atacante debe hacer una doble imitación : él debe suplantar simultáneamente el servidor (cuando habla con el cliente) y suplantar al cliente (cuando habla con el servidor).
Con SSL como se define en el estándar , cuando el servidor solicita un certificado del cliente, no es un verdadero MitM factible a menos que el atacante sepa las claves secretas tanto del cliente como del servidor. El problema al que alude ("el servidor solo verifica la autenticidad del cliente") no existe realmente. Por lo tanto, su propuesta no puede resolverlo (no hay una solución posible para un problema inexistente).
De hecho, mezclar la clave pública del cliente puede empeorar las cosas. Idealmente, la clave pública del servidor tampoco debería usarse para el intercambio de claves. El motivo de esto a menudo se denomina secreto de envío (PFS). Si el servidor utiliza un intercambio de claves basado en RSA clásico, y el atacante, más adelante , roba una copia de la clave privada del servidor, entonces el atacante puede descifrar las sesiones grabadas. Esto es malo. Pero hay una solución en SSL, llamada "DHE" como "Ephemeral Diffie-Hellman". Cuando se utilizan conjuntos de cifrado DHE, el intercambio de claves real utiliza pares de claves DH que tanto el cliente como el servidor generan sobre la marcha; el servidor simplemente firma su clave pública DH utilizando su clave privada permanente. Esto proporciona PFS porque el servidor nunca almacena su clave privada DH en ningún lugar, lo que lo hace presumiblemente inmune a un robo posterior.
Podemos observar que, en SSL, la clave del cliente, cuando se usa, es solo para una firma; y eso es bueno. Esto significa que si la clave privada del cliente es robada, las sesiones anteriores siguen siendo confidenciales. El uso de un conjunto de cifrado DHE habilita la misma propiedad deseable en el lado del servidor. Esta seguridad mejorada no se obtiene al "usar el certificado del cliente para generar la clave del maestro de maestro"; todo lo contrario por cierto. Se logra al dejar de usar el certificado del servidor para generar la clave de premaster.