Hi everyone, I'm dealing with TLS secure communciations and I found out that retransmitted TLS handshake messages, recevied at the wrong time, can prevent the correct session decryption. By enabling the TCP preference "Do not call subdissector for error packets", the decryption works fine. I'm wondering how this preference impact the subdissector, in particular which are these error packets handled differently? I also notice that enabling this preference has no effect on decryption when some TLS handshake messages are marked as TCP out-of-order segments: in this case wireshark won't decipher anyway. asked 13 Oct '15, 00:07  theo66 |
One Answer:
The "error" packets are the retransmissions. By default the TCP dissector will hand retransmissions to the subdissector (in this case the SSL/TLS dissector) which means that the subdissector sees the retransmitted data twice. If the subdissector is stateful (its behavior now is impacted by what packets it saw before) then this can/will confuse the subdissector. I think the TLS/SSL dissector is stateful since it's running decryption on the bytes as they go by. (Or something like that.) The TCP dissector treats both retransmissions and "out of order" packets as error so it should behave the same in both cases. I'd guess that something else is going wrong to break the decryption in your second case. answered 13 Oct '15, 06:45  JeffMorriss ♦ |
Thank for the reply. For the failed decryption with out-of-order TCP segments there's already the bug report 9641.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9461
You're welcome. If an answer answers your question, please be sure to accept it (by clicking on the check mark next to the answer). That way the site will consider the question as answered--see the FAQ.
You're right, I've missed to accept the answer, sorry!