This works as documented, but I now have the unwanted side-effect where my other non-TLS streams are bypassed once I’ve reached the reassembly depth.
I looked at the code, and from what I could tell, there’s no real reason for this dependency, it’s a simple if: suricata/stream-tcp.c at master · OISF/suricata (github.com)
STREAMTCP_FLAG_BYPASS is only set by StreamTcpSetSessionBypassFlag
which is only called once in the entire codebase in the app-layer parser and only when APP_LAYER_PARSER_BYPASS_READY is set, which is only turned on when ssl_config.encrypt_mode is set to SSL_CNF_ENC_HANDLE_BYPASS, here and here.
In other words, there are no other flows that set STREAMTCP_FLAG_BYPASS as far as I can tell.
So my question is - why is this dependency here? Why not call PacketBypassCallback without asking if (StreamTcpBypassEnabled())?
But this doesn’t seem version related, it’s right there in the code and this behavior is explicitly documented (ignoring the documentation error calling it encrypt-handling instead of encryption-handling):
When encrypt-handling is set to bypass , all processing of this session is stopped. No further parsing and inspection happens. If stream.bypass is enabled this will lead to the flow being bypassed, either inside Suricata or by the capture method if it supports it and is configured for it.
The question is why? I don’t see any reason to couple these 2 features (not to say that there is no reason, just saying I don’t see it). The only reasoning I can think of is that it just follows the common coding pattern/convention where PacketBypassCallback(p) is called only if StreamTcpBypassEnabled() returns true, regardless of whether that’s an actual prerequisite.