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

With this link is attached a sample pcap file along with the ssl keylog file and debug file.

I am unable to understand why Wireshark would not decrypt the data for some ssl application data packets. This data was captured with a website request from chromium and some cipher suites blacklisted (0xcca8, 0xcca9). After perusing through the debug file, I found three common ssl states - 0x2BF, 0x3BF, 0x7BF

On seeing, packet number 594 and 1002, I do not understand why one packet was decrypted while the other was not. The keylog file captured the client random and master secret as it was able decrypt some of the packets (decoder exists for those packets).

Can somebody please help me understand the different ssl states that a dissector can obtain and what do they mean. Specifically, what are the cases in which a decoder variable would fail to be created (assume, no memory leaks and memory abundance on the computer).

As I understand, for decryption of ssl packets - You need

  1. Capture of the complete handshake.
  2. The session key either from the keylog file or the private key from the server/client.

A further concept/follow through for this question is to try to find a solution to this problem.

If there are two computers set up such as this -

Comp A ----------Bridged --------> Comp B -----------> Internet

Computer B has some firewall rules that initially blocks ssl application data packets but after execution of a script, allows all packets to pass through.

Wireshark is running on Comp A and Comp B and capture packets respectively as pcap A and pcap B. pcap B contains all packets (any dropped packets from the firewall rule also).

Then given a keylog file captured on comp A, is it possible to match and verify the decrypted content of all packets captured on both computers. ?

I tried to export the decrypted http objects and do a hash of the contents, but the match would always fail (as some packets would decrypt and some would not).

In particular, I also made the following observations -

  1. TCP reassembly happened differently on both computers (Does this lead to a difference in arrival of ssl states for the ssl session).

  2. A certain subset of data application packets for a pair of ip addresses contain different lengths. (when matched on both the computers. I do not know why this happens as the computer is only forwarding packets).

  3. Because data application packets on both computers have different lengths, they decrypt with different data and a simple hash for decrypted content fails.

What would be the best way to match and verify the decrypted contents on both the computers ?

asked 29 Dec '16, 14:01

mac9393's gravatar image

accept rate: 0%

I think you can try using the "ignore mac failed" param in the ssl options, If you are sure that the computer B just forwards the packets.

"Then given a keylog file captured on comp A, is it possible to match and verify the decrypted content of all packets captured on both computers. ?"

If you are sure that the computer B just forwards the packets then, the symmetric key should probably be same and you should be able to decrypt the packets in both the pcaps.

From your description it feels like the computer B probably does more than just forwarding are you sure it is not a proxy?

(29 Dec '16, 22:30) koundi

Please see the capture files on both the computers.

(02 Jan '17, 09:45) mac9393

Both the capture files in theory should contain the same data but are reassembled differently, with different packet lengths etc.

The gateway computer (bridged interface) just forwards the packets.

(02 Jan '17, 09:48) mac9393

I am not sure how do I verify contents of both the capture files correctly.

(02 Jan '17, 10:02) mac9393

Frame 594 is part of for which the full handshake is available. Frame 1002 is part of for which the handshake is missing and therefore Wireshark has no idea what ciphers are in use (using tcp.port==38476 also did not show other packets for this connection).

In the current dissector (for TLS <= 1.2), the common states (after completing the handshake) are:

  • A RSA key exchange is in use and a private key file was provided. The encrypted premaster secret can be decrypted and transformed into a master secret.
  • A master secret is available via a lookup in the keylog file and based on any of the Client Hello random value or Session ID.
  • No secrets are available so no decryption is possible.

In your case the handshake is missing, so no decryption is possible since the parameters are unknown.

permanent link

answered 31 Dec '16, 05:16

Lekensteyn's gravatar image

accept rate: 30%

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: 29 Dec '16, 14:01

question was seen: 1,168 times

last updated: 02 Jan '17, 10:02

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