Decrypting TLS in Wireshark when using DHE_RSA ciphersuites

Question

How can I decrypt TLS messages when an ephemeral Diffie-Hellman ciphersuite is used? I am able to expose the premaster secret and master secret from the SSL Client. Using that, how to decrypt the messages in Wireshark?

Answer 1

Some background: Wireshark supports decryption of SSL sessions when the master secret can be calculated (which can be derived from a pre-master secret). For cipher suites using the RSA key exchange, the private RSA key can be used to decrypt the encrypted pre-master secret.

For ephemeral Diffie-Hellman (DHE) cipher suites, the RSA private key is only used for signing the DH parameters (and not for encryption). These parameters are used in a DH key exchange, resulting in a shared secret (effectively the pre-master secret which is of course not visible on the wire).

Wireshark supports various methods to decrypt SSL:

• By decrypting the pre-master secret using a private RSA key. Works for RSA key exchanges and subject to the above limitation.

• Using a SSL keylog file which maps identifiers to master secrets. The available identifiers are:

  • The first 8 bytes (16 hex-encoded chars) of an encrypted pre-master secret (as transmitted over the wire in the ClientKeyExchange handshake message). (RSA XXX YYY, since Wireshark 1.6.0)
  • The 32 bytes (64 bytes hex-encoded chars) within the Random field of a Client Hello handshake message. (CLIENT_RANDOM XXX YYY, since Wireshark 1.8.0)
    • A variant that maps the Client Random to a pre-master secret (rather than master-secret) also exists. (PMS_CLIENT_RANDOM XXX ZZZ, since Wireshark 2.0)
    • Another variant exists to support TLS 1.3 and maps the Client Random to respective secrets. Instead of CLIENT_RANDOM, the key is one of CLIENT_EARLY_TRAFFIC_SECRET, CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_HANDSHAKE_TRAFFIC_SECRET, CLIENT_TRAFFIC_SECRET_0 or SERVER_TRAFFIC_SECRET_0. Since Wireshark 2.4.
  • The Session ID field of a Server Hello handshake message. (RSA Session-ID:XXX Master-Key:YYY, since Wireshark 1.6.0)
  • The Session Ticket in a Client Hello TLS extension or Session Ticket handshake message. (RSA Session-ID:XXX Master-Key:YYY, since Wireshark 1.11.3)

To generate such a SSL key log file for a session, set the SSLKEYLOGFILE environment variable to a file before starting the NSS application. Example shell commands for Linux:

export SSLKEYLOGFILE=$PWD/premaster.txt
firefox

On Windows you need to set a global environment variable, either via cmd (invoke setx SSLKEYlOGFILE "%HOMEPATH%\Desktop\premaster.txt" for example) or via the System configuration panel. After doing so, you can launch Firefox via the icon. Note: (Linux) users of Firefox with NSS 3.24+ are possibly unable to use this method because Firefox developers disabled this by default.

The SSL key log file can be configured for Wireshark at Edit -> Preferences, Protocols -> SSL, field (Pre)-Master-Secret log filename (or pass the -o ssl.keylog_file:path/to/keys.log to wireshark or tshark).

After doing this, you can decrypt SSL sessions for previous and live captures. Should you encounter a situation where you still cannot decrypt traffic, check:

• whether the key log file path is correct (use absolute paths in case the program changes the working directory).
• whether the key log file actually contains key material for your program.
• whether Wireshark was compiled with GnuTLS (I have tested Wireshark 1.10.1 with GnuTLS 3.2.4 and libgcrypt 1.5.3)
• whether other sessions can be decrypted. For instance, I tried https://lekensteyn.nl/ which works, but a site using a Camellia cipher suite failed.

---

If you still cannot decrypt all traffic, it is possible that Wireshark contains a bug (in my case it was missing support for Camellia). To start debugging, save your capture and start wireshark with SSL logging enabled:

wireshark -o ssl.debug_file:debug.txt savedcapture.pcapng

After the capture has been loaded, you can close the program again. (You do not actually need to save the capture, but it makes it easier to reproduce the issue and avoid further noise in the log dump.) You might see something similar to the line below:

ssl_generate_keyring_material not enough data to generate key (0x33 required 0x37 or 0x57)

These numbers are a combination of the constants defined in epan/dissectors/packet-ssl-utils.h:

215-#define SSL_CLIENT_RANDOM       (1<<0)
216-#define SSL_SERVER_RANDOM       (1<<1)
217:#define SSL_CIPHER              (1<<2)
218-#define SSL_HAVE_SESSION_KEY    (1<<3)
219-#define SSL_VERSION             (1<<4)
220-#define SSL_MASTER_SECRET       (1<<5)
221-#define SSL_PRE_MASTER_SECRET   (1<<6)

As you can see, I am missing the SSL_MASTER_SECRET (0x20) here. Looking further in the log file, I can also find:

dissect_ssl3_hnd_srv_hello can't find cipher suite 0x88

This cipher suite is indeed missing from the cipher_suites structure defined in epan/dissectors/packet-ssl-utils.c. After studying RFC 5932 - Camellia Cipher Suites for TLS, I found the required parameters for a CipherSuite. The resulting patch should then be submitted to Wireshark as I did here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9144. The stable 1.12 series have vastly improved cipher suite and TLS support, so you should not have to manually patch it now.

Answer 2

If you can "expose the premaster secret", though the key exchange uses ephemeral Diffie-Hellman, then you have privileged access to either the client or the server. That's one of the points of DHE: the actual key exchange uses newly generated DH key pairs, which neither client or server stores anywhere except in its own RAM. Having a copy of the permanent server's key would give you nothing, as a passive attacker with Wireshark, since it is used only for signatures. That key could be used to impersonate the server, and thus mount an active Man-in-the-Middle attack.

However you put it, if you have access to the premaster secret, then you should also have direct access to the clear data, without having to resort to crude packet capture; therefore, your question is weird.

Anyway, subsequent data records can be decrypted by following the standard (or one of the previous versions, when applicable), which is an interesting programming exercise. It is possible that ssldump's source code might be reused for that task.