Pourquoi ne puis-je pas décrypter le trafic SSL avec la clé privée du client uniquement?
J'ai découvert que je peux décrypter le trafic SSL dans Wireshark avec la clé privée du serveur .
Pourquoi la clé privée du client n'est-elle pas suffisante pour déchiffrer le trafic SSL?
En effet, dans une connexion SSL/TLS, l'échange de clés asymétrique utilise la clé publique du serveur pour échanger le secret pré-maître. Un certificat client n'est utilisé pour l'authentification client que si le serveur le demande. Le secret pré-maître est utilisé pour générer les clés de session. C'est pourquoi vous avez besoin de la clé privée du serveur, pas de celle du client.
échange de clés SSL/TLS typique : 
Remarquez que dans l'échange ci-dessus, seul le serveur envoie son certificat. Le message d'échange de clé client est le secret pré-maître chiffré avec la clé publique du serveur.
Échange de clés SSL/TLS avec authentification client
Dans l'échange ci-dessus, nous voyons qu'après que le serveur a envoyé son certificat, il fournit également un message CertificateRequest. Ce message demande au client son certificat public. Il répond avec le message ClientKeyExchange comme il le fait dans une poignée de main typique, puis envoie un message ClientVerify qui signe les données d'échange de clé hachée. Le serveur utilise ensuite cette signature pour vérifier le client.
Le client ou le serveur n'utilise jamais la clé publique du client pour crypter les informations de la négociation. Par conséquent, il n'est pas nécessaire pour le déchiffrement de session.
Parce que le client utilise la clé publique du serveur pour crypter la communication pendant la phase 4 de la négociation (wikipedia):
4 - En utilisant jusqu'à présent toutes les données générées dans la prise de contact, le client (avec la coopération du serveur, en fonction du chiffre utilisé) crée le secret pré-maître pour la session, le chiffre avec la clé publique du serveur (obtenue à partir du certificat du serveur, envoyé à l'étape 2), puis envoie le secret pré-maître chiffré au serveur.
À la fin de la négociation, les deux parties génèrent une clé de session pour crypter la communication.
Je pense que Wireshark, avec la clé privée du serveur, peut choisir cette clé de session pendant la prise de contact.
Cédric.
La clé privée du client est utilisée uniquement lors de l'utilisation de l'authentification par certificat client et elle n'est utilisée que pour la signature, pas le déchiffrement. (si vous utilisez des clés RSA/DSA) (Si vous utilisez un DH statique, cela pourrait être possible, mais le DH statique n'est pris en charge par aucun serveur ou client TLS)
En supposant une configuration appropriée des paramètres SSL/TLS du côté du serveur (ou théoriquement client, mais cela est plus difficile et ne doit pas toujours fonctionner), la possession de la clé privée des serveurs ne devrait toujours pas vous permettre de décrypter le trafic, sauf si vous effectuent une attaque active.
Cela dépend vraiment si Forward Security (FS) a été négocié entre le client et le serveur. Il n'y a aucune garantie que le client négocie un algorithme de sécurité avant. IE est notoirement mauvais pour choisir un algorithme FS, et s'appuie sur le serveur pour prioriser les différentes options. Donc, si vous êtes très prudent dans la configuration de votre Options SSL sur le serveur ET votre serveur prend en charge la priorité d'un algorithme sur un autre, il est alors possible de négocier la sécurité avancée sur IE.
(Qualsys dispose d'un excellent outil qui simule les principales négociations du navigateur avec les sites Web.) https://www.ssllabs.com/ssltest/index.html
Essentiellement, tous les autres principaux navigateurs (Chrome, Firefox, Safari, etc.) choisissent généralement la sécurité avancée si le serveur la prend en charge, donc le déchiffrement avec uniquement la clé privée du serveur n'est pas possible.
La réponse de Raz donne un très bon aperçu de votre situation particulière. Il convient toutefois de mentionner que si la clé privée du serveur vous permet de décrypter réellement la communication sans effectuer d'attaque MITM, votre SSL/TLS est mal configuré.
En supposant une configuration appropriée des paramètres SSL/TLS du côté du serveur (ou théoriquement client, mais cela est plus difficile et ne doit pas toujours fonctionner), la possession de la clé privée des serveurs ne devrait toujours pas vous permettre de décrypter le trafic, sauf si vous effectuent une attaque active.
L'utilisation de DHE (échange Diffie-Hellman) ou ECDHE (les mêmes courbes elliptiques ci-dessus) pour l'échange de clés (échangeant en fait le secret principal à partir duquel les clés sont générées) apporte une augmentation marquée de la sécurité presque sans coût pour les performances ou la convivialité.