On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote:
> 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? :)
It's a mixed up world, we should have all bugs fixed before the end of
the day and never run out of beer... and *not* the other way around ;-)
> > 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.
Well, at first no. But I reconsidered and to me it feels like the
sensible way to go. All statistics will have duplicates when
the retransmitted data is sent again to the upper layer dissector.
(remember my session on Sharkfest, where enabling or disabling
the "tcp.desegment_tcp_streams" preference gave different results).
Dissecting the retransmitted data with the "data" dissector prevents
these glitches.
Also, on the system that received the packets, the data is sent to
the upper layer only once (in case the ACK got lost and it indeed
received the data twice).
> > - 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.
Yep, but that means having to change each and every dissector which
has tcp as it's transport layer.
> > - 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 :).
Agreed, have a look at the users-list, there is a thread in which this
problem occurs :-)
Any objections to the following fix:
Have a preference in the tcp profile like "show retransmitted frames
as data" with tooltip "Dissecting the same fragment of data twice
can disrupt the upper layer dissectors (ssl-decryption for example)".
By default this preference will be unchecked to not change the current
behavior.
Cheers,
Sake