Encrypted ClientHello / ESNI blocking
also: ECH blocking, ESNI blocking
The `session_record` schema includes explicit boolean-style flag columns ssl_esni_flag and ssl_ech_flag, confirming that TSG/Galaxy tags every session with whether Encrypted SNI or Encrypted ClientHello was used -- giving the operator session-level visibility into ECH/ESNI adoption even where it cannot decrypt the underlying SNI.
An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').
In the same live TSG capture, rows show ssl_ech_flag=1 recorded for real observed TLS sessions (to connect-api.guardianapp.com) alongside a populated ssl_ja3_hash and an intact ssl_sni value, and the session was still denied by name-based rule Deny_Brave. This confirms the DPI engine parses and logs the TLS ClientHello ECH extension as a distinct per-session flag in production/test traffic, i.e. ECH usage is visible to the gateway even though SNI in this particular capture was not itself encrypted from the classifier's point of view.
The same 224-column TSG per-session log schema carries a full TLS- interception field set — proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, sc_rsp_raw and sc_rsp_decrypted (raw vs. decrypted server response content) — plus ssl_esni_flag and ssl_ech_flag (explicit ECH/ESNI-usage flags), ssl_ja3_hash/ssl_ja3s_hash, and ssh_hassh (SSH client fingerprinting), confirming certstore-style MITM interception, ECH/ESNI detection, and TLS/SSH fingerprinting are all first-class fields logged on every session, not experimental add-ons.
A raw TSG session-log export shows the full production log schema: per-flow fields include subscriber_id, imei, imsi, phone_number and apn alongside ssl_ja3_hash/ja3s_hash, ssl_esni_flag, ssl_ech_flag, quic_sni, dtls_ja3_fingerprint, and proxy_pinning_status/proxy_intercept_status/ proxy_cert_verify fields for the MITM proxy path. This confirms TSG's session logging natively joins network-flow identity to subscriber identity and captures TLS fingerprint/ESNI-ECH state and MITM-interception outcome in the same record.
A 2024 IIE CAS thesis proposal (advisor name redacted, a senior-grade engineer) explicitly frames "website identification under ECH encryption" as necessary infrastructure for China's CAC/MIIT/MPS "Clean Web"/"Sword Net" enforcement campaigns, and reports concrete progress already made: a Go-based DNS active-probing framework scanning 1.7B+ domains at roughly 11,000 domains/sec to build a global ECH-deployment map (10 anonymity sets / 79 domains found as of April 2024), and an already-implemented ECH-flow filter keyed on the TLS extension-type IDs used across ECH draft versions 07-18, with planned work on cross-flow traffic correlation plus raw-byte/flow-feature fusion to identify the specific site within an ECH anonymity set.
A MESA Lab Go tool (modikai/edns_svcb_https) measures EDNS, SVCB, and HTTPS DNS record support across a top-1M domain list and a set of DNS servers — record types that carry Encrypted ClientHello (ECH) configuration, suggesting reconnaissance ahead of possible ECH-aware blocking.
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 MESA Lab thesis/report states that ESNI/ECH protocol-identification technology, based on TLS extension field type numbers, "has already been applied in actual projects," and lists the researcher's own project participation as "G1系统 - ESNI、ECH加密协议识别" (Feb-Aug 2023) and "G1系统 - QUIC协议旁路ZD" (Feb-Nov 2023, QUIC bypass/blocking), plus a separately implemented "DNS主动探测模块" (DNS active-probing module, marked 已实现/already implemented). "G1" also appears independently as a named legacy system in the Maat/Transformer DPI header (PROTO_VPN comment: "G1历史遗留"), corroborating it as a real internal system name, not a typo.
The MESA_Platform/gquic sapp plugin extracts SNI and User-Agent across a wide range of QUIC implementations/versions (Google QUIC 23/25/33/34/35/37/39/41/43/44/46/48/50, IETF QUIC draft-29 and RFC9000, plus QUANT/PicoQUIC/quic-go/quicly/MsQuic/mvfst/TQUIC), including a dedicated Aug 2021 feature to 'support parsing encrypted SNI for QUIC RFC9000' — i.e. the DPI engine derives/decrypts QUIC Initial-packet protection to recover the TLS ClientHello SNI even from RFC9000's protected header.
The same SSL plugin added explicit detection of the Encrypted Client Hello extension (type 0xFE0D) with test cases in June 2023, and separately implements JA3/JA3S (2020) and JA4/JA4S (2024) TLS client/server fingerprint calculation as first-class features -- so TSG-class DPI can flag 'ECH is in use' even without decrypting it, and independently fingerprints TLS stacks via JA3/JA4.
A leaked SQL migration renames/normalizes a session-attribute-dictionary entry to `ssl.analysis.sni_absent` (backed by virtual_table `ATTR_SSL_NO_SNI`), confirming the detection pipeline maintains an explicit, first-class boolean signal for "TLS ClientHello with no SNI present" — a classic tell for ECH, domain fronting, and custom TLS stacks that omit SNI to evade SNI-based blocking.
MESA Lab's "stellar" SSL/TLS decoder (ssl_decoder, packaged in test fixtures as "stellar-on-sapp") ships a dedicated regression test case captured against an Ethiopia (E21) target host, alongside TLS 1.3 ESNI, encrypted ClientHello (ECH), and TachyonVPN-client test pcaps, showing the decoder is validated both against E21-deployment-style traffic and emerging TLS privacy extensions.
A DPI session-plugin ("stellar" framework) SSL/TLS decoder fully parses live ClientHello/ServerHello handshakes, computing JA3/JA3S fingerprints (MD5 over version+cipher-suites+extensions with GREASE values stripped per the standard JA3 spec), extracting plaintext SNI, explicitly flagging whether a ClientHello carries ESNI (extension type 0xFFCE) or ECH (extension type 0xFE0D), and decoding full X.509 certificate chains (issuer/subject RDN sequences, SAN, validity window, serial, pubkey, signature algorithm) in real time. It also recognizes TLCP 1.0 (China's national "国密"/GmSSL TLS variant) as a distinct protocol version alongside SSLv2 through TLS1.3.
chongming/traffic_replay is a Flask/tcpreplay-based QA harness that replays curated pcaps against a TSG instance to exercise its decoders, including SSL fixtures specifically named ssl_ech_false.pcap, ssl_no_sni.pcap and ssl_tls13.pcap alongside esni.pcap, openvpn.pcap, and major-platform captures (facebook/google/twitter/ youtube). A companion update_tsg_ca.py/tsg_ca.txt installs a TSG-issued CA cert on the test client, confirming the QA environment exercises TLS interception as part of routine detection testing.
Two independently-leaked TSG session-log CSV exports share an identical 224-field schema whose proxy_* columns (proxy_action, proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_intercept_error) log the outcome of TLS interception per session, alongside ssl_ja3_hash/ssl_ja3s_hash, ssl_esni_flag, ssl_ech_flag, and quic_sni fields — confirming MITM/cert-pinning-bypass instrumentation and TLS/QUIC fingerprinting are built into TSG's standard traffic-logging pipeline, not a bolt-on feature.
A leaked TSG session-log CSV schema (device XXG-TSG-BJ) includes built-in per-session fields for TLS interception status (proxy_intercept_status, proxy_cert_verify, proxy_pinning_status, proxy_passthrough_reason) alongside JA3/JA3S TLS fingerprints and explicit ssl_esni_flag/ssl_ech_flag columns, confirming TSG logs whether a session was MITM'd and whether it used ECH/ESNI.
The full TSG session-log CSV schema header discloses the complete set of per-session fields the platform records, including TLS JA3/JA3S fingerprint hashes, explicit ssl_esni_flag/ssl_ech_flag columns, QUIC/DTLS SNI and JA3 fields, and direct subscriber-identity fields (subscriber_id, imei, imsi, apn, phone_number) captured on every logged session alongside ordinary network 5-tuple data.
TSG's core traffic-processing daemon (tango/tsg_master) added explicit support for treating Encrypted ClientHello (ECH) as a security-policy match condition (TSG-15163/TSG-15711) and tags app_full_path output with ESNI and ECH markers (TSG-15779), meaning field TSG deployments can write and enforce policy rules that specifically key on ECH/ESNI usage rather than only on plaintext SNI.
The same TSG QA suite includes purpose-built "hijack" test fixtures for at least seven content types (APK, EXE, GIF, HTML, JPEG, PNG, SVG) alongside JS/CSS insertion scripts and Lua replace/insert manipulation scripts, and its UI/API test cases reference a "Manipulation" policy object with replace/hijack/deny(drop) actions triggered by "Keywords" objects inside "http_signature" matching and an explicit "no_sni" traffic-matching condition; separate pcap test fixtures (esni.pcap, ssl_ech_false.pcap, ssl_no_sni.pcap, ssl_tls13.pcap) show this is specifically regression-tested against ESNI/ECH and SNI-less TLS 1.3 traffic.
TSG's security-policy verification engine (tango/verify-policy) supports 'ssl.no_sni', 'ssl.ech' (Encrypted ClientHello), and 'ssl.esni' (Encrypted SNI) as first-class Boolean match conditions in its policy language (TSG-18943), meaning TSG can write and evaluate blocking/monitoring policies that specifically trigger on TLS connections carrying no SNI, ECH, or ESNI.