On Sun, Jun 03, 2018 at 11:02:58AM -0700, Guy Harris wrote:
> On Jun 3, 2018, at 10:30 AM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
>
> > A long standing issue is that the TCP dissector is unable to reassemble
> > out-of-order segments, resulting in missing HTTP objects and breaking
> > TLS decryption (among other things).
> >
> > In order to tackle this, I wrote a patch to buffer segments until all
> > missing segments are found: https://code.wireshark.org/review/27943
> > (Reviews are welcome, especially for the User's Guide changes and the
> > idea itself.)
>
> I.e., leverage the existing reassembly code to handle out-of-order segments?
Yes it does, the actual code change is rather small since the reassembly
API performs tracking. Most of the LoC are from comments, documentation
and tests.
> Yes, that's the right thing to do; I'd been thinking about the same thing.
If possible, please check if the code (and documentation) matches what
you would do (or whether it should be done in a different way).
> > This behavior is currently disabled by default and put behind an
> > additional preference. I was wondering though if you would be okay with
> > enabling correct out-of-order handling by default.
>
> If "Allow subdissector to reassemble TCP streams" is the default, I'd say that reassembling out-of-order segments should be the default as well.
OK, I'll enable it by default then. There are some known (documented)
edge cases were the setting causes issues, but users are more likely to
encounter OoO issues I think.
> > I could also make it depend on the "Allow subdissector to reassemble TCP
> > streams" preference if desired. Then users who are only doing TCP
> > analysis do not have to disable an additional preference.
>
> That *might* make sense. Some people *might* think it's weird that they can't have out-of-order segment handling without reassembly, however. On the other hand, some *other* people might wonder why you'd *want* to have out-of-order segment handling without reassembly - I'm not sure in how many cases one of them would cause a problem but not the other.
Implementation-wise both options independently have some effect, but
indeed it seems strange to enable OoO handling, but at the same time
disable reassembly. I guess I'll go for making OoO depend on reassembly.
That way, if you would like to make sure that segments are dissected
independently, then only one preference has to be toggled.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
