1

I am unable to understand why decryption does not work here.

Consider the scenario in this pcap file - https://drive.google.com/open?id=0Bz5corUPBatBWWpXTFYwWjdfS0k

I have a network setup such that

Internet Server (104.31.17.3)<---------> (eth1) Gateway (192.168.151.19) (eth0) <----------> Client (192.168.151.15)

For the context of this capture I use the filter tcp and !ssh and am interested only in the frames from frame #22 to frame #98

An explanation of what is happening in between these frames -

  1. Frame 22-30 is the TLS handshake.
  2. Frame 31 is the GET request. This is dropped by a firewall rule.
  3. Frame 32-35 are some re-transmissions for the same GET request (see length of packet etc)
  4. Frame 38-86 are the client computer (the one that made the GET request) and the gateway computer interacting. (rsync +ssh communication - see port number 22 in the frames) Frame 61 is just another retransmission for the GET request.
  5. Frame 87 another retransmission for GET request by client.
  6. Time difference between frame 86 and 87 is 0.9 seconds (during which some firewall rules were updated).
  7. Frame 88 is when the server responds and contains TLS application data. Wireshark is unable to decrypt frame 88 which I am interested in.

The debug file is not easy to read as the dissector code is modified. (Use of ssl_debug_printf statement in a loop needed for other purposes). Please use the following command to read the debug file. The "-C parameter prints the next # lines following the grep string"

cat debug.txt | grep -C 10 "frame #88"

I do not understand why Wireshark cannot decrypt the TLS application data packet. The packet belongs to the same TCP stream, TCP port no and SSL conversation. The SSL state is the same as the one for the initial GET request (one that was dropped because of firewall rule - frame 31).

  • 1
    this isn't really an infosec question, it's a wireshark question. Try in SuperUser or stackoverflow. – Steve Sether Feb 17 '17 at 01:46
  • 1
    https://ask.wireshark.org/questions/23590/change-cipher-spec-is-retransmitted-ssl-decryption-fails - this has a similar description, one way traffic is decrypted, the other way is not. The answers say that "*a retransmitted "Change Cipher Spec" message (from server to client) causes the wrong decryption of all the TLS messages*" - your capture has a retransmitted change cipher spec as frame #32, just after decrypting the GET request in frame #31. Could that be relevant? – TessellatingHeckler Feb 17 '17 at 05:06
  • It seems it is indeed reported as a bug with Wireshark. The re-transmitted Changecipher spec is the cause of this problem. –  Feb 18 '17 at 02:34

0 Answers0