This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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 

asked 11 Jan '13, 16:27

Yudi's gravatar image

Yudi
26114
accept rate: 0%

edited 14 Jan '13, 00:00

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245


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.

permanent link

answered 11 Jan '13, 16:34

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×319
×75
×62

question asked: 11 Jan '13, 16:27

question was seen: 20,769 times

last updated: 14 Jan '13, 00:00

p​o​w​e​r​e​d by O​S​Q​A