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.
proxy_rule_list,proxy_action,proxy_pinning_status,proxy_intercept_status,proxy_passthrough_reason,...,proxy_cert_verify,proxy_intercept_error,...,ssl_ja3_hash,ssl_ja3s_hash,ssl_cert_issuer,ssl_cert_subject,ssl_esni_flag,ssl_ech_flag
Defense implications
- Assume any TLS session through TSG-class middleboxes may be actively MITM'd and logged per-connection (cert issuer/subject captured) -- pinning alone only prevents decryption, not detection: proxy_pinning_status is logged regardless.
- ECH/ESNI adoption is explicitly tracked as its own flag rather than silently ignored -- expect ECH usage itself to become a distinguishing signal to this censor even before any content is inspected.
Related findings
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.
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.
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.
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.
MESA_Platform's "quic" module (built and packaged as stellar-on-sapp/sapp RPMs) implements SNI/User-Agent extraction from both cleartext GQUIC (versions 23-59) and encrypted IETF QUIC RFC9000 ClientHello payloads, and supports a QUIC SNI whitelist -- i.e. the DPI pipeline decrypts/parses encrypted QUIC handshakes to recover the destination domain rather than being blocked by QUIC's encryption.