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.
sapp A使用PAG接口，通过mrzcpd（在线捕包驱动程序）获取原始流量（密文），挂载通联和密文管控插件。sapp B通过UDS接口（域名间套接字）从第三方解密平台获取并处理解密后流量（明文）。
Defense implications
- TLS MITM decryption coverage against real port-443 traffic in this test was low (~7% of connections) and slow (avg 1.7s latency, up to 6s) -- a protocol whose blocking-relevant exchange completes quickly may finish before the MITM-triggered policy decision on decrypted content lands.
- The raw-vs-decrypted two-sapp split architecture means any blocking decision that depends on decrypted content trails raw-traffic-only blocking by roughly half a second to several seconds; this is a timing window, not an evasion of detection on the raw-traffic side.
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.
An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.
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.
TSG ships a built-in offensive "active defense" (主动防御) module named houyi (后羿), built on the sapp/marsio/mrzcpd stack, that performs spoofed-source-IP network-layer flood attacks, DNS/NTP/Memcached reflection-amplification attacks, and application-layer (HTTP/HTTPS) CC floods against a configured target. Spoofed source IPs are drawn from named CIDR-range "profiles" (e.g. 10.1.1.0/24), and policy is distributed via Redis and issued either through an interface called "安天" (Antiy) or by directly calling a "毕方" (Bifang) API. Deployment is via Ansible from git.mesalab.cn/tsg/houyi-deploy, packaged as RPMs installed under /opt/houyi and as sapp plugins under /home/mesasoft/sapp_run/plug.
Confirms a TSG-X/TSG-OS (v22.11) deployment at "新疆联通IDC" (Xinjiang Unicom IDC, a specific China Unicom data center), part of a domestic "XJ-NPM" project; core traffic-processing components are named "mrzcpd" and "sapp," both required to start successfully for the appliance to function.