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.
proxy_rule_list,proxy_action,proxy_pinning_status,proxy_intercept_status,proxy_passthrough_reason,proxy_server_side_latency_ms,proxy_client_side_latency_ms,proxy_client_side_version,proxy_server_side_version,proxy_cert_verify,proxy_intercept_error
Defense implications
- Assume any TSG-adjacent link can log JA3/JA3S TLS fingerprints, ESNI/ECH presence flags, and QUIC SNI per-session; randomize/rotate ClientHello fingerprints rather than relying on TLS alone to blend in.
- The schema logs proxy_cert_verify and proxy_pinning_status per session, meaning cert-pinning-detection is a first-class, always-on signal for the operator, not a special case — pinning alone will not go unnoticed even if it defeats interception.
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.
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.
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.
TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).
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.