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

I followed the instuctions provided under the "Complete walk through" section in After the SSL handshake the GET request (frame #10) dispays in plain text in Wireshark, but the server response (frame #11) is displayed as "Encrypted Application Data". However, the SSL debug file shows the successful decryption for that same frame. Any idea what I'm doing wrong here? Thanks in advance.

asked 16 Jun '14, 22:10

PotRoast's gravatar image

accept rate: 0%

In Wireshark click Edit>Preferences…

Select and expand Protocols, scroll down (or just type ssl) and select SSL

Click the RSA Keys List Edit… button, click New and then enter the following information;

■IP Address is the IP address of the host that holds the private key used to decrypt the data and serves the certificate (i.e. the decrypting host, the server) ■Port is the destination port used to communicate with the host that holds the private key used to decrypt the data and serves the certificate (enter Port used for ssl ideally 443) ■Protocol is the upper-layer protocol encrypted by SSL/TLS, for instance, the protocol encrypted over a HTTPS web connection is HTTP(Type HTTP) ■Key File – select as necessary ■Password is the passphrase used to protect the private key file, if any (Can be put blank)

IMP notes : ■The private key file must be in the PEM or PKCS12 format; if it’s not you can use OpenSSL to convert what you have as appropriate, just Google it. ■The private key file should only contain the private key, not the public key (aka the certificate). Files frequently contain both, check by viewing the file in a true text editor. You only need the text delimited by this; Header: —–BEGIN RSA PRIVATE KEY—– Footer: —–END RSA PRIVATE KEY—– ■The capture must include both ‘sides’ of a conversation. In other words, the capture must include the full client and server exchange. ■The capture must include the initial SSL/TLS session establishment. In other words, the CLIENTHELLO and SERVERHELLO exchange. Beware captures taken where a session has been resumed. Ideally, ensure any capture either a) is of packets related to an entirely new device connecting or b) where a device that has already previously established a session is used, it is used after a considerable time after the last session was established. ■Ensure the use of a Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite is not negotiated between the two hosts. This is indicated by the use of a ServerKeyExchange message. There is no way to decrypt data where ephemeral ciphers are used.

(16 Jun '14, 23:28) kishan pandey

what is your

  • OS and OS version
  • Wireshark version

can you please post the SSL debug file (in total, not just the lines for frame #11)?

(17 Jun '14, 11:55) Kurt Knochner ♦

Here's the follow-up infomration ...

  1. Packet Capture file
  2. Wireshark decrypt debug file
  3. Screen shot of Wireshark previous to decrypt
  4. Screen shot of Wireshark with debug info configured as specified above and in the Wireshire SSL page
  5. PEM file used for decryption (don't worry, this is a throw-away private key that I don't use other than this exercise).

The frame I'm most interested in is frame #11. The debug log file shows the encrypted and decrypted (plain text) data, so I'm confident that Wireshark can do the decryption, but is still shows as encrypted in the Wireshark app.

(19 Jun '14, 23:12) PotRoast

I'm wondering if this issue has anything to do with the TLS version and cipher suite: TLSv1.2 Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) although the log file show successful decryption so I'm at a loss. Thanks in advance for help.

(19 Jun '14, 23:19) PotRoast

I decrypted it,Find below the steps performed, 1) entered 4433 in ssl port list ( preference - http - ssl) 2) under Preferencec -HTTP - Uncheck "HTTP header spanning multiple tcp segments"

(20 Jun '14, 00:00) kishan pandey

FYI ... here is the version of Wireshark I'm using on Ubunutu 14.04

wireshark --version

wireshark 1.10.6 (v1.10.6 from master-1.10)

Copyright 1998-2014 Gerald Combs [email protected] and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 3.10.7, with Cairo 1.13.1, with Pango 1.36.1, with GLib 2.39.91, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Feb 25 2014 21:09:53), with AirPcap.

Running on Linux 3.13.0-29-generic, with locale en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.8, GnuTLS 2.12.23, Gcrypt 1.5.3, without AirPcap. Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz

Built using gcc 4.8.2.

(20 Jun '14, 00:31) PotRoast

also, here are the contents of the Wireshark ssl_keys file:


(21 Jun '14, 00:48) PotRoast

thanks kishan, but I'm still getting the same result. Here at my HTTP setting from the Wireshark preferences file:

#http.dechunk_body: TRUE
#http.decompress_body: TRUE
#http.desegment_body: TRUE
http.desegment_headers: FALSE
http.ssl.port: 443,4433
#http.tcp.port: 80,3128,3132,5985,8080,8088,11371,1900,2869,2710

any suggestions?

(21 Jun '14, 14:45) PotRoast
showing 5 of 8 show 3 more comments

If you look at your ssl debug file, you will see, that Wireshark was able to decrypt the frame!

 77 d0 0b cc 59 fd b2 bc 61 1d 7f 1c 17 f1 75 f1 |w...Y...a.....u.|
 48 54 54 50 2f 31 2e 30 20 32 30 30 20 6f 6b 0d |HTTP/1.0 200 ok.|
 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 65 3a 20 74 |.Content-type: t|
 65 78 74 2f 68 74 6d 6c 0d 0a 0d 0a 3c 48 54 4d |ext/html....HTM|
 0a 0a 73 5f 73 65 72 76 65 72 20 2d 77 77 77 20 |..s_server -www |
 2d 63 69 70 68 65 72 20 41 45 53 32 35 36 2d 53 |-cipher AES256-S|
 48 41 20 2d 6b 65 79 20 73 65 72 76 65 72 2e 70 |HA -key server.p|
 65 6d 20 2d 63 65 72 74 20 73 65 72 76 65 72 2e |em -cert server.|
 63 72 74 20 0a 53 65 63 75 72 65 20 52 65 6e 65 |crt .Secure Rene|
 67 6f 74 69 61 74 69 6f 6e 20 49 53 20 73 75 70 |gotiation IS sup|
 70 6f 72 74 65 64 0a 43 69 70 68 65 72 73 20 73 |ported.Ciphers s|
 75 70 70 6f 72 74 65 64 20 69 6e 20 73 5f 73 65 |upported in s_se|

It just does not show the decrypted frame as HTTP response.

After playing a bit with the protocol preferences, I found that disabling the following option will show the HTTP response ('HTTP/1.0 200 ok').

Edit -> Preferences -> SSL -> Reassemble SSL Application Data spanning multiple SSL records

I'm not sure what is going on here, as I did not check the code. Could be a bug due to the large answer (multiple TCP segments). Please file a bug report at and include the files you posted in this question.

In the meantime you can continue your work/tests by disabling the option I mentioned.


permanent link

answered 21 Jun '14, 16:25

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

edited 21 Jun '14, 16:26

Thanks Kurt. Yes, as I stated in my original post, the SSL debug file shows the successful decryption, so that's good.

I tried unchecking the option you suggest (ssl.desegment_ssl_application_data: FALSE) and am still getting the same result as I had before: no decrypted output in Wireshark. Could you post the contents of your Preferences file so I can do a full compare?

However, the debug log still continues to show successfull decryption. I also did this in tshark and am getting the same results.

tshark -r localhost-test.pcap -o ssl.desegment_ssl_application_data:FALSE -o "ssl.keys_list:,4443,http,/home/doug/temp/ssl/server.pem" -V > tshark.out

Here's the resulting output file (tshark.out):

Here's the resulting debug file:

(21 Jun '14, 17:44) PotRoast

I tried unchecking the option you suggest ssl.desegment_ssl_application_data: FALSE

Could you post the contents of your Preferences file so I can do a full compare?

That's the only option in my preferences file that is different than the default settings for HTTP and SSL, so it makes no sense to post the file.

BTW: My tests are on Windows, not Linux. Maybe that makes a difference (somehow - the code should be the same).

I tested with 1.10.7 and 1.11.2. Both show the same behavior.

(21 Jun '14, 17:52) Kurt Knochner ♦

No need to file a new bug, I already encountered this in the past: Last time I tried to debug it, there appears to be deeper problems in HTTP assembly but I have not picked up the work yet.

(23 Jun '14, 15:12) Lekensteyn
Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 16 Jun '14, 22:10

question was seen: 13,764 times

last updated: 23 Jun '14, 15:12

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