Comment # 16
on bug 12793
from Peter Wu
(In reply to Andre Luyer from comment #15)
> I have now git, compiler, packages, etc. up and running... (there was no
> need for it when just reporting a bug).
Sorry, I thought you already had a development environment set up and that
testing was easy but now I realize you were probably using the automated
builds. If I knew that it would be such an hassle, I would not have requested
the testing from the patch.
> This is the output I get:
>
> $ ./tshark -v | head -1
> TShark (Wireshark) 2.3.0 (6f4d73f from master)
> $ for i in "-Y" "-2 -Y" "-2 -R"; do echo Option: $i; ./tshark -r
> ~/Session_resumption.pcapng $i ssl.resumed; done
> Option: -Y
> 6 0.002285 192.168.12.2 → 192.168.12.12 TLSv1 197 Server Hello, Change
> Cipher Spec, Finished
> Option: -2 -Y
> 6 0.002285 192.168.12.2 → 192.168.12.12 TLSv1 197 Server Hello, Change
> Cipher Spec, Finished
> Option: -2 -R
> 1 0.002285 192.168.12.2 → 192.168.12.12 TLSv1 197 Server Hello, Change
> Cipher Spec, Finished
> 2 0.019189 192.168.12.2 → 192.168.12.12 TLSv1 127 Change Cipher Spec,
> Finished
>
> So only -R (Read filter) shows 2 packets.
Thanks for testing, the result with -R looks initially quite unexpected, but
actually it is logical given the current heuristics. When a capture contains a
Server Hello followed by two ChangeCipherSpecs, it will assume for both of them
that it is an abbreviated handshake since there is no ServerHelloDone in
between.
To improve the heuristics, it could also reset the resumption assumption after
handling the first ChangeCipherSpec (from the server side). Patch is updated,
your testcase now only displays a single packet for each occurrence.
A remaining limitation is that captures where the ServerHelloDone is somehow
filtered out will be misdetected as resumed. I think it is quite rare to be
that unlucky (have a ChangeCipherSpec for a non-abbreviated handshake, but no
ServerHelloDone), so it is a risk that can be taken.
You are receiving this mail because:
- You are watching all bug changes.
