An internal presentation ("中间人攻击技术及应用", Aug 2024) documents live MITM proof-of-concept testing using mitmproxy in both forward-proxy (client-trusted root CA + HTTPS certificate replacement, relayed through an Alibaba Cloud VPS and the circumvention tool Clash) and transparent-proxy (SSL-stripping/HTTPS-downgrade via a dual-NIC inline box) configurations, both demonstrated live against scholar.google.com/google.com with conditional keyword-based blocking of decrypted search queries.
在用户PC终端安装Mitmproxy根证书，使用Chrome浏览器访问https://scholar.google.com，可以进行https访问，说明使用信任根证书进行中间人代理。在其页面搜索毒品等违禁词，会出现无法访问页面，而搜索正常内容，可以正常访问，同时访问https://www.google.com,出现无法访问页面，说明进行了合规性过滤。
Defense implications
- Confirms working internal MITM tooling and playbooks (both trusted-root-CA and transparent SSL-stripping variants) for decrypt-then-keyword-filter interception, tested specifically against Google Scholar/Google search -- traffic resembling ordinary browser HTTPS to search-style endpoints should assume query content itself, not just SNI/domain, can be inspected post-decryption if a client is ever induced to trust a foreign root CA or gets downgraded to HTTP.
Related findings
A MESA Lab monthly report describes a 'web-proxy' engineering task that modified the open-source Ultraviolet web-proxy project to add keyword- and specific-URL-blocking, alongside deployment work (certificate issuance, redirect handling) and a document listing which sites the proxy is permitted to relay; the purpose (internal filtered access vs. a broader capability) is not stated in this excerpt.
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.
Geedge fingerprinted several V2Ray-based VPN apps by their fixed API/bootstrap domains rather than protocol characteristics — blocking "V2 Pro" via pro.mucacherry.org, "V2 VPN" via v2.mucacherry.org, and "V2Net VPN" via api.v2net.live plus 5 rotating free-node domains (free1-5.v2n3t2.online / v2n3t.online) the app uses to fetch node lists.
PanGu defines explicit business/service IDs for webpage keyword blocking (0x28) and keyword monitoring (0x98), with a dedicated NTC_KEYWORDS_URL_LOG log table storing the URLs recovered from keyword-hit traffic -- confirming keyword-based content filtering is a named, first-class TSG business rule with its own audit log, separate from domain/IP/SNI blocking.
Geedge runs an ongoing, largely manual weekly signature-extraction program against commercial VPN apps (LetsVPN, Betternet, VPNLITE, and a ~80-app batch), combining server-IP lists, FQDN patterns, and payload/SNI/Host/User-Agent signatures, tested for blocking efficacy and false-positive rate before rollout. VPNLITE was fingerprinted via TCP direct-connect on ports 18000/3320/8099 plus TLS to randomized .xyz/.info subdomains on Cloudflare ranges (104.21.0.0/16, 172.67.0.0/16).
relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.