TSG's TLS ClientHello parser (MESA_Platform/ssl GitLab component) explicitly parses the ec_point_format extension from ClientHello, confirming deep TLS extension-level fingerprinting beyond simple SNI extraction.

A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.

An internal field-mapping schema for TLS/SSL session logging (cross-referenced against multiple internal system versions, one explicitly labeled "tsg") shows JA3 and JA3S TLS ClientHello/ServerHello fingerprint hashes are captured as standard logged fields alongside SNI, negotiated cipher suites, and the full server and mutual-TLS client certificate chains (issuer, subject, serial, validity window, raw public key).

Session records carry client and server TLS fingerprints (ssl_ja3_hash, ssl_ja3s_hash) and equivalent DTLS fingerprints (dtls_ja3_fingerprint, dtls_ja3_hash) as first-class columns, and the same schema separately includes an SSH client/server fingerprint field (ssh_hassh) alongside ssh_cipher_alg/ssh_kex_alg/ssh_host_key_alg -- confirming JA3/JA3S-style and HASSH-style fingerprinting is computed and retained per session across TLS, DTLS, and SSH traffic, not just TLS.

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.

The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author name redacted, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.

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').