I have found that I can decrypt SSL traffic in Wireshark with the server's private key.

Why isn't the client's private key enough to decrypt SSL traffic?


This is because in an SSL/TLS connection the asymmetric key exchange uses the server's public key to exchange the pre-master secret. A client certificate is only used for client authentication if the server requests it. The pre-master secret is what's used to generate the session keys. This is why you need the server's private key, not the client's.

Typical SSL/TLS Key Exchange: enter image description here

Notice how in the above exchange only the server sends its certificate. The client key exchange message is the pre-master secret encrypted with the server's public key.

SSL/TLS Key Exchange w/ Client Authentication

enter image description here

In the above exchange we see that after the server sends its certificate it also provides a CertificateRequest message. This message asks the client for its public certificate. It responds with the ClientKeyExchange message as it does in a typical handshake, and then sends a ClientVerify message which signs the hashed key exchange data. The server then uses this signature to verify the client.

The client or server never uses the client's public key to encrypt any information in the handshake. Therefore it is not necessary for session decryption.


Because client uses server public key for encrypting communication during phase 4 of negotiation (wikipedia) :

4 - Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

At the end of the negotiation, both sides generate a session key for encrypting communication.

I think that wireshark, with server's private key can pick this session key during the handshake.



Clients private key is used only when using client certificate authentication and there it is used only for signing, not decryption. (if using RSA/DSA keys)(If using static DH, it could be possible, but static DH is not supported by any TLS servers or clients)


Assuming an appropriate setup of the SSL/TLS parameters on the side of the server (or theoretically client, but that is harder and doesn't have to always work) having the servers private key should still not allow you to decrypt any traffic unless you are performing an active attack.

It really depends on if Forward Security (FS) was negotiated between client and server. There's no guarantee that the client negotiates a forward security algorithm. IE is notoriously bad at choosing a FS algorithm, and relies on the server to prioritize the various options. So if you're very careful in setting up your SSL options on the server, AND your server supports prioritizing one algorithm over another, then it's possible to get Forward Security negotiated on even IE.

(Qualsys has an excellent tool that simulates major browser negotiation with websites.) https://www.ssllabs.com/ssltest/index.html

Essentially all the other major browsers (Chrome, Firefox, Safari, etc) generally choose forward security if the server supports it, so decryption with just the private key of the server isn't possible.

  • Hi.  I was reading your answer to this question, I went to your profile page to check out the picture, and so I read your blurb. For what’s it’s worth, I partially agree with you about Stack Exchange — it’s not terrible, but it could use some improvement. I’m pinging you to tell you that Michael T. Richter’s blog has gone away, but it can be seen on the Wayback Machine here. – Scott Jun 9 at 21:08
  • 1
    @Scott Thanks for your reply. I guess that link has been broken for a while. I fixed it by linking to archive.org. Reading this particular answer, it's aging a bit, and I'm no longer sure if recent versions of IE negotiate FS any better. – Steve Sether Jun 10 at 17:31

Raz's answer gives a very good overview of your particular situation. It should however be mentioned that, if the server's private key allows you to actually decrypt the communication without performing a MITM attack your SSL/TLS is set up badly.

Assuming an appropriate setup of the SSL/TLS parameters on the side of the server (or theoretically client, but that is harder and doesn't have to always work) having the servers private key should still not allow you to decrypt any traffic unless you are performing an active attack.

Using DHE (Diffie-Hellman exchange) or ECDHE (the same above elliptic curves) for key exchange (actually exchanging the master secret from which the keys are generated) brings a marked increase in security at almost no cost to performance or usability.

  • A bit offtopic, but... what about ECDHE and youtube.com/watch?v=ulg_AHBOIQU ? Is it still "safe"? – Wojtek Sep 23 '14 at 7:53
  • @Wojtek I haven't had a chance to actually watch the whole video (hopefully in the evening) but from the links and a cursory scan it seems to be about the EC-DRBG hoohaa. That though has nothing to do with ECDHE in itself. It is just a possible backdoor in a random number generator that happens to also use eliptic curves. You can (and most probably do) use any other random number generator for the ECDHE key exchange. The similarity is only in the name. – DRF Sep 23 '14 at 10:52
  • @Wojtek Also quite offtopic, I would like to point out that trying to stay safe from the NSA (or any other large nation state security agency) is probbably a losing battle for any individual. The best you can do is try to minimize your exposure to the large collection methods but if you're being targeted you're pretty much toast. They won't be attacking the crypto if they want to know what you are doing. That's very bad ROI. – DRF Sep 23 '14 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.