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.
