|
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
|