Wireshark Display Filters and SSL

I mentioned the power of Wireshark display filters when analyzing 802.11 last year. Now I read Ephemeral Diffie Hellman support - NOT ! by the Unsniff guys and they tell me that they cannot decode SSL traffic which uses the ephemeral Diffie-Hellman cipher suite. I wonder what that looks like in traffic?

Thanks to Wireshark display filters, I can find a suitable packet. Here's a matching packet.
You could use syntax like this with Tshark:

tshark -V -n -r capture -R "ssl.handshake.ciphersuite == 0x39"
Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
gmt_unix_time: Jan 26, 2007 19:32:44.000000000
random_bytes: 76744E818415307EA6F7C14FAF4BA640F67834C1263E5065...
Session ID Length: 32
Session ID (32 bytes)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Compression Method: null (0)
Maybe some of you crypto gurus can comment on their blog post -- is it possible to decrypt traffic if the cipher suite is TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037) instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)? The cited perfect forward secrecy article says Diffie-Hellman provides PFS but isn't clear on the differences between plain DH and DHE (ephemeral).

From what I read in Cryptography Decrypted, SSL/TLS uses Diffie-Hellman to create a shared pre-master secret key and six shared secret keys. Anonymous DH doesn't require either side to authenticate each other. Fixed or static DH exchanges public DH values using digital certs. Ephemeral DH exchanges public DH values signed with RSA or DSA keys. What does this mean for decryption using Wireshark, etc.? Thank you.


Anonymous said…
The blog you cite says they can break DH. Sure, but you need the private key used in that exchange from at least one of the partys(say, A). If you have that key you can just use it as exponent for the public value of the other party(B). Just like A would do it.

This private key you need differs for DH and EDH.

For DH, your secret is the private key of the certificate that you use. The peer will decrypt this with the public key of your certificate. You're authenticated at this very moment, different certificates with different public keys won't work, DH would produce different keys for the two parties.

For EDH, your secret is a random value that you only need as long as the handshake takes. The key-pair of your certificate is only used for authentication, eg you can in addition sign your public value.

After an (E)DH key agreement, there are always exatly two parties posessing the resulting key. You need authentication to make sure they are the right two parties and not A-Attacker and Attacker-B.

Simple DH is probably pretty old. It took a moment for me to realise that it's the stupid variant of what I learned in my studies during the last few years.

Now, did I earn one of your many books? *g*
Anonymous said…
SSL decryption in Wireshark or SSLdump requires you to own the private keys used to decrypt the connection.

In an EDH, no such keys exist. It's a straight DH exchange, with randomly generated keys.

In a straight DH exchange, this would be vulnerable to MITM attacks (the snoop would simply complete DH exchanges with both sides of the connection, deriving two different keys, and translate etween the two).

EDH uses the cert keypairs to guarantee that the DH exchange happened without an MITM tampering.

EDH has "perfect forward secrecy" because no stationary set of keys is used to protect all the sessions. If you compromise the server key, all you get is the ability to sign DH parameters in a future session.
Unknown said…
Interesting...this might actually answer a question I had about my alert-based IDS/IPS. Some SSL connections were not getting decrypted properly recently. The sensor itself doesn't even log a single packet for this alert unless I customize it (trying to get more than one packet is like pulling teach from a pit bull).

Hopefully I can get another alert here soon and check the cipher suite field...interesting. :)
Anonymous said…

There is more.

The failure to decrypt is not just with Diffie Hellman Ephemeral. The decryption method used by Wireshark, ssldump, unsniff will not work for exportable RSA keys either (i.e less than 1024 bit).

This is because a temporary RSA key exchange takes place to negotiate a exportable cipher. This is just like DHE, but for weaker encryption and uses RSA.

This may sound weird, but the so called weak export ciphers are actually immune to decryption using tools like Wireshark / ssldump / unsniff etc.

However unlike DHE , RSA "ephemeral" for export is vulnerable to brute force. This means agencies like NSA in the United States can simply brute force keys like DES56, irrespective of the key exchange strength !

A hobby attacker, or someone who has stolen server keys, can certainly not brute force an export cipher like DES56 very easily.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia