3

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?

Muhatashim
  • 646
  • 8
  • 22
  • The keys are not actually sent. They are embedded with the browser itself. Hence we need to regularly update the browsers as and when new ssls are shared. – unbesiegbar Jun 15 '14 at 17:25
  • This is just some basic info.. I hope someone gives a good description for your question – unbesiegbar Jun 15 '14 at 17:25
  • 2
    This question appears to be off-topic because it is not about programming. Perhaps [Super User](http://superuser.com/) or [Information Security Stack Exchange](http://security.stackexchange.com/) would be a better place to ask. – jww Jun 16 '14 at 01:08
  • See the Wireshark wiki at [Secure Socket Layer (SSL)](http://wiki.wireshark.org/SSL). You need the premaster secret to derive the six keys used in the connection (Encryption keys, HMAC keys, and initial IVs). – jww Jun 16 '14 at 01:09

3 Answers3

4

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.

Community
  • 1
  • 1
EricLaw
  • 56,563
  • 7
  • 151
  • 196
0

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).

Martin Konecny
  • 57,827
  • 19
  • 139
  • 159
  • Sorry, my grammar on the symmetric key got mixed up. I just fixed that part too. So what I'm understanding is that the browser has some built in deciphering code to decipher the incoming traffic that other programs don't have? – Muhatashim Jun 15 '14 at 17:36
  • I misunderstood the context of that question, but yes you're right. I'll remove that part to avoid any confusion. – Martin Konecny Jun 16 '14 at 19:13
0

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.

Edvard Fagerholm
  • 862
  • 5
  • 15
  • 1
    If you have the server private key, all the recorded traffic and if a PFS cipher suites (such as DHE) is not used, you **can** decrypt the communication. – Bruno Jun 17 '14 at 14:43
  • Yes, it depends on the AKE protocol. I'm assuming the server is using a reasonably modern one. – Edvard Fagerholm Jun 17 '14 at 15:06
  • It's not really a matter of being modern. Not all servers enable DHE, even now. – Bruno Jun 17 '14 at 15:09
  • That is unfortunately true. From a pure cryptographic point of view it's unfortunate that fairly ancient algorithms are used a lot in practice. In other words, I'm referring to modern as in a modern AKE protocol, not modern as in servers out there. – Edvard Fagerholm Jun 17 '14 at 15:13