Wireshark-dev: [Wireshark-dev] SSL decryption breaks after retransmission
From: "Sake Blok" <[email protected]>
Date: Tue, 6 May 2008 22:17:54 +0200
Hi All,
 
Today I noticed that SSL decryption breaks when there is a tcp retransmission. The retransmitted segment will be handled by the SSL dissector as if it was new data. The mac-check will fail, but the state of the SSL decrypter is left in an erroneous state, causing the dissection of all subsequent SSL records to fail. Of course on the receiving host, the TCP stack takes care of filtering out the retransmitted segment, so it's SSL stack will have an issue.
 
To solve this issue, I can think of several options:
 
- Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. The change in behavior can be prevented with a preference, but I don't want to create a zillion preferences...
 
- Have a "retransmitted_data" flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. Since the flag only has meaning between the calling and the called dissector, I'm not so happy with it's presence in the frame-data structure.
 
- Add code to the SSL dissector to get the TCP conversation data and check for the TCP analysis flag "retransmission" itself. But that would break the layered design of it all.
 
- Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap.
 
 
For now, I think I would prefer option 1.What do you all think? Are there any other options that I haven't thought of?
 
Cheers,
       Sake