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_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
