An internal MITM-techniques presentation (name redacted, dated 2024.8) surveys ARP/DNS spoofing and HTTPS/SSH/RDP/email/IPsec MITM, then demonstrates two hands-on tests specifically involving a circumvention tool: (1) a forward-proxy test routing an Aliyun-VPS mitmproxy instance in upstream mode into "翻墙工具Clash" (the circumvention tool Clash) to reach overseas web services, showing that once the client trusts the mitmproxy root CA, keyword-based content filtering works transparently through the Clash tunnel (blocking "毒品"/drugs searches on Google Scholar while allowing normal queries, and blocking google.com outright); and (2) a transparent-proxy/SSL- stripping test on a dual-NIC hardware box that downgrades HTTPS to HTTP and applies the same keyword/URL filtering with zero client configuration.
配置VPS为自身代理服务器，Mitmproxy upstream模式，使用upstream模式将流量代理到翻墙工具Clash，进而访问境外Web服务... 客户端安装信任此根证书... 在其页面搜索毒品等违禁词，会出现无法访问页面，而搜索正常内容，可以正常访问，同时访问https://www.google.com,出现无法访问页面，说明进行了合规性过滤。
Defense implications
- This is a hands-on demonstration that keyword-based content filtering works even when the client is already routing through the circumvention tool Clash upstream, because the interception happens on the client machine's own outbound hop (trusted root CA, or transparent SSL-stripping) before Clash's proxy layer ever sees the traffic. Any deployment model where the client device itself can be MITM'd (compromised root store, transparent inline box, forced HTTPS downgrade) defeats the outer proxy tool's protocol strength entirely — Lantern's threat model should treat client-endpoint compromise as a bypass of transport-layer defenses, not just a network-path attack.
Related findings
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 MESA Lab research note directly measures and compares China's ('CN') HTTP censorship middlebox against Russia, India and an unlabeled 'HZ' system, plus open-source Snort2/Snort3/Suricata: China is characterized as inspecting Host- and keyword-based triggers (example trigger given: a request containing the parameter 'q=ultrasurf') across ALL ports rather than just 80/443, responding with a triple RST or an extra RST+ACK; an 8-technique HTTP-request-mangling evasion comparison table credits China's middlebox as vulnerable only to request-line whitespace insertion and HTTP-version tampering, fewer categories than the other three systems tested.
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.
Internal MAAT engineering Q&A notes detail the rule engine's filter hierarchy: a 'region' config matches on keyword / regex / IP / extended-IP(CIDR) / numeric / file-digest / text-similarity / FQDN fields; regions roll up via AND/OR into 'group' configs; groups roll up into an 8-clause-max 'compile' config in conjunctive normal form. Rule config is pushed via a Redis single-primary/multi-replica tree, and MAAT itself is not distributed — each production front-end box runs its own single MAAT instance that receives pushed config and calls the shared rulescan library to execute the actual scan.
A weekly operational report documents newly-added blocking rules for 25 mobile apps (18 hosted overseas, mostly on Hong Kong-region Azure/Alibaba/Tencent cloud IPs), where analysts extract each app's domains, IPs, and distinctive URL paths (e.g. '/tigase/getLastChatList', '/user/getUserMoney') and log 'system disposition: newly added blocking action' for every one; matching raw keyword-object exports using the identical URL-path style confirm these hand-extracted paths are loaded directly as live filter-list entries in production.
The AppSketch/MAAT signature system contains a systematically dated, patch-versioned catalog of FQDN-based detection signatures for dozens of individually named commercial VPN apps (e.g. V2VPN, V2Netvpn, Turbo VPN, LetsVPN, AdGuard VPN, Avira Phantom VPN, TouchVPN, FinchVPN, Opera VPN, Ultrasurf VPN, GoFly VPN), each modeled as an 'app' object in category 'networking' / subcategory 'tunnels' whose default deny_action drops the flow while sending both an ICMP-unreachable and a TCP RST to the client. At least 35 such distinct VPN-app signature objects appear in this batch alone, dated July-November 2024, with repeated 'Patch0N' revisions to the same app as its domains rotate.