Diffie-Hellman/TLS decryption breaks after 'TCP Previous Segment not captured' / 'TCP Out-Of-Order'

edit

Thank you for the pointer to the man page!

Enabling 'Reassemble out-of-order-segments' certainly had an effect. In one case the decryption broke-down even earlier ;) :D.

In another case the decryption went on for longer but broke-down eventually - I think it broke-down again while a fairly large (+20 MB) WebSocket message was transmitted and another "TCP Previous segment not captured" info is shown in the GUI. After that info line the type in the Protocol column went from TLSv1.3 to TCP and stayed that way in that direction.

I'm not sure if this is noteworthy but what I also see is that the decryption doesn't break-down completely. Instead the decryption stays intact in only one direction (IP.A -> IP.B but not the other way around).

Are there maybe other knobs I could try to adjust?

If you're dropping packets and they aren't retransmitted then the decryption can't succeed.

Recent versions of Wireshark have TCP "completeness" flags that indicate that state of the connection from the initial SYN to the final FIN, ACK (or RST). Look at tcp.completeness*.

Great, thank you! I'll dig into it.

But what confuses me a little is that the actual application was still maintaining the bidirectional TLS conversation / exchange. So it seems to me that the packets weren't actually missing but Wireshark wasn't able to capture them because of some reason. Is this a posibility? Can anything be done about that? Kind regards

If your capture method is dropping packets then you need to build a better capture method!

Some discussion about drops on @Jasperblog

Thank you, I appreciate your feedback!