| Bug ID |
9461
|
| Summary |
SSL decryption fails on out of order TCP segments
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
In the attached capture file, there is a problem in having the SSL dissector
successfully decrypt the TCP connection of port 57777. On this connection, some
TCP packets are out of order, see frame #589 and #956. Here the TCP reassembly
and the SSL dissector can handle the situation.
But in frame #1542 it somehow fails. As you can see this TCP packet contains a
full short SSL record, which is decrypted and the start of a longer SSL record
spanning the frames #1541 and #1543. However in frame #1543 the SSL dissector
is not called to decrypt the longer record.
When SSL is called again in frame #1544 on the next record, it finds that the
MAC is wrong (obvious, since it did not attempt to decrypt the previous record)
and stops decrypting from this point on.
The question is, why is TCP re-assembly + SSL decryption failing in the
situation of frame #1542, while it could successfully handle the similar
situation in frame #589 and #956?
This may be the same problem as Bug 8694.
You are receiving this mail because:
- You are watching all bug changes.