Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple stream bypass from TLS encrypted bypass v4 #11831

Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 20 additions & 15 deletions doc/userguide/configuration/suricata-yaml.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1732,21 +1732,26 @@ 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.

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.

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.

Finally, if ``encryption-handling`` is set to ``full``, Suricata will process the
flow as normal, without inspection limitations or bypass.
option in ``app-layer.protocols.tls`` and ``app-layer.protocols.ssh`` controls
the behavior after the handshake.

If ``encryption-handling`` in TLS protocol 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.

.. note:: The ``encryption-handling: default`` option is only available for
SSL/TLS and not for SSH protocol.

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.

The option has replaced the ``no-reassemble`` option. If ``no-reassemble`` is
present, and ``encryption-handling`` is not, ``false`` is interpreted as
Expand Down
12 changes: 8 additions & 4 deletions doc/userguide/performance/ignoring-traffic.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.tls.encryption-handling` options to `bypass` Suricata
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`app-layer.protocols.tls.encryption-handling` options to `bypass` Suricata
`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 these flow is ignored.
The bypass is done in the kernel or in hardware, similar to how flow bypass
is done.

.. _bypass:

Expand Down
8 changes: 2 additions & 6 deletions src/stream-tcp.c
Original file line number Diff line number Diff line change
Expand Up @@ -5651,17 +5651,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);
}
Expand Down