¿Por qué no puedo descifrar el tráfico SSL solo con la clave privada del cliente?

Esto se debe a que, en una conexión SSL / TLS, el intercambio de claves asimétricas utiliza la clave pública del servidor para intercambiar el secreto maestro previo. Un certificado de cliente solo se utiliza para la autenticación del cliente si el servidor lo solicita. El secreto pre-maestro es lo que se utiliza para generar las claves de sesión. Es por eso que necesita la clave privada del servidor, no la del cliente.

Intercambio de claves SSL / TLS típico :

Observequeenelintercambioanteriorsoloelservidorenvíasucertificado.Elmensajedeintercambiodeclavedelclienteeselsecretomaestropreviocifradoconlaclavepúblicadelservidor.

Intercambio de claves SSL / TLS con autenticación del cliente

En el intercambio anterior, vemos que después de que el servidor envía su certificado también proporciona un mensaje de solicitud de certificado. Este mensaje le pide al cliente su certificado público. Responde con el mensaje ClientKeyExchange como lo hace en un típico protocolo de enlace, y luego envía un mensaje ClientVerify que firma los datos de intercambio de clave hash. El servidor usa esta firma para verificar el cliente.

El cliente o servidor nunca usa la clave pública del cliente para cifrar cualquier información en el protocolo de enlace. Por lo tanto, no es necesario para el descifrado de sesión.

Debido a que el cliente utiliza la clave pública del servidor para cifrar la comunicación durante la fase 4 de negociación (wikipedia):

  

4 - Utilizando todos los datos generados en el protocolo de enlace hasta el momento, el cliente   (con la colaboración del servidor, dependiendo del cifrado en uso)   crea el secreto pre-master para la sesión, lo cifra con el   clave pública del servidor (obtenida del certificado del servidor, enviada en   paso 2), y luego envía el secreto pre-master cifrado al servidor.

Al final de la negociación, ambas partes generan una clave de sesión para cifrar la comunicación.

Creo que Wirehark, con la clave privada del servidor, puede elegir esta clave de sesión durante el protocolo de enlace.

Cedric.

La clave privada de los clientes se usa solo cuando se usa la autenticación del certificado del cliente y allí se usa solo para firmar, no para descifrar. (si usa claves RSA / DSA) (si usa DH estático, podría ser posible, pero DH no está soportado por ningún servidor o cliente TLS)

  

Suponiendo una configuración adecuada de los parámetros SSL / TLS en el lado de   El servidor (o teóricamente cliente, pero eso es más difícil y no lo hace).   tener que trabajar siempre) tener la clave privada del servidor todavía no debería   Le permite descifrar cualquier tráfico a menos que esté realizando una activa   ataque.

Realmente depende de si Forward Security (FS) se negoció entre el cliente y el servidor. No hay garantía de que el cliente negocie un algoritmo de seguridad hacia adelante. IE es notoriamente malo en la elección de un algoritmo FS, y confía en el servidor para priorizar las diversas opciones. Por lo tanto, si tiene mucho cuidado al configurar sus opciones SSL en el servidor, Y su servidor admite la priorización de un algoritmo sobre otro, entonces es posible obtener una Seguridad Avanzada negociada incluso en IE.

(Qualsys tiene una excelente herramienta que simula una gran negociación del navegador con sitios web). enlace

Esencialmente, todos los demás navegadores principales (Chrome, Firefox, Safari, etc.) generalmente eligen la seguridad de reenvío si el servidor lo admite, por lo que no es posible descifrar solo con la clave privada del servidor.

La respuesta de Raz le da una muy buena visión general de su situación particular. Sin embargo, debe mencionarse que, si la clave privada del servidor le permite descifrar realmente la comunicación sin realizar un ataque MITM, su SSL / TLS está mal configurado.

Suponiendo una configuración adecuada de los parámetros SSL / TLS en el lado del servidor (o en teoría, el cliente, pero eso es más difícil y no siempre tiene que funcionar) tener la clave privada del servidor no debería permitirle descifrar ningún tráfico a menos que esté realizando un ataque activo.

El uso de DHE (intercambio Diffie-Hellman) o ECDHE (las mismas curvas elípticas anteriores) para el intercambio de claves (en realidad el intercambio del secreto maestro a partir del cual se generan las claves) produce un aumento notable en la seguridad casi sin costo para el rendimiento o la facilidad de uso. .