Wireshark-bugs: [Wireshark-bugs] [Bug 9515] TLSV1 "Ignored Unknown Record"
Date: Sun, 01 Feb 2015 02:38:01 +0000
Comment # 22
on bug 9515
from Evan Huus
> Detection of a STARTTLS request and acknowledgement requires assistance from the dissector. Certainly, the question then becomes who handles the decryption once STARTTLS has been detected. My observation is that normally, when protocol A carries protocol B, the dissector for A calls the dissector for B. In this particular case, one can imagine that SSL fits "between" TCP and the application, however the call path is not currently TCP->SSL->Application, it becomes TCP->Application->SSL. > Now, Evan is suggesting to make the upper layers (TCP/UDP/...) aware of marking the lower layer as TLS-encapsulated, but wouldn't this move complexity to the all of the TCP/UDP/... protocols? As far as I am aware, TCP is basically the only protocol that carries SSL (UDP may be used occasionally, and perhaps also SCTP, but I don't know of any reliable uses of those or any others). Having this complexity in those few places is potentially preferable to having it in the four (and counting) application-level protocols that support this feature. > I've just pushed an updated patch that fixes a desegmentation issue, but it still has a problem with fragmentation of a SSL record over multiple TCP segments It seems to me that having the TCP dissector call the SSL dissector directly would make reassembly of fragmented SSL records substantially simpler because the application-level protocol would not have to act as intermediary passing through the reassembly information. Is this not the case?
You are receiving this mail because:
- You are watching all bug changes.
- Next by Date: [Wireshark-bugs] [Bug 10908] New: wireshark is not dissecting http2 correctly
- Next by thread: [Wireshark-bugs] [Bug 9515] TLSV1 "Ignored Unknown Record"
- Index(es):
- Get Wireshark
- Download
- Code of Conduct