TSG runs two separate detection engines: a licensed third-party DPI engine for general app/protocol identification (requires per-environment authorization -- absent in a demo environment caused a detection gap), and a Geedge-built component ('glimpse_detector') specifically for VPN protocol identification (WireGuard, OpenVPN). App-ID numbering (e.g. built-in wireguard=3700) can be silently shadowed by environment-specific custom IDs, causing detection to fail even when the underlying protocol is correctly classified.
问题1：第三方DPI未获得授权 ... glimpse_detector本地读包都能正确识别对应的APP ... wireguard在京版是3700，demo环境变成15022了
Defense implications
- Detection reliability for this system depends on synchronized ID mappings between a central signature DB and each site's local config -- deployments that skip a DB update cycle, or whose licensing lapses on the third-party engine, plausibly have real (if unintentional) detection gaps worth probing for in a specific target deployment before assuming full capability.
Related findings
Raw TSG session_record export logs dated Nov 2024, tagged device_group 'YGN-MYTEL' (Yangon, Mytel), directly corroborate the leak's M22=Myanmar/Mytel/Yangon site-codename mapping with live production data: individual SSL sessions are classified by app as 'Hotspot Shield VPN' (destination get.adobe.com, likely a fronting/CDN endpoint) and allowed under a named whitelist rule 'whitelist_102024', geolocated client-side as Myanmar.Yangon.Yangon.
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.
As of TSG's SSL/protocol parser in 2022, in-band STARTTLS negotiation (observed via XMPP) was not supported by the SSL parsing logic, causing app-identification-based blocking to silently fail for STARTTLS-negotiated sessions; the workaround was a manual TCP-payload string match rather than proper protocol classification. Confirm current status before relying on this -- single 2022-dated ticket, may since be patched.
A June 2021 MESA Lab test report ("精管流量初步分析报告") measured a live TLS-decryption pipeline feeding two sapp instances -- sapp A ingesting raw encrypted traffic via mrzcpd, sapp B ingesting plaintext from a third-party decryption platform over a Unix domain socket -- and found decrypted plaintext covered only 4.85% of raw traffic bytes and 7.4% of port-443 connections, with average MITM decryption latency of 1741ms (range 158-6000ms) across 2957 matched connections.