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" 
...edited...
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)
     Random
      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.

Comments

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*
8:09 PM
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.
9:07 PM
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. :)
9:50 AM
Anonymous said…
lonervamp,

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.
10:27 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more