Wireshark-bugs: [Wireshark-bugs] [Bug 12793] Expert Info ssl.resumed incorrect after TLS renegot
Comment # 18
on bug 12793
from Andre Luyer
(In reply to Peter Wu from comment #16)
> 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.
No problem. It is not the first time I compiled / edited Wireshark code (
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4652 ). And parallel to
this issue I was already busy getting it compiled on Red Hat (RHEL7) because
the version installed via "yum" (1.10) was lacking functionality. So my result
in comment #15 was actually from my RHEL7 build.
> 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.
In practice using only the ssl.resumed filter is not useful. The example below
is more likely to be used and shows only one matched frame as expected:
./tshark -r ~/Session_resumption.pcapng -2 -R ssl -Tfields -e ssl.resumed -e
_ws.col.Info
> 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.
Maybe there is another way: in case of a resumed session both ServerHello and
ChangeCipherSpec will be in the same frame (so that frame is either filtered or
not), otherwise it is not resumed. (In theory it could be spilt over two
frames, but then the TLS is badly implemented on the server.)
So that should work in case of a -R filter too -- as long as the capture is not
snapped.
And use ClientHello to reset the ssl state to handle the renegotiated
session(s) correctly.
FYI: the sample pcap shows a step up in security: after the HTTP POST the
server decides that a stricter security is required and sends therefor a
HelloRequest.
See you at SharkFest16(?)!
You are receiving this mail because:
- You are watching all bug changes.
