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

Wireshark - Problem Decrypting SSL Traffic via ERSPAN

0

Hi experts,

I have a question regarding Wireshark ability to decrypt SSL traffic via ERSPAN.

We have ERSPAN mirroring session from our web server A to another server B. Our software on server B seems to have problem decrypting some of the traffic being mirrored from server A. Packet captures were conducted on both servers to determine root cause.

On Server A, I can see a full handshake with Client Key Exchange frame, and the subsequent traffic is decrypted as HTTP.

However on server B, the Client Key Exchange frame (#2386) was marked as [TCP Previous segment not captured] and [TCP segment of a reassembled PDU], in turn, this wasn't showned as Client Key Exchange step and wireshark was not able to decrypt the application data. Additionally, this frame is also marked as [Reassembled PDU in frame 2389], so it seems that the traffic arrived later but it wasn't pieced together to form Client Key Exchange.

Could anyone suggest any ideas why Wireshark is not able to reconstruct a Client Key Exchange step on server B?

Does this highlight a problem with the network? Or is it a problem with wireshark not being able to reconstruct out of order SSL traffic via ERSPAN. I can provide more details if needed.

Also, I tried to linked in a few screenshots from dropbox for illustration but my post were marked as spam and could not be publicized.

Thanks in advance.

asked 17 Apr '13, 17:21

huandn's gravatar image

huandn
11●1●1●3
accept rate: 0%

One Answer:

1

SSL decryption does not really like out-of-order packets in the SSL handshake. If you really need to decrypt the traffic, you might need to manually reorder the packets by using editcap. This would take the following steps:

  1. extract frame 2386: editcap -r <file> frame2386.pcap 2386
  2. save the remaining file : editcap <file> otherframes.pcap 2386
  3. adjust the timestamp of frame 2386: editcap -d <timediff> frame2386.pcap frame2386-new.pcap
  4. merge to a new file: mergecap -w <newfile> otherframes.pcap frame2386-new.pcap

answered 18 Apr '13, 00:03

SYN-bit's gravatar image

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

Thanks very much for your answer. It was spot on.

We have a sniffing probe that inspect packets continuously and de-crypt them for analysis. We would need traffic to be decrypted all the time and not just in this instance.

Do we need to resolve the network TCP out of order problem first? Or whether our software have to be able to reorder packets before trying to decrypt them.

(18 Apr '13, 17:28) huandn