Can’t Decrypt TLSv1 Traffic

Question

Hi,

I’m using Wireshark v1.8.4.

I’m trying to learn about SSL package decryption using wireshark. I have downloaded sample capture file and private key (snakeoil2_070531.tgz) from http://wiki.wireshark.org/SSL and successfully decrypted the package.

Then I tried to configure my own Apache Tomcat server to use SSL. When I capture the traffic to/from my Apache Tomcat server, Wireshark said that its protocol is “TLSv1” instead of “SSLv3”. I have provided the private key to Wireshark SSL protocol preference. But the traffic from my Apache Tomcat isn’t decrypted.

Here is my Wireshark SSL debug file.

ssl_association_remove removing TCP 443 - http handle 00000000051D0CE0 Private key imported: KeyID a0:d7:ab:5c:93:66:ed:92:de:1d:ba:77:4f:db:22:e2:... ssl_load_key: swapping p and q parameters and recomputing u ssl_init IPv4 addr '192.168.168.131' (192.168.168.131) port '443' filename 'G:\Reference\ebook\Networking\Wireshark Network Analysis (Supplement Material)\9781893939943_allsupplements\9781893939943_traces\latihan\ssl\privkey.pem' password(only for p12 file) '' ssl_init private key file G:\Reference\ebook\Networking\Wireshark Network Analysis (Supplement Material)\9781893939943_allsupplements\9781893939943_traces\latihan\ssl\privkey.pem successfully loaded. association_add TCP port 443 protocol http handle 00000000051D0CE0 dissect_ssl enter frame #8 (first time) ssl_session_init: initializing ptr 0000000006B164B0 size 680 conversation = 0000000006B15DF8, ssl_session = 0000000006B164B0 record: offset = 0, reported_length_remaining = 194 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 189, ssl state 0x00 association_find: TCP port 60193 found 0000000000000000 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 185 bytes, remaining 194 packet_from_server: is from server - FALSE ssl_find_private_key server 192.168.168.131:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01 dissect_ssl enter frame #9 (first time) conversation = 0000000006B15DF8, ssl_session = 0000000006B164B0 record: offset = 0, reported_length_remaining = 1130 dissect_ssl3_record found version 0x0301(TLS 1.0) -> state 0x11 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 1125, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 70 bytes, remaining 1130 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello found CIPHER 0x0033 -> state 0x17 dissect_ssl3_hnd_srv_hello trying to generate keys ssl_generate_keyring_material not enough data to generate key (0x17 required 0x37 or 0x57) dissect_ssl3_hnd_srv_hello can't generate keyring material dissect_ssl3_handshake iteration 0 type 11 offset 79 length 615 bytes, remaining 1130 dissect_ssl3_handshake iteration 0 type 12 offset 698 length 424 bytes, remaining 1130 dissect_ssl3_handshake iteration 0 type 14 offset 1126 length 0 bytes, remaining 1130 dissect_ssl enter frame #10 (first time) conversation = 0000000006B15DF8, ssl_session = 0000000006B164B0 record: offset = 0, reported_length_remaining = 166 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 102, ssl state 0x17 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 98 bytes, remaining 107 ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt dissect_ssl3_handshake can't decrypt pre master secret record: offset = 107, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 Change Cipher Spec dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 113, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 48, ssl state 0x17 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 122 offset 118 length 13182942 bytes, remaining 166 dissect_ssl enter frame #11 (first time) conversation = 0000000006B15DF8, ssl_session = 0000000006B164B0 record: offset = 0, reported_length_remaining = 6 dissect_ssl3_record: content_type 20 Change Cipher Spec dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER

dissect_ssl enter frame #12 (first time) conversation = 0000000006B15DF8, ssl_session = 0000000006B164B0 record: offset = 0, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 48, ssl state 0x17 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 182 offset 5 length 11033596 bytes, remaining 53

Answer 1

2

Here is the line from your ssl-debug file that tells you what the problem is:

ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt

DH key exchanges uses a randomly created public/private keypair to encrypt the session key in the ClientKeyExchange handshake message. As wireshark does not have the randomly created keypair, it can not decrypt the session key and therefor not decrypt the application data.

A RSA key exchange uses the public key from the certificate to encrypt the session key in the ClientKeyExchange handshake message. So when wireshark is pointed to the correct private key, it is able to decrypt the session key and then use the session key to decrypt the application data.

answered 11 Jan '13, 16:34

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

Does DH key exchange refer to "Diffie–Hellman key exchange"? I read from http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange and http://en.wikipedia.org/wiki/Key_exchange but none of them say about randomly generated public/private key pair.

Could you give further references about this DH key exchange?

(11 Jan '13, 17:17) Yudi

You are right, it is not a public/private key pair. However, both client and server generate a random value (not known to wireshark) which allows them to generate a shared secret (the session key) instead of exchanging the shared secret by encrypting it with the public key from the certificate (which can be decrypted by using the matching private key).

(12 Jan '13, 02:14) SYN-bit ♦♦

So, is the next question "How do I configure Tomcat to use RSA instead of DH key exchanges" or what? I realize that we're getting into off-topic things here, but it would be good if the answer also answered "Okay, so what next?", rather than just diagnose the problem.

(12 Jan '13, 22:50) Warren Young

So, is the next question "How do I configure Tomcat to use RSA instead of DH key exchanges" or what?

a very good question for a Tomcat forum, isn't it ;-)

As you did not tell us how you configured your Tomcat installation it is impossible to tell you what to change. It's either the webserver (Apache, Lighthttpd, ngnix) or Tomcat itself that handles SSL/TLS. Obviously the required changes depend on the setup.

Google is your friend...

Tomcat: http://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2-in-tomcat.html
Apache: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html

Look for DHE or Diffie Hellman or similar strings.

(13 Jan '13, 04:35) Kurt Knochner ♦

So, is it absolutely impossible to decrypt DH key exchange using wireshark? Is there any workaround for this? Maybe like manually generate session key and force both client and server to temporarily use the known session key.

(13 Jan '13, 13:08) Yudi

So, is it absolutely impossible to decrypt DH key exchange

without knowledge of the session key? Yes, that's why people use DH.

Is there any workaround for this?

As mentioned: Configure the server (webserver) or the client (browser) to refrain from using DH ciphers.

Another alternative would be to expose the session key within the server or client (see openssl client). Unfortunately there is no "standard" way of doing that in the browser or the server. At least I don't know any. So again: google is your friend...

(13 Jan '13, 13:20) Kurt Knochner ♦

showing 5 of 6 show 1 more comments