From: Dean Balandin Date: Tue, 27 Jun 2023 12:40:37 +0000 (+0000) Subject: stream: decouple stream.bypass dependency from tls bypass X-Git-Tag: suricata-8.0.0-beta1~49 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3cdb0ceb7ebe3872bc1eb7c6163d8a5bb6369bed;p=thirdparty%2Fsuricata.git stream: decouple stream.bypass dependency from tls bypass Decouple app.protocols.tls.encryption-handling and stream.bypass. There's no apparent reason why encrypted TLS bypass traffic should depend on stream bypass, as these are unrelated features. Ticket: 6788 --- diff --git a/doc/userguide/configuration/suricata-yaml.rst b/doc/userguide/configuration/suricata-yaml.rst index 071b5a9d94..0bccf90713 100644 --- a/doc/userguide/configuration/suricata-yaml.rst +++ b/doc/userguide/configuration/suricata-yaml.rst @@ -1861,21 +1861,21 @@ Encrypted traffic There is no decryption of encrypted traffic, so once the handshake is complete continued tracking of the session is of limited use. The ``encryption-handling`` -option controls the behavior after the handshake. +option in ``app-layer.protocols.tls`` and ``app-layer.protocols.ssh`` controls +the behavior after the handshake. -If ``encryption-handling`` is set to ``default`` (or if the option is not set), -Suricata will continue to track the SSL/TLS session. Inspection will be limited, -as raw ``content`` inspection will still be disabled. There is no point in doing -pattern matching on traffic known to be encrypted. Inspection for (encrypted) -Heartbleed and other protocol anomalies still happens. +If the ``encryption-handling`` property of the TLS/SSH configuration nodes are set to ``track-only`` (or are not set), Suricata will continue to track the respective SSL/TLS or SSH session. Inspection will be limited, as raw ``content`` inspection will still +be disabled. There is no point in doing pattern matching on traffic known to +be encrypted. Inspection for (encrypted) Heartbleed and other protocol +anomalies still happens. -When ``encryption-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. +When ``encryption-handling`` is set to ``bypass``, all processing of this +session is stopped. No further parsing and inspection happens. This will also +lead to the flow being bypassed, either inside Suricata or by the capture method +if it supports it and is configured for it. -Finally, if ``encryption-handling`` is set to ``full``, Suricata will process the -flow as normal, without inspection limitations or bypass. +Finally, if ``encryption-handling`` is set to ``full``, Suricata will process +the flow as normal, without inspection limitations or bypass. The option has replaced the ``no-reassemble`` option. If ``no-reassemble`` is present, and ``encryption-handling`` is not, ``false`` is interpreted as diff --git a/doc/userguide/performance/ignoring-traffic.rst b/doc/userguide/performance/ignoring-traffic.rst index a2c7a88255..50399a051d 100644 --- a/doc/userguide/performance/ignoring-traffic.rst +++ b/doc/userguide/performance/ignoring-traffic.rst @@ -73,10 +73,14 @@ Example:: encrypted traffic ----------------- -The TLS app layer parser has the ability to stop processing encrypted traffic -after the initial handshake. By setting the `app-layer.protocols.tls.encryption-handling` -option to `bypass` the rest of this flow is ignored. If flow bypass is enabled, -the bypass is done in the kernel or in hardware. +The TLS and SSH app layer parsers have the ability to stop processing +encrypted traffic after the initial handshake. By setting the +`app-layer.protocols.tls.encryption-handling` and +`app-layer.protocols.ssh.encryption-handling` options to `bypass` Suricata +bypasses flows once the handshake is completed and encrypted traffic is +detected. The rest of the flow is ignored. +The bypass is done in the kernel or in hardware, similar to how flow bypass +is done. .. _bypass: diff --git a/doc/userguide/upgrade.rst b/doc/userguide/upgrade.rst index a6ca06283e..d378df0b6b 100644 --- a/doc/userguide/upgrade.rst +++ b/doc/userguide/upgrade.rst @@ -141,6 +141,17 @@ Major changes after the previously mentioned interval. Other cards were not observed to have this issue. This feature is disabled by default. See :ref:`dpdk-link-state-change-timeout`. +- Encrypted traffic bypass has been decoupled from stream.bypass setting. + This means that encrypted traffic can be bypassed while tracking/fully + inspecting other traffic as well. +- Encrypted SSH traffic bypass is now independently controlled through + ``app-layer.protocols.ssh.encryption-handling`` setting. The setting can either + be ``bypass``, ``track-only`` or ``full``. + To retain the previous behavior of encrypted traffic bypass + combined with stream depth bypass, set + ``app-layer.protocols.ssh.encryption-handling`` to ``bypass`` (while also + setting ``app-layer.protocols.tls.encryption-handling`` to ``bypass`` and + ``stream.bypass`` to ``true``). Removals ~~~~~~~~ diff --git a/src/stream-tcp.c b/src/stream-tcp.c index 7b276e16ec..224877572a 100644 --- a/src/stream-tcp.c +++ b/src/stream-tcp.c @@ -5707,17 +5707,13 @@ int StreamTcpPacket (ThreadVars *tv, Packet *p, StreamTcpThread *stt, } if (ssn->flags & STREAMTCP_FLAG_BYPASS) { - /* we can call bypass callback, if enabled */ - if (StreamTcpBypassEnabled()) { - PacketBypassCallback(p); - } - - /* if stream is dead and we have no detect engine at all, bypass. */ + PacketBypassCallback(p); } else if (g_detect_disabled && (ssn->client.flags & STREAMTCP_STREAM_FLAG_NOREASSEMBLY) && (ssn->server.flags & STREAMTCP_STREAM_FLAG_NOREASSEMBLY) && StreamTcpBypassEnabled()) { + /* if stream is dead and we have no detect engine at all, bypass. */ SCLogDebug("bypass as stream is dead and we have no rules"); PacketBypassCallback(p); }