Snort 4.1.10 / Snort 2.9.20: spp_ssl 137:1 false positive on TLS 1.3 HelloRetryRequest

jsokorp

Howdy,

I am reporting what appears to be a current reproducer for the longstanding Snort spp_ssl 137:1 false positive:

[137:1:2] (spp_ssl) Invalid Client HELLO after Server HELLO Detected
Timestamp: 2026-09-18 01:45:02.362346 -0500
Flow: 67.173.119.29:25220 -> 13.225.47.95:443
SNI: analytics.brew.sh

The alert was generated by a valid TLS 1.3 exchange involving a HelloRetryRequest (HRR). The capture shows the client sending an initial ClientHello, the server requesting a different key-share group, and the client sending a second ClientHello as required by the TLS 1.3 handshake. Snort reports the second client hello as an invalid client hello after the server hello.

Environment

pfSense: pfSense 2.9.0-RELEASE
Package: pfSense-pkg-snort-4.1.10
Snort package: snort-2.9.20_9
Snort: Snort 2.9.20 GRE Build 82
DAQ: DAQ 2.2.2_3
libpcap: 1.10.6
PCRE: 8.45
ZLIB: 1.3.2

Packet sequence

The relevant packet sequence is:

01:45:02.339237  ClientHello #1
01:45:02.361311  HelloRetryRequest
01:45:02.361678  ChangeCipherSpec
01:45:02.362346  ClientHello #2

The server's HelloRetryRequest asks the client to retry with the following key-share group:

Requested key_share group: 0x0017

The HRR can be identified by its TLS 1.3 magic random value:

cf21ad74e59a6111be1d8c021e65b891c2a211167abb8c5e079e09e2c8a8339c

The capture also contains the TLS 1.3 compatibility-mode ChangeCipherSpec record:

14 03 03 00 01 01

This is why I believe the alert is a false positive rather than evidence of an invalid client handshake. The second ClientHello is the expected response to the HelloRetryRequest, and the ChangeCipherSpec record is part of the compatibility behavior commonly seen in TLS 1.3 handshakes.

Reproduction material

The packet capture is attached as:

snort-137-1-014502.pcap

SHA256:

dbb6a1e7f79b987f7cdc35c30bf4b0839ef957053e85a129d4eee4a43447944f

Relation to earlier reports

This appears related to the longstanding spp_ssl 137:1 false-positive issue discussed in earlier Netgate Snort/Snort community threads. Those reports describe Snort losing track of the SSL/TLS stream and interpreting client and server hello messages out of order.

The current capture adds a more specific packet-level reproducer: on Snort 2.9.20, a standards-compliant TLS 1.3 HelloRetryRequest sequence still causes 137:1 to fire when the client sends the retried ClientHello.

Could this signature be reviewed for TLS 1.3 HRR handling, or otherwise updated so that a valid retry sequence does not generate this alert?

For reference, the suppression commonly used for this alert is:

#(ssp_ssl) Invalid Client HELLO after Server HELLO Detected
suppress gen_id 137, sig_id 1

I would prefer to avoid suppressing the signature globally if the underlying stream-tracking or TLS 1.3 parsing issue can be corrected, so I am including the capture and checksum for investigation.

bmeeks

Snort 2.9.20 is extremely old and the underlying binary is no longer really supported by the upstream Snort team. The problem you describe is very likely to be an error in the logic of the C source code within the binary piece of the Snort package. Snort on pfSense CE is actually two related but distinct packages. There is a binary executable piece that runs as a service and does the actual work of traffic inspection and blocking/alerting. On pfSense there is also a custom GUI package written in PHP that provides the unique GUI interface available on pfSense. Snort on most other platforms does not offer a GUI for configuration and the admin instead directly manipulates text-based configuration files.

Netgate has chosen to implement the new Snort3 code tree in pfSense Plus with Nexus. That is where future development efforts will be. I expect the current Snort 2.9.x package to eventually just die as there is no longer any maintainer and that code tree is obsolete. Snort 2.9.x is single-threaded whereas the newer Snort3 tree is multithreaded (and also rewritten in C++). Snort3 uses Lua for configuration files.

So, a long answer to say I would not expect this issue to be resolved in the old Snort 2.9.x code.