Project

General

Profile

Actions

Bug #7476

open

Suricata tls.sni check fails when PQC KEMs like kyber

Added by Shashank Gugalia about 2 months ago. Updated 21 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

As clients begin migrating to PQC, such as the latest versions of Chrome and Golang which now use the Kyber KEM, many of our SNI-based rules have stopped functioning.

Example rule:
pass tls any any -> any any (msg:"Allow connection to test.openquantumsafe.org/"; flow:to_server,established; tls.sni;content:"test.openquantumsafe.org"; nocase; isdataat:!1,relative; sid:1;)
rejectboth tls any any -> any any (msg:"Unauthorized TLS outbound connection in any"; flow:to_server,established; sid:2;)

Example request: curl --verbose --curves kyber768:X25519 https://test.openquantumsafe.org/
Note :Communication works if I don't overwrite the curve

Logs from even.json: {"timestamp":"2025-01-02T20:20:15.023011+0000","flow_id":1866019709982669,"event_type":"alert","src_ip":"10.128.0.6","src_port":40248,"dest_ip":"158.177.128.14","dest_port":443,"proto":"TCP","pkt_src":"wire/pcap","alert":{"action":"blocked","gid":1,"signature_id":1,"rev":0,"signature":"Unauthorized TLS outbound connection","category":"","severity":3},"tls":{"version":"UNDETERMINED"},"app_proto":"tls","direction":"to_server","flow":{"pkts_toserver":3,"pkts_toclient":1,"bytes_toserver":1572,"bytes_toclient":60,"start":"2025-01-02T20:20:14.893218+0000","src_ip":"10.128.0.6","dest_ip":"158.177.128.14","src_port":40248,"dest_port":443}}

Here is the suricata build info

This is Suricata version 7.0.4 RELEASE
Features: NFQ PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HTTP2_DECOMPRESSION HAVE_LUA HAVE_LIBJANSSON TLS TLS_C11 MAGIC RUST 
SIMD support: SSE_4_2 SSE_4_1 SSE_3 
Atomic intrinsics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 11.4.1 20230605 (Red Hat 11.4.1-2), C version 201112
compiled with _FORTIFY_SOURCE=0
L1 cache line size (CLS)=64
thread local storage method: _Thread_local
compiled with LibHTP v0.5.47, linked against LibHTP v0.5.47

Suricata Configuration:
  AF_PACKET support:                       yes
  AF_XDP support:                          no
  DPDK support:                            yes
  eBPF support:                            yes
  XDP support:                             yes
  PF_RING support:                         no
  NFQueue support:                         yes
  NFLOG support:                           no
  IPFW support:                            no
  Netmap support:                          no 
  DAG enabled:                             no
  Napatech enabled:                        no
  WinDivert enabled:                       no

  Unix socket enabled:                     yes
  Detection enabled:                       yes

  Libmagic support:                        yes
  libjansson support:                      yes
  hiredis support:                         yes
  hiredis async with libevent:             yes
  PCRE jit:                                yes
  LUA support:                             yes
  libluajit:                               no
  GeoIP2 support:                          yes
  Non-bundled htp:                         no
  Hyperscan support:                       yes
  Libnet support:                          yes
  liblz4 support:                          yes
  Landlock support:                        yes

  Rust support:                            yes
  Rust strict mode:                        no
  Rust compiler path:                      /usr/bin/rustc
  Rust compiler version:                   rustc 1.71.1 (eb26296b5 2023-08-03) (Red Hat 1.71.1-1.el9)
  Cargo path:                              /usr/bin/cargo
  Cargo version:                           cargo 1.71.1

  Python support:                          yes
  Python path:                             /usr/bin/python3
  Install suricatactl:                     yes
  Install suricatasc:                      yes
  Install suricata-update:                 yes

  Profiling enabled:                       no
  Profiling locks enabled:                 no
  Profiling rules enabled:                 no

  Plugin support (experimental):           yes
  DPDK Bond PMD:                           no

Development settings:
  Coccinelle / spatch:                     no
  Unit tests enabled:                      no
  Debug output enabled:                    no
  Debug validation enabled:                no
  Fuzz targets enabled:                    no

Generic build parameters:
  Installation prefix:                     /usr
  Configuration directory:                 /etc/suricata/
  Log directory:                           /var/log/suricata/

  --prefix                                 /usr
  --sysconfdir                             /etc
  --localstatedir                          /var
  --datarootdir                            /usr/share

  Host:                                    x86_64-pc-linux-gnu
  Compiler:                                gcc (exec name) / g++ (real)
  GCC Protect enabled:                     no
  GCC march native enabled:                no
  GCC Profile enabled:                     no
  Position Independent Executable enabled: no
  CFLAGS                                   -g -O2 -fPIC -std=c11 -I/usr/include/dpdk -include rte_config.h -march=corei7  -I${srcdir}/../rust/gen -I${srcdir}/../rust/dist
  PCAP_CFLAGS                               
  SECCFLAGS         

Files

oqs.pcap (1.99 KB) oqs.pcap Shashank Gugalia, 01/06/2025 07:58 PM
oqs_without_suricata_rejectrule.pcap (206 KB) oqs_without_suricata_rejectrule.pcap Shashank Gugalia, 01/07/2025 10:02 PM
tcpump.pcap (10.2 KB) tcpump.pcap Shashank Gugalia, 01/31/2025 07:54 PM
Actions #1

Updated by Shashank Gugalia about 2 months ago

  • Description updated (diff)
Actions #2

Updated by Victor Julien about 2 months ago

  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

Can you attach a pcap or create a full Suricata-Verify test?

Actions #3

Updated by Shashank Gugalia about 2 months ago

Attaching the pcap captured at the client host

Actions #4

Updated by Victor Julien about 2 months ago

Do you also have a pcap from a successful session (so w/o Suricata)? The current pcap appears to work correctly.

Actions #5

Updated by Shashank Gugalia about 2 months ago

Attaching pcap where its working.

Also was not clear with your comment "The current pcap appears to work correctly"

Like curl actually failed with connection reset error, so when you say its working correctly I am not very clear what you meant by that

Actions #6

Updated by Victor Julien about 2 months ago

Based on the pcaps, things work as expected. The sni rule matches and puts the flow into "pass" mode. I've tested with IPS mode.

Can you describe your setup? Runmode, capture settings, IPS/IDS, etc?

Actions #7

Updated by Shashank Gugalia about 1 month ago

We using IPS mode with these config overwritten
runmode: workers

nfq:
mode: accept
batchcount: 5
fail-open: yes

Default suricata.yaml gets is taken from https://github.com/jasonish/docker-suricata/tree/main/7.0

Actions #8

Updated by Shashank Gugalia about 1 month ago

Hi Victor,

Please let me know if you need info/data from my end

Thanks
Shashank

Actions #9

Updated by Shashank Gugalia 22 days ago

Another pcap for releases.hashicorp.com where we are getting connection reset

Actions #10

Updated by Shashank Gugalia 22 days ago

Pass rule is
pass tls $src_ip any -> any 443 (msg:"Allow terraform binaries from releases.hashicorp.com"; flow:to_server,established; tls_sni; content:"releases.hashicorp.com"; nocase; isdataat:!1,relative; sid:77002;)

Actions #11

Updated by Victor Julien 21 days ago

I believe this is not related to the specific curve, but instead is due to the client hello getting split over multiple packets due to it's size. This leads to a problem with the rules above.

Packet X:

[ client hello part 1]: TLS detection, toserver, establised, so sid:2 matches

Packet Y:

[ client hello part 2]: client hello parsed, SNI available

What happens here is that the reject rule triggers for packet X, since all conditions match. Packet Y completes the client hello, which means only then sid:1 is evaluated.

The problem is that this scenario is not well supported, as the rule language doesn't give you a way to pass packet X currently.

There is work ongoing to address this, see:
#7164, #7485
https://github.com/OISF/suricata/pull/12422
https://github.com/OISF/suricata-verify/pull/2239/files#diff-9c1a8fa7b32b878c51333b3e87a2bdc2e91afd1efed930faf15ffe7b8a0c0593

Actions

Also available in: Atom PDF