Can you decrypt incoming SSL traffic?

Question

There's a question similar to this, but it asks if you simply can decrypt SSL with the certificate.

So my question is, if you capture all traffic from a device using Wireshark then shouldn't you have at least enough information to decrypt incoming traffic? What I've heard is that the server sends a public key which the computer uses to generate a symmetric key to encrypt data which can only be decrypted on the server. But then if everything is encrypted, how does the browser decrypt incoming traffic? And can't that be intercepted, or how how else is the browser going to be able to decrypt what the server sends?

I also used Fiddler and it seems that Fiddler can read https traffic when I'm on facebook and stuff, so how does that exactly work then?

Answer 1

No. You can't decrypt if you have all the traffic. Even if you have the private key of the certificate, the private key is only used to authenticate. The keys that the traffic is encrypted with are generated during the handshake by the communicating programs (the server and your browser). Therefore, your browser has the encryption keys in memory, which allows it to decrypt the traffic. No other program running on the same machine will have them. This includes Wireshark.

If you have the private key, then you can stage a man-in-the-middle attack (i.e. you're essentially a proxy). In this case you (or whatever program like e.g. Fiddler) will generate the encryption keys and therefore it can decrypt the traffic.

To summarize, you need an active attacker instead of a passive attacker. A passive attacker that has just copied all the data transferred during a session can't decrypt it even if given the long-term private keys of both parties (i.e. the private keys of the certificates).

EDIT: As a clarification, if using bad cipher suites, then knowing the RSA private keys does allow decrypting traffic. This is why the ephemeral DH suites should be used. Post Heartbleed this will hopefully become the norm.

Answer 2

Fiddler acts as a man-in-the-middle: it sends its own self-generated certificates, with its own private/public key pairs, to the client. Hence, when the client sends the symmetric key to the Fiddler, it does so using the public key that matches the private key that Fiddler itself already has. See What is point of SSL if fiddler 2 can decrypt all calls over HTTPS? to understand how the browser can be configured to allow this.

After Fiddler gets the decrypted traffic, it resends the requests to the server, pretending to the server like it is the client, using the server's public key to encrypt a new symmetric key that is used to talk from Fiddler to the server.

[Client] -FiddlerPublicKey(SymmetricKey1)--> [Fiddler] -ServerPublicKey(SymmetricKey2)--> [Server]

In contrast, Wireshark can decrypt the traffic when you provide it with the server's private key; it can look for the message where the client sends the symmetric key and decrypt it using the (normally secret) private key that the server ordinarily holds.

Answer 3

The public and private key (assymetric encryption) are used to generatea shared key that is the same for both sides (symmetric encryption). One of the reasons for this is because symmetric encryption is much faster than asymmetric.

Can Wireshark decrypt SSL streams? Yes - even though the data is intended for the browser, Wireshark can decrypt it if the encryption key can be provided:

The SSL dissector is fully functional and even supports advanced features such as decryption of SSL if the encryption key can be provided and Wireshark is compiled against GnuTLS (rather than OpenSSL or bsafe). This works for RSA private keys.

This can be a bit of a pain, however it's necessary since the SSL was intended for end-to-end encryption, meaning only the browser and the server should be able to decipher the message.

EDIT: Fiddler is able to decrypt your SSL by acting as a proxy for your requests (something which wireshark does not do).