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 071b5a9d94ed175b93236f202eccce40cb7b9340..0bccf90713bbfa655c781ba414e94e3e2e4d7fb8 100644 (file)
--- 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 a2c7a8825528c302595221a9443fd2eefd8e40a2..50399a051d2871a046124a40a3d5dff6ef3938b6 100644 (file)
--- 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 a6ca06283e56f66b95fd08be77b145a44c708c1f..d378df0b6b973fae2c46ba5dba9a1c824640a3fb 100644 (file)
--- 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 7b276e16ecb4bbb1b4355ce143b6c861855084b6..224877572a266c5ef958e345ff8d2a00f9710870 100644 (file)
--- 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);
         }