Uni-directional TLS

Help
,
1

image
image880×529 50.4 KB

tls-ex1-3pkt.pcap (535 Bytes)

tls-ex1-4pkt.pcap (629 Bytes)

Suricata version 6.0.3, Running Suricata in NFQUEUE mode.
we have following values “True”

stream:
  midstream: true             # don't allow midstream session pickups
  async-oneside: true        # don't enable async stream handling

Alerting Suricata with TLS rule, noticed that with Uni-directional Suricata is not Alerting (fail) but it is working for Bi-directional. Using the same TLS rule for both Uni-directional and Bi-directional.

Sample Rule:
alert tls any any → any any (msg:“Alert by TLS SNI-EX”; tls.sni; content:“www.example.com”; fast_pattern; gid:1; sid:4; rev:1;)

Uni-directional

When we have uni-directional traffic like from client to server (syn), then ack is not coming through Suricata, means we have only 3 packets going.

Traffic Flow (fail/Suricata No Alert):
client → server syn
client → server ack
client → server tls client hello

FYI, when running in pcap mode uni-directional is working fine.

Bi-directional

if we have bi-directional traffic going through Suricata then it’s working fine, we can see Suricata is alerting.

Traffic Flow (work/Suricata Alert TLS SNI):
client → server syn
server → client syn|ack
client → server ack
client → server tls client hello

Fast.log

10/10/2023-16:10:01.206399  [**] [1:4:1] Alert by TLS SNI-EX [**] [Classification: (null)] [Priority: 3] {TCP} 10.129.135.2:41238 -> 15.2.0.100:443
2

I don’t think this is going to work as intended for what you describe as “uni-directional” traffic. Think that there’s a difference between uni-directional and one-side of the communication for tcp. In order for tcp to ensure transfer reliability (it’s the main reason it was designed) ACKs need to flag receipt of data. without that, Suricata won’t think it’s a valid tcp flow and it won’t try to match against any other protocol that have a valid tcp flow as a dependency.
One way to prove that hypothesis is to check the suricata “stats.log” and check for “tcp.sessions” field as well as “tcp.syn” and “tcp.synack” fields.

Without seeing a proper tcp handshake establishment and ACKs of send data (TLS handshake in your case) the only way to match against that would be a rule that has a raw packet content inspection check instead of a one that is based off “tls.sni”.

EDIT:
I missed that you’re using async-oneside and I missed that asyn-oneside is supposed to to exactly that. Is it set to true under the uncommented “stream:” keyword section in your config?

3

If I am reading this correctly, you may be hitting up against Bug #3218: ssl_state does the wrong thing - Suricata - Open Information Security Foundation

4

Originally in default stream: section the values were false.

stream:

midstream: false # don’t allow midstream session pickups

async-oneside: false # don’t enable async stream handling

we changed both the values to “true”.

6

Daniel,
We have async-oneside enabled but suricata is still not alerting one directional TLS Traffic.

7

You might be hitting the bug jt described above.
What does your stats.log show? In particular, what does app_layer.flow.tls field show between the working flow topology and the non-working (one-side) flow topology?