On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote:
> Today I noticed that SSL decryption breaks when there is a tcp
> retransmission.
We never run out of things to fix, do we? :)
> 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.
Something about this just doesn't feel right.
> - 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.
I like this idea. The next protocol can then use it if necessary or
ignore 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.
The packet info struct is probably a better place for it based on what
is already in epan/packet_info.h's declaration of packet_info.
> - Accept that retransmitted frames will break SSL decryption and let
> the user delete the retransmitted frames themselves with editcap.
Too much work for the user :).
Steve
