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
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
PA Updated by Philippe Antoine about 1 month ago
- Status changed from New to Feedback
Not sure what we want to do about this :
We set the flow to some skip_inspection state after seeing the first encrypted packet
Should we have a config parameter to try to inspect new packets ?
PA Updated by Philippe Antoine about 1 month ago
I guess we would need a HashMap per ConnectionID of what we currently have in the QuicState (for the quic crypto frame reassembly)
PA Updated by Philippe Antoine 9 days ago
- Tracker changed from Security to Bug
- Private changed from Yes to No
PA Updated by Philippe Antoine 9 days ago
- Status changed from Feedback to In Review
Actions