¿El certificado de cliente en SSL HandShake no es seguro?

El certificado solo contiene la clave pública, que son datos públicos. La parte importante no es el mensaje Certificate que envía el cliente, sino el mensaje CertificateVerify que también envía el cliente. Ese mensaje contiene una firma digital que el cliente computa usando su clave privada, y sobre los mensajes anteriores. El atacante puede olfatear todo lo que quiera, no obtendrá la clave privada, que no se envía, y no podrá calcular otra firma, aplicable sobre otro intercambio de SSL.

Incluso cuando el certificado del cliente está visible, la firma realizada con la clave privada no se puede falsificar. Las respuestas anteriores dieron más detalles sobre el mensaje Certificate Verify , pero el principio de clave pública / privada es el mismo que para los certificados de servidor (o mecanismos criptográficos asimétricos en general): si no tiene la clave privada, no puede hacerse pasar por la entidad a la que se emitió el certificado.

Un problema secundario de la autenticación del certificado del cliente es que, si se hace durante el protocolo inicial, el certificado es visible para el intruso. En algunos casos, esto puede no ser satisfactorio, ya que puede revelar la identidad del usuario (por ejemplo, CN=Bob Smith ).

Una forma de mitigar esto es usar la autenticación del cliente solo en un protocolo de negociación renegociado.

El cliente firmará su mensaje con su clave privada que se puede descifrar usando la clave pública que se comparte abiertamente y se confía en que corresponda al cliente. Dado que el servidor puede descifrar esta información con la clave pública del cliente, sabe que la información provino del cliente. En el caso de que el siguiente paso de la negociación sea RSA, el contenido del paquete es una parte de una clave cifrada con la clave pública del servidor, por lo que solo el servidor puede descifrar el segundo nivel de cifrado.

En cuanto a un usuario deshonesto que retira el certificado y trata de secuestrar la sesión, el servidor tiene la clave pública del usuario y el atacante no podrá generar información que descifre con esa clave pública, por lo que la conexión se garantiza que el originador de la conexión continuará siendo el cliente de la conexión.

Si el certificado del cliente no se comparte previamente, sería posible evitar que se forme una sesión con el cliente y en su lugar sustituir la clave pública de un atacante, pero en ese momento el usuario objetivo no estaría en la sesión y no lo haría. Tener la información clave para la sesión. La misma prevención de MITM se aplica como SSL de certificado de servidor normal después del protocolo de enlace inicial, la provisión de un certificado de cliente simplemente garantiza que la identidad del cliente permanezca igual en una o más sesiones.

También algo más a tener en cuenta. Para hacer ilícito el certificado de un cliente, necesita un certificado que haya sido firmado por una Autoridad de Certificación, cuyo trabajo es responder por quién es usted. El cliente solo debe confiar en los certificados que han sido firmados por una CA con reputación.