A December 2022 MESA Lab student monthly report (advisor 周舟) describes a live mid-term project review demo merging HTTPS, RDP, and SSH man-in-the-middle interception onto a single VM with unified start/stop scripting, alongside work on an internal "SSFY" standard/ specification document, SSL-strip measurement against the Alexa top-50 domains, and directed reading on detecting proxy traffic via nested TLS handshakes and on residential proxies as an active research topic.
1、mitm演示（11.21—11.23） • 合并https、rdp、ssh三个协议中间人到一台虚拟机。 • 写脚本统一启停，项目中期现场演示 ... 域间路由、非对称路由、家庭网络接入、住宅代理、TLS1.3、QUIC、HTTP3.0、反向代理nginx、LVS ... 细读论文一篇《通过嵌套TLS检测代理流量》
Defense implications
- MITM interception is confirmed to extend beyond HTTPS/TLS to RDP and SSH on a unified platform — do not assume tunneling a Lantern transport inside RDP or SSH framing is a MITM blind spot for this group.
- Active research interest in detecting proxy traffic via nested/encapsulated TLS handshakes (matching the USENIX-2024 'Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes' line of work) and in residential proxies specifically means any TLS-in-TLS tunneling design should be evaluated against that exact detection technique before relying on it.
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.
An internal design note for a 'Shadowsocks traffic parsing/restoration module' describes decrypting captured Shadowsocks payloads back to the original HTTP request/response, given a known pre-shared key (AES-256-CFB, MD5-derived key, IV embedded in the stream).
A dedicated internal "运营商前端分析团队" (Carrier Front-end Analysis Team) produces weekly, carrier-specific traffic-analysis reports explicitly titled "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report), with instances dated from at least July 2022 through March 2024. One instance (Xinjiang Mobile, 2023-05-15) reports total carrier bandwidth of 4.4Tbps (1Tbps access bandwidth), 27.34PB of weekly throughput, 123 distinct identified application-layer protocols, and a section (4.1, pages 17+) explicitly tracking server IP/location for 28 named overseas apps (BBC, Discord, ESPN, Facebook, Gmail, Google, Hulu, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Uber, WhatsApp, Wikipedia, YouTube, Zoom, etc.).
A 2018 MESA Lab monthly report describes work on the "GPS"/"先导" (Pioneer) active-probing projects: adding IPv6 scanning support and simultaneous 3-domain scanning to MAAT, alongside active-probing experiments (nslookup/dig/nmap) and root-DNS-server BGP-anycast measurement -- indicating MAAT's rule engine is paired with an active network-scanning subsystem, not purely passive/inline matching.
An internal 'MAAT Configuration Description Manual (String)' fully documents MAAT's rule-compilation model: per-field string matches (substring/prefix/suffix/exact/regex/AND-of-substrings/offset-anchored substrings) grouped into up to 8 AND/NOT clauses per compiled rule (conjunctive normal form), each carrying an action code (0=block, 1=monitor-only, 2=whitelist), blacklist and logging flags, and a floating-point execution-order field for safe rule reordering, plus the C scanning API (Maat_full_scan_string) and the file/JSON formats used to push rule updates to production.