Project

General

Profile

Actions

Bug #8776

open
PA

quic: SNI detection evasion when a new connection reuses an existing UDP five-tuple

Bug #8776: quic: SNI detection evasion when a new connection reuses an existing UDP five-tuple

Added by Philippe Antoine about 1 month ago. Updated 9 days ago.

Status:
In Review
Priority:
Normal
Assignee:
-
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs Suricata-Verify test

Description

Original report

Hello OISF Security Team,
I am reporting a potential QUIC detection-evasion issue affecting Suricata 8.0.6. I reproduced it in passive IDS mode using AF_PACKET.
Summary
Suricata appears not to inspect a second QUIC ClientHello when a new QUIC connection reuses an existing UDP five-tuple before the corresponding Suricata flow expires.
In my test:
The client sent a valid QUIC Initial containing SNI = google.com.
Suricata detected and logged this SNI.
The client then reused the same source IP, source UDP port, destination IP, destination UDP port, and protocol to start a new QUIC connection.
The second connection used independent QUIC/TLS state and a different Initial Connection ID, with SNI = www.dongbeirain.fun.
The second handshake completed successfully and application data was exchanged.
Suricata produced no QUIC event, SNI metadata, alert, or anomaly corresponding to the second ClientHello.
An IDS rule matching www.dongbeirain.fun did not trigger.
I have only confirmed this behavior in passive IDS mode. I have not yet tested inline IPS mode.
Environment
Suricata: 8.0.6 RELEASE
OS: Ubuntu 24.04
Capture mode: AF_PACKET passive IDS
QUIC parser: enabled
Interface: wlp2s0 (i checked wifi hotspot interface where request from a phone)
Expected behavior
Because the second Initial starts an independent QUIC connection and contains a separately decryptable ClientHello, Suricata should inspect it and expose:
quic.sni = www.dongbeirain.fun
The detection rule should then match.
Actual behavior
Suricata reports only:
quic.sni = google.com
The second ClientHello is not exposed to the rule engine, even though the second connection succeeds.
My preliminary hypothesis is that Suricata retains one QUIC parser state for the UDP flow and does not create a new parser context when another Initial with a different Connection ID appears on the same five-tuple.
Attachments
I have attached:
A minimized reproducer (https://github.com/jiangshaoqi/QUIC-sni-check-client, with your valid cert for test);
A PCAP containing both QUIC connections;
The Suricata configuration  (enable quic check on dst 4434, as set on my QUIC server);
eve.json, suricata.log, and stats.log corresponding snippet;
The attachments are confidential and are provided solely for OISF’s private security evaluation (.json file shows the only SNI identified but pcap indicates the first SNI and second). Please do not publish them without my prior consent.
I am reporting this under the OISF Security Policy and defer severity assessment, disclosure timing, and CVE handling to OISF.
Reporter:
Name: Shaoqi Jiang
Affiliation: Concordia University
GitHub handle: jiangshaoqi
Credit preference: PUBLIC CREDIT
Regards,
Shaoqi Jiang
Actions

Also available in: PDF Atom