Ask Your Question

TLS decryption fails after packet losses induced by tc netem on lo

asked 2020-05-22 08:35:14 +0000

Pethrus gravatar image

Dear Wireshark community,

I am currently using Wireshark/Tshark for protocol evaluation under different network conditions. I have succesfully been able to decrypt HTTP/2 traffic over TLS1.3/TCP by providing Wireshark the Pre-Master TLS keys dumped by the nghttp client.

Both server and client are running on the loopback interface and I am capturing the traffic using tcpdump on that interface. To emulate network different network conditions, I have used netem to add delay to the loopback interface and loss to add packet loss.

The decryption has been working fine until I start adding packet loss. What happens then is that Wireshark is sometimes unable to decrypt packets that follows the TCP Expert Info Warning: Previous segment(s) not captured (common at capture start). I read somewhere that when TCP segments get lost and reordered, it is possible that it breaks the TLS decryption. However, the client receives and decrypts the responses to every request without any problem.

Therefore, I wonder if there is some setting in Wireshark that would enable the TLS decryption to work even under packet losses. ("Allow subdissector to reassemble TCP streams" and "Reassemble out-of-order segments" are already enabled).

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-05-23 14:35:42 +0000

Pethrus gravatar image

I have now been able to locate the issue by fiddling with the different TCP protocol option settings under Edit -> Preferences -> Protocols -> TCP.

It turns out that when the option "Analyze TCP sequence numbers" is checked, the payload of TCP segments marked with Expert Info Warning Previous segment(s) not captured are not decrypted. However, when unchecking this option, those packets are decrypted. The complete TCP settings to have everything working looks like this:

  • CHECK Show TCP summary in protocol tree
  • UNCHECK Validate the TCP checksum if possible
  • CHECK Allow subdissector to reassemble TCP streams
  • CHECK Reassemble out-of-order segments
  • UNCHECK Analyze TCP sequence numbers
  • UNCHECK Relative sequence numbers
  • UNCHECK Track number of bytes in flight
  • UNCHECK Calculate conversation timestamps
  • UNCHECK Try heuristic sub-dissectors first
  • UNCHECK Ignore TCP Timestamps in summary
  • UNCHECK Do not call subdissectors for error packets
  • CHECK TCP Experimental Options with a Magic Number
  • UNCHECK Display process information via IPFIX

Hope this can help someone else struggling with partial TLS decryption!

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-05-22 08:35:14 +0000

Seen: 49 times

Last updated: May 23