At the K18 site, TSG's TLS-interception ("Tera") steering rules failed to cover all of a CDN-fronted site's IPs (avg.com via Akamai): certificate replacement succeeded on one resolved IP (185.189.92.41) but not another (23.61.224.112), indicating Tera's per-IP steering configuration can miss a fraction of a multi-IP CDN's address space.
当域名到23.61.224.112，无拦截效果，当域名解析到185.189.92.41是，有拦截效果...I think some IP addresses may be missed from Tera's steering rules
Defense implications
- Fronting behind large, dynamic-IP CDNs increases the odds of landing on an IP outside TSG's static interception steering rules, a partial, site-specific evasion path rather than a guaranteed one.
Related findings
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 郑超, 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.
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.
An internal SQL query cookbook targets a ClickHouse-style database 'tsg_galaxy_v3.session_record' with example top-10 breakdowns by common_l4_protocol, common_client_ip, common_server_ip, common_app_id, common_app_label, http_domain, and — notably — common_subscriber_id, plus filtered variants (e.g. by http_domain LIKE '%baidu.com%' or by a specific client IP) using a 1-in-10 sampling trick (cityHash64(common_recv_time) % 10 = 0). This names the internal analytics database and confirms subscriber-level session records are a standard, first-class query dimension, not an edge case.
Raw TSG session_record CSV exports (header row `recv_time,log_id,decoded_as,session_id,...`) show a ~224-column per-session logging schema that goes far beyond blocking metadata: subscriber_id/imei/imsi/apn/phone_number identity fields, full DNS query/response, HTTP with a cleartext mail_password field for mail protocols, TLS JA3/JA3S hashes, cert issuer/subject, ESNI/ECH flags, SIP/RTP VoIP metadata, SSH hassh fingerprints, RDP client details, and cryptocurrency-mining (stratum) protocol detection. This is a general-purpose deep-inspection/logging pipeline, not a narrow blocklist filter.
Live TSG session logs from an internal test/QA gateway (device_id 9800165603191146 / 21426003, data_center label XXG-TSG-BJ) show real sessions from named commercial VPN apps — AlohaBrowserLite, BeePassVPN, BravePrivateVPN (WireGuard), Proton VPN, Turbo VPN, CyberGhost, BetternetVPN, SuperUnlimitedVPN, TrustzoneVPN and VPNHero — each matched to a dedicated per-app security rule (e.g. Deny_Brave, Deny_BeePassvpn, deny_Super Unlimited VPN) and given security_action=Deny. One row's app_transition field records a layered classification chain 'Psiphon Provider' -> ... -> 'BravePrivateVPN' for a single session, indicating the engine attempts nested/tunnel-in-tunnel protocol identification, not just single-label app ID.