The "stellar" QUIC decoder plugin implements a complete RFC 9001 QUIC Initial-packet header- and payload-deprotection pipeline (HKDF key derivation from the well-known public IETF/gQUIC initial salts, AES-128-GCM payload decryption, AES-CTR header-protection removal) to decrypt QUIC ClientHello messages in real time, reassembling CRYPTO frames fragmented across multiple UDP datagrams, and extracts SNI and User-Agent from the decrypted handshake. It separately parses legacy Google QUIC (gQUIC) CHLO tag-value blobs (TAG_SNI / TAG_UAID) for older/non-IETF QUIC variants, and recognizes version ranges for a long list of QUIC implementations (mvfst, quant, quicly, msquic, mozquic, picoquic). A config flag (DECRYPTED_SWITCH) toggles whether the decrypt-and-inspect pass runs.
case TAG_SNI: copy_extension_tag(payload+tag_value_start_offset, one_tag_len, &quic_info->sni); parse_result=PARSE_RESULT_CLIENT_HELLO; break;
Defense implications
- This deployment fully decrypts standard QUIC Initial packets using the public RFC 9001 salts to read ClientHello SNI in the clear — any QUIC-based transport that uses unmodified standard QUIC framing (including the standard Initial-packet salt) is fully SNI-visible to this class of DPI, regardless of TLS 1.3 being 'encrypted'.
- Legacy Google QUIC (gQUIC) CHLO tag parsing (TAG_SNI/TAG_UAID) is implemented alongside modern IETF QUIC, so falling back to older gQUIC framing for cover offers no additional protection against this decoder.
- The decrypt-and-inspect path is gated by a config toggle (DECRYPTED_SWITCH, default enabled) rather than being hardcoded — worth noting for measurement work distinguishing which deployments currently have QUIC SNI-extraction turned on versus merely QUIC protocol identification.
Cited artifacts
mesalab_git—stellar/quic_decoder.bundle:src/quic_deprotection.cpp(source-code)mesalab_git—stellar/quic_decoder.bundle:src/quic_process.cpp(source-code)mesalab_git—stellar/quic_decoder.bundle:src/quic_entry.cpp(source-code)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
A TSG-Application blocklist test found that disabling Facebook/Twitter in TSG's per-app policy did not stop Psiphon3 traffic from reaching those services in practice, because Psiphon3's dual-stack fallback drove the tunneled Facebook traffic over IPv4 QUIC, which TSG's classifier failed to attribute to Facebook -- in contrast to Taobao/Bilibili/Youku/JD, which TSG blocked successfully in the same test.
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.
A Sept 2021 MESA research report analyzes a Chinese patent (application 200710130726.7) for out-of-path UDP session blocking via forged ICMP destination/port-unreachable packets injected by raw socket, verifies the exact Linux 3.10.0 kernel code path that propagates the resulting ECONNREFUSED to the application layer, and empirically demonstrates it fully blocks Chrome's QUIC connections to Google (effective for all 16 ICMP unreachable subcodes, and through NAT), with Chrome falling back to HTTP/2 within seconds; combining it with TCP RST additionally blocks the HTTP/2 fallback.
Internal engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core Xeon E5.