Tiangou Secure Gateway (TSG)

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 TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').

Raw structured DNS event logs (dated 2021-08-23) captured from what appears to be a GFW-adjacent DNS monitoring/injection pipeline use a schema purpose-built for DNS response forgery ('CHEAT_TYPE', 'CHEAT_RCODE', 'CHEAT_STRATEGY', 'CHEAT_RR', 'INJECTED_PKT_FILE' fields) alongside per-query geolocation; sampled records show lookups for facebook.com and tiktokv.com originating from residential China Telecom/Unicom/Mobile subscriber IPs in Guangdong, Zhejiang, Anhui and other provinces, resolving against both domestic and foreign (8.8.8.8, OpenDNS) resolvers.

A 2023 MESA Lab monthly report describes the 'TF' project's active-defense work: test cases for serial ('串联') HTTP hijack/tamper and parallel ('并联') DNS race-injection ('DNS抢答'), performance tuning that scaled active-defense capacity from 3 to 5 units, converting two existing TSG boxes to active-defense mode, and rewriting the active-defense flow-control logic to no longer depend on sapp.

The T1/NTC (text-content DPI) node's wired-config manifest (main.conf, dated 2019-01-30) sets REMOTE_DIR=ASTANA/KAZAKHTELECOM/, directly naming Kazakhtelecom — Kazakhstan's dominant state-linked telecom operator — as the carrier context for this K18 deployment. The NTC_MAAT module's EFFECTIVE_FLAG further scopes rules to {location: Astana, isp: Tanstelecom}, naming a second Kazakhstani ISP (Transtelecom) tied to the same deployment.

An 'ADC Hardware Installation and Configuration Guide' (v21.11) describes a modular chassis (Switch Sled, CPU Sled) matching taxonomy's Pakistan/WMS-UTR 'ADC hardware' reference, confirming ADC is a distinct deployed hardware line -- not just a site nickname -- with its own installation documentation separate from the TSG-X/TSG-7400 line.

An internal ops runbook for setting up Nginx basic-auth on a deployed service gives the literal filesystem path /home/ceiec/bifang/nginx/htpasswd (and the corresponding docker volume mapping), directly tying the 'Bifang' policy-management API identified in the TSG OAM CLI guide to infrastructure branded/organized under 'ceiec' — consistent with this corpus's identification of CEIEC (China National Electronics Import & Export Corp) as an export intermediary for Geedge/TSG deployments.

A 'Druid Historical Data Migration' runbook directs uploading a migration folder to /data/ceiec/ on HDFS server 10.4.61.78, then migrating Apache Druid tables named 'application_protocol_stat' and 'security_rule_hits' from old to new tables — further corroborating a CEIEC-branded analytics/HDFS deployment backing TSG's DPI rule-hit and per-app-protocol statistics pipeline (the same kind of data that feeds the traffic-overview and carrier-analysis reports found elsewhere in this batch).

A recurring Chinese-language daily '出入口整体流量监测报告' (Entry/Exit Overall Traffic Monitoring Report), sampled here from June 2022 through Feb 2024, tracks national-gateway-scale traffic (peak 1.1 Tbps, 5.62 PB/day in one instance; top apps by volume include Bytedance, Tencent, Kuaishou, Alibaba, Baidu). The 2024-01-16 instance explicitly discloses that of 34 total ingress/egress links (2.68 Tbps aggregate capacity), the monitoring system actually taps only 2 links (200 Gbps) — 7.46% of total link capacity — meaning the reported traffic figures reflect partial-link sampling, not full-link coverage.

A recurring weekly 'Tiangou Secure Gateway — Server IP and Location of Overview' report, spanning Jan 2023 through Jan 2024 in this batch alone, tracks per-app top server IPs/geolocations/bytes for named foreign platforms (Instagram, Netflix, Reddit, Skype, Pinterest, Quora, Line, Likee, Medium, Pandora). Top consumer-side IP rows consistently resolve to Kazakhstan cities (Almaty, Pavlodar, Nur-Sultan/Astana), matching the K18 site codename. Processed-row counts grow roughly 10x over the year (889B rows/week in Jan 2023 to 9.4T rows/week in Jan 2024), and one instance reports Total Bytes Transferred of 14.66 PB and an average of 218.34 Gbps for a single week.

An internal runbook for 'Sentinel EMS' (a third-party HASP hardware/software licensing system) describes generating per-deployment license files (C2V request -> V2C license) and explicitly states the resulting V2C content is cut at the <hasp_info> node and placed into a 'bifang-api service license file template' — i.e. TSG/Bifang feature entitlement per customer site is gated by a Sentinel HASP license file, not compiled in statically, meaning specific capabilities can be selectively enabled/disabled per contract.

In the same live TSG capture, rows show ssl_ech_flag=1 recorded for real observed TLS sessions (to connect-api.guardianapp.com) alongside a populated ssl_ja3_hash and an intact ssl_sni value, and the session was still denied by name-based rule Deny_Brave. This confirms the DPI engine parses and logs the TLS ClientHello ECH extension as a distinct per-session flag in production/test traffic, i.e. ECH usage is visible to the gateway even though SNI in this particular capture was not itself encrypted from the classifier's point of view.

An internal SQL query cookbook targets a ClickHouse-style database 'tsg_galaxy_v3.session_record' with example top-10 breakdowns by common_l4_protocol, common_client_ip, common_server_ip, common_app_id, common_app_label, http_domain, and — notably — common_subscriber_id, plus filtered variants (e.g. by http_domain LIKE '%baidu.com%' or by a specific client IP) using a 1-in-10 sampling trick (cityHash64(common_recv_time) % 10 = 0). This names the internal analytics database and confirms subscriber-level session records are a standard, first-class query dimension, not an edge case.

The 'TSG OAM CLI User Guide' (v0.81) and companion 'TSG MIB Specification' describe the TSG-X hardware as four CPU sleds (MCN) plus one switch sled (MXN) running a CentOS-based command shell (tsg_policy, tsg_policy_object, tsg_record, tsg_show, tsg_diagnose), reachable via SSH, where policy queries/enable/disable and policy-object import/export are proxied through an internal 'Bifang API'. The tsg_show command has a dedicated --intercept flag documented as showing 'interceptable and blocked traffic information', confirming interception/blocking status is a first-class, directly queryable operational state on the device.

Raw TSG session_record CSV exports (header row `recv_time,log_id,decoded_as,session_id,...`) show a ~224-column per-session logging schema that goes far beyond blocking metadata: subscriber_id/imei/imsi/apn/phone_number identity fields, full DNS query/response, HTTP with a cleartext mail_password field for mail protocols, TLS JA3/JA3S hashes, cert issuer/subject, ESNI/ECH flags, SIP/RTP VoIP metadata, SSH hassh fingerprints, RDP client details, and cryptocurrency-mining (stratum) protocol detection. This is a general-purpose deep-inspection/logging pipeline, not a narrow blocklist filter.

Live TSG session logs from an internal test/QA gateway (device_id 9800165603191146 / 21426003, data_center label XXG-TSG-BJ) show real sessions from named commercial VPN apps — AlohaBrowserLite, BeePassVPN, BravePrivateVPN (WireGuard), Proton VPN, Turbo VPN, CyberGhost, BetternetVPN, SuperUnlimitedVPN, TrustzoneVPN and VPNHero — each matched to a dedicated per-app security rule (e.g. Deny_Brave, Deny_BeePassvpn, deny_Super Unlimited VPN) and given security_action=Deny. One row's app_transition field records a layered classification chain 'Psiphon Provider' -> ... -> 'BravePrivateVPN' for a single session, indicating the engine attempts nested/tunnel-in-tunnel protocol identification, not just single-label app ID.

A recurring weekly '[Xinjiang Unicom/Xinjiang Mobile] Traffic Analysis Report' (新疆联通/移动流量分析报告), produced by a 'Carrier Front-End Analysis Team' (运营商前端分析团队), spans Feb-Jul 2023 in this batch. It reports each carrier's total/access bandwidth (Xinjiang Unicom: 1.88 Tbps total, 880 Gbps access; Xinjiang Mobile: 4.4 Tbps total, 1 Tbps access) and per-app server-IP/location/traffic breakdowns for 31 named foreign platforms including Telegram, WhatsApp, Twitter, Facebook, Discord, Snapchat, Gmail and YouTube, alongside domestic-app sections — direct evidence of an ongoing, carrier-integrated domestic monitoring program for China's Xinjiang region.

An internal TSG 3.0 upgrade runbook specifies deployment directory conventions literally namespaced to "ceiec" (/data/ceiec, /home/ceiec, and a service-backup path /data/ceiec/update/0908/组件名称), alongside TSG-generic paths (/home/tsg3.0-volumes/, docker-compose services renamed from /home/test to /home/galaxy, a Nacos service-config registry, and a note that version 21.09 needs Kafka authentication integrated) — corroborating CEIEC as an actual deployment-branding identifier in TSG's own ops tooling, not just a contracting-paperwork name.

A Sentinel HASP software-license XML file names "CEIEC" as the licensed organization (type "Evaluation"), with the license's embedded HASP feature blob (v2c field) containing readable product-SKU strings "TSG-Web-Sketch-DB- Subscription", "TSG-App-Sketch-DB-Subscription", "TSG-App-Sketch-Engine", "TSG-App-Sketch", "TSG-WANNAT", "TSG-Proxy", and "TSG-CM" — direct primary- source evidence of a CEIEC-licensed TSG deployment naming the specific licensed product modules. This does not by itself identify which end customer/country CEIEC was reselling to for this particular license.

A custom Prometheus-backed infrastructure-monitoring platform (MySQL schema dumped from source "nz-prometheus", schema "nz-temp", dated 2020-10-16) has its sys_area reference table seeded with exactly the five Kazakhstan cities named in the K18 site-codename entry — Aktau, Almaty, Nur-Sultan (the pre-2022 name for Astana), Karaganda, and Zhezkazgan — and a companion live alert-message dump (dated Nov 2020) shows real "endpoint down" P2 alerts tagged Data center: Nur-Sultan / Aktau, Project: ADC, across modules named MXN-NODE and MCN0-3-NODE/SRV, pushing the earliest confirmed evidence of the K18 Kazakhstan deployment back to at least October-November 2020.

The TSG System Installation Manual (dated 2021-05-28) documents a three-component architecture — ADC (distributed cluster, policy enforcement/traffic processing), OLAP (log analytics, standalone or cluster mode), and CM ("Central Management", the policy UI) — with policy pushed from CM to ADC devices and ADC-generated logs aggregated via Kafka for OLAP analysis. Baseline per-node hardware requirements are 24+ CPU cores, 32GB+ RAM, 2TB disk, 1Gbps NIC, on CentOS 7.4.

The same 224-column TSG per-session log schema carries a full TLS- interception field set — proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, sc_rsp_raw and sc_rsp_decrypted (raw vs. decrypted server response content) — plus ssl_esni_flag and ssl_ech_flag (explicit ECH/ESNI-usage flags), ssl_ja3_hash/ssl_ja3s_hash, and ssh_hassh (SSH client fingerprinting), confirming certstore-style MITM interception, ECH/ESNI detection, and TLS/SSH fingerprinting are all first-class fields logged on every session, not experimental add-ons.

TSG's core per-session log schema (a 224-column CSV export, four near- identical copies in this batch) includes subscriber-identity fields — subscriber_id, imei, imsi, apn, and phone_number — directly alongside the standard 5-tuple/app-classification fields in the *same* record, meaning every inspected session is natively correlated to a subscriber identity by design, not as a bolted-on side system.

TSG automatically generates recurring weekly "SNI Report of Overseas APP" and companion "Server IP and Location of Overseas APP" reports at what is almost certainly a China-national (not export-customer) scale — single weekly runs process from ~5.7 trillion to over 135 billion rows and up to ~775TB/week — breaking down QUIC.SNI/SSL.SNI/HTTP.Host traffic per named blocked-in-China platform (YouTube, Facebook, Google, Twitter, Instagram, Telegram, WhatsApp, Netflix, BBC, Viber, Line, Snapchat, Gmail, HBO, and more), down to individual CDN edge hostnames (e.g. specific scontent-*.fbcdn.net and rr*---sn-*.googlevideo.com nodes ranked by bytes). The report series recurs weekly from at least Feb 2023 through Mar 2024.

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.).

The Xinjiang Mobile carrier traffic report (2023-05-15) states in its own QUIC-domain-ranking section that Xinjiang's intra-provincial traffic has begun carrying QUIC/HTTP3 (UDP-based) traffic that poses "a huge challenge" to the traditional parallel/out-of-band ("并联") traffic-access blocking method, and that effectively gatekeeping ("GK") UDP/QUIC traffic requires switching to an inline/in-path ("串联") blocking architecture — a direct internal admission that (as of mid-2023, in this province) the standard mirror-tap deployment could not reliably block QUIC.

A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.

A thesis-project assignment for hidden-service (VPN/Proxy/Tor) identification via heterogeneous graph neural networks on flow logs sources its one day of training data from a database explicitly named 'tsg_galaxy_p19' — tying the internal TSG naming convention to the taxonomy's P19/WMS-UTR Pakistan site codename — accessed over an internal 'Information Harbor' (信息港) VPN, with ground-truth hidden-service IP labels supplied by the commercial IP-intelligence service spur.us.

A MySQL dump of a TSG admin-panel dictionary table (sys_dict) contains an 804-row "出入口应用程序列表" (Ingress/Egress Application List) enumerating classifiable applications by internal code name, including explicitly named VPN/circumvention tools wireguard, hotspot_shield, windscribe, expressvpn, browsec_vpn, skyvpn, barracuda_vpn, anonytun_vpn, and others -- i.e. a master admin-facing catalog of apps (including VPN protocols/brands) available as classification/policy targets across the platform.

TSG's app-traffic classification relies on an updatable "App Sketch DB" component (uploaded as a versioned file to each deployment). A version bump at the Xinjiang Unicom province-exit + IDC site increased identified application-traffic share from 23% to 68% of total traffic within days, with ByteDance-attributed traffic alone rising from ~100TB/day to ~500TB/day identified, illustrating both the scale of traffic under classification and that classification itself is a frequently-updated, centrally-distributed database rather than a static build-time artifact.

AppSketch Works' asw-controller service (net.geedge.asw, 271 commits) implements a full automated signature-extraction pipeline: it tracks app source/releases via git (BranchController, MergeRequestController, ApplicationReleaseEntity), provisions remote/virtual Android 'Environment' instances with noVNC and terminal WebSocket access so a human operator can drive the app, captures the resulting traffic to pcap (PcapController, PcapParserThread), runs Playbook-scripted analysis integrated with Zeek and WebShark (ZeekClient, WebSharkClient), and produces versioned per-app DPI signatures (SignatureExtract.java, SignatureUtil.java -> ApplicationSignatureEntity).

At a Pakistan site (P19/MSH), Geedge identified that TCP RST-injection for a Deny action fails on asymmetric ('unidirectional') flows because the synthetic RST packet lacks GRE callid/routing context only present when both directions transit the same node. Two fixes are in progress: a dedicated third-layer packet-injection route, or a cluster-wide coordination mechanism ('SwarmKV') that syncs which policy a session matched across nodes so each node can independently inject its own side's interference packet.

Raw TSG session-log CSV exports from device group XXG-TSG-BJ (a Beijing test/demo box, security rule list labeled "Demo 0625") show live enforcement: sessions to VPN client backends are matched by app-transition signatures such as BeePassVPN_Patch01/02/04 and BetternetVPN_Patch08_20240929, tagged with security_rule_list "Deny_BeePassvpn" and security_action "Deny" — i.e. TSG identifies specific patched VPN client app builds and actively drops the session, not just logs it.

The 'Tsg_Galaxy_v3.0' deployment bundle ships built Flume interceptor plugins (FlumeRadiusOnOffInterceptor, FlumeSubscriberInterceptor, FlumeDynamicInterceptor) as operational binary artifacts alongside a full set of per-protocol traffic-content collectors -- DNS/FTP-doc/HTTP-doc/Mail/SSL/Telnet -- that feed ClickHouse via Flume and gohangout, confirming these RADIUS/subscriber-correlation interceptors are deployed in production as part of TSG Galaxy v3.0's full-protocol content-capture pipeline.

TSG/CM ships with pre-built, first-class 'Learning Object' entries specifically for Freegate (Object ID 18) and Psiphon3 (Object ID 19), plus a generic 'Top Server IP' object (ID 20) -- default product features, not customer-commissioned custom signatures. The Psiphon3 object auto-learns and dynamically updates a live blocklist that reached roughly 70,000 IPs at one deployment before a database issue temporarily dropped it to ~50,000.

Ethiopia (E21) customer specifically tested Melon VPN and Ultrasurf against TSG; Ultrasurf's frequently-rotating IPs required an updated signature (successfully blocked after update), while Melon VPN's connection succeeded but was non-functional for other reasons (not attributed to TSG blocking).

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.

Confirms the full licensed TSG component roster deployed at Ethiopia (E21): Firewall, Digital Observer, Email Retention, Statistics Policy, Proxy, Session Record, GTP Security, AppSketch, AppSketch Engine, AppSketch DB, WebSketch, WebSketch DB. Several license terms were extended to expire 2091-12-31, indicating a multi-decade commercial commitment.

A companion recurring report family, "Tiangou Secure Gateway — Server IP and Location of Overseas APP", automatically compiles TOP10/TOP50 server-IP-and-geolocation tables per major Western platform (BBC, Discord, Facebook, Gmail, Google, Hulu, ESPN, Messenger, etc.), i.e. an automated pipeline for building IP-block target lists against specific foreign services from observed traffic, generated on a similar recurring cadence.

An internal TSG troubleshooting runbook ("HTTPS证书替换策略无效果") documents the certstore MITM-certificate service actively serving/validating forged certificates keyed by SNI, walking an operator through checking certstore logs for specific real-world domains including Google's update service (update.googleapis.com) and Nvidia's GFE service (services.gfe.nvidia.com), and cross-checking keyring config live via maat_redis_tool.

certstore's own commit history documents its transparent-TLS-MITM mechanics directly: it writes the client's observed SNI into the SAN field of the leaf certificate it mints on the fly, supports ECC issuance (secp192r1/secp256r1) for those forged certs, and reads its Trusted/Untrusted decryption-keyring configuration from MAAT's DECRYPTION_KEYRING table -- confirming the interception pipeline end-to-end: client SNI in, matching forged certificate out, gated by MAAT-synced keyring policy.

tsg/cli-deploy is an Ansible deployment repo for "tsg-cli" host monitoring (tsg-monitor service, rsyslog forwarding) targeting named production hosts, including hosts.astana and astana_ADC_IPlist_V1.xlsx, with a commit explicitly adding "astana部署环境IP" (Astana deployment-environment IPs) and a later branch for reading ADC hardware chassis IDs into the device serial-number scheme — concrete deployment evidence for the K18 (Kazakhstan, Astana) site.

A production ClickHouse query template for a TSG-family "connection_record_log" table reveals the deployed DPI collection schema: every base session record carries a subscriber-ID field alongside SSL SNI, HTTP domain/URL, client/server ASN, device ID, and internal/external/sled IP -- with subscriber ID used as the primary session identifier (falling back to client IP only when absent).

The same GEEDGE employee handbook dates the launch of 网络叙事者 (CyberNarrator) to April 2021, and separately states the company's products serve 18 data centers and carriers worldwide processing over 20 Tbps of traffic — the first primary-source confirmation of CyberNarrator's launch date and a company-stated global deployment-scale figure.

A weekly "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report), authored by the "运营商前端分析团队" (Carrier Front-End Analysis Team), directly ties the SNI/Server-IP overseas- APP report format to the China Mobile Xinjiang branch specifically, and states the pipeline identifies 126 distinct application-layer protocols including multi-layer tunnel nesting such as STUN.DTLS and STUN.RTP.RTCP.DTLS — i.e. it decomposes and classifies nested WebRTC-style transport stacks, not just top-level TLS/QUIC.

Side-by-side internal performance comparison across Xinjiang (China Mobile carrier deployment, hostname cmcc-xj-server1-sapp-244), Fujian (domestic), and Ethiopia (E21) explicitly references the same 'app_sketch_maat' diagnostic log format at all three sites, confirming the identical AppSketch app-fingerprinting stack is used for domestic Xinjiang surveillance and for the exported Ethiopia deployment.

Direct dated evidence (July 2023) that the Ethiopia (E21) customer actively toggles application-level blocking as a live policy lever: lifting the block on YouTube plus four other apps caused a documented traffic surge and device alerts at the BOL-IGW site.

Real TSG session logs from device "XXG-TSG-BJ" (Beijing) show live production blocking of named commercial VPN apps by app-signature: 206 of 213 sampled sessions carry security_action "deny_quarkVPN01" against app field "quarkVPN0622.quarkVPN0619" (destination IPs in Germany, Russia, US, Australia, Bangladesh); a second log from the same device shows security_action "Deny_BeePassvpn" against app-identified BeePass VPN traffic.

A raw TSG session-log export shows the full production log schema: per-flow fields include subscriber_id, imei, imsi, phone_number and apn alongside ssl_ja3_hash/ja3s_hash, ssl_esni_flag, ssl_ech_flag, quic_sni, dtls_ja3_fingerprint, and proxy_pinning_status/proxy_intercept_status/ proxy_cert_verify fields for the MITM proxy path. This confirms TSG's session logging natively joins network-flow identity to subscriber identity and captures TLS fingerprint/ESNI-ECH state and MITM-interception outcome in the same record.

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's TLS ClientHello parser (MESA_Platform/ssl GitLab component) explicitly parses the ec_point_format extension from ClientHello, confirming deep TLS extension-level fingerprinting beyond simple SNI extraction.

Recurring automated "Tiangou Secure Gateway — SNI Report of Overseas APP" documents (weekly, multiple recurrences across 2023-2024) enumerate every distinct QUIC.SNI/SSL.SNI/HTTP.Host value observed per major foreign platform (Netflix, WhatsApp, Telegram, Twitter, YouTube, Signal- adjacent services, etc.) with packet/byte counts, processing runs at up to ~6.3 trillion rows per report. QUIC SNI is tracked as a distinct column from TLS SNI, showing the pipeline separately fingerprints HTTP/3 traffic.

The galaxy/tsg_olap/dll-multipoint-aggregation repo defines a Flume-based multi-site log-aggregation pipeline with five parallel categories -- "active_defence", "connection" (call-detail/通联日志), "proxy", "security", and "radius" -- the last explicitly ingesting RADIUS data, corroborating that the CyberNarrator subscriber-correlation capability's RADIUS feed sits inside this broader TSG OLAP log-aggregation architecture rather than as a standalone system.

A 2020 MESA Lab monthly report describes building an encrypted-DNS gateway device and a self-hosted DoH server that was wired directly into a live "TSG platform WAN net interface", alongside a passive DoH-service-discovery pipeline that found 39 new DoH-serving domains in a single day of backbone ("科技网") traffic; a related note documents actively probing known DoH-serving IPs' upstream resolvers via a proxy network across 196 countries to check which still function.

The tsg/dp_telemetry_app repo is a data-plane telemetry agent that loads MAAT-sourced rules (maat.c/maat.h, etc/dp_telemetry_rules.json) including BPF filter expressions, and on a match exports full packet captures (pcapng) plus MessagePack-encoded session telemetry over Kafka -- i.e. a MAAT policy match can trigger targeted, per-session raw packet capture, not just a pass/block decision.

An internal "DPI Benchmark" methodology document names the three production components underlying TSG's DPI stack and proposes benchmarking each against open-source equivalents: Marsio (DPDK-based packet I/O) for receive/transmit, Sapp ("网络安全开发平台", a high-speed traffic-processing platform) for protocol parsing and flow-table management, and Maat (Hyperscan-class signature engine with Redis-based multi-machine config sync) for pattern scanning.

A certificate-issuance repo (luwenpeng/certificate, commit "TSG-8365 为TSG/Nezha界面的服务端签发证书" = "issue server-side certs for the TSG/Nezha interface") contains config, CSR, key, and crt files explicitly named "-for-e21" (ca-root-for-e21.conf, tsg-entity-for-e21.crt, nezha-entity-for-e21.key), confirming an internally-issued PKI hierarchy used for encrypted communication between TSG and its "Nezha" management-web-interface components at a site tagged E21 (Ethiopia).

The "ADC Hardware Installation and Configuration Guide" (v21.10) documents Geedge's own carrier-grade appliance: model ADC-L404 with hot-swappable fan/PSU/CPU-sled/switch-sled chassis modules, installed via ONIE and running TSG-OS, managed through an MCN0/MCN1-3 control-node cluster architecture. This is the physical hardware product underlying TSG deployments, including the "ADC hardware" referenced in the WMS-UTR/P19 Pakistan site codename notes.

The same ADC/TSG-OS installation guide's built-in factory acceptance test ("tsg-diagnose-oneshot") enumerates the product's certified MITM/content-manipulation actions as standard, tested features of every deployment: SSL interception with expired/self-signed/untrusted-root cert handling, and both SSL and HTTP proxy policies supporting redirect, block, replace, hijack, and insert actions, plus DNS request handling with drop and A/AAAA redirect (including TTL-range variants). This is vendor self-documentation, not inferred behavior.

A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.

A TSG "device_group" tag configuration enumerates 30+ Ethiopian deployment sites far beyond the previously-known E21 site list, including many new city/PE (provider-edge) codes (Ambo, Nekemte, Yeka, Arada, Jijiga, Dessie, Mekele, Debre Markos, Gondar, Hawasa, Sodo, Jimma, plus GGSN nodes at Microwave/Kirkos/Nefas Silk) alongside the already-documented sites (Bole, Shashamane, Bahir Dar, Dire Dawa, Legehar, Old Airport, Nefas Silk). Two entries are explicitly labeled "Safaricom Kaliti IGW" (KLT-IGW) and "Safaricom STEP HQ IGW" (STQ-IGW), directly confirming the Safaricom Ethiopia customer identity for the E21 deployment from primary device configuration rather than inference.

A TSG device-group tag list for the Ethiopia deployment enumerates far more IGW/PE sites than previously catalogued, including Bole-IGW, Shashamane-IGW, Microwave-IGW, and Bahir Dar-IGW gateway nodes plus PE sites at Legehar, Old Airport, Nefas Silk, Ambo, Dire Dawa, Nekemte, Kirkos, Yeka, Arada, Jijiga, Dessie, Mekele, Debre Markos, Gondar, Hawasa, and Sodo, and explicitly labels two nodes 'Safaricom Kaliti IGW' and 'Safaricom STEP HQ IGW', directly tying the deployment to carrier Safaricom Ethiopia; a companion site runbook for a link migration at the Bahir Dar-IGW node shows live CLI admin sessions against hardware identified as '9000-SMBIO-P01R01-1'.

Production network-topology docs for the Astana and Almaty (Kazakhstan / K18) sites show a live decrypted-traffic forwarding pipeline between an ADC front-end and an ASEM front-end over a direct fiber link, plus a distinct 'IP Spoofing' business function and dedicated static/dynamic proxy interception business lines, and a certificate-management endpoint (port 9991) — confirming operational TLS interception (MITM) infrastructure in production, not just lab capability, at both K18 sites.

A Flink-based "FileChunkCombiner" pipeline in the TSG OLAP stack (galaxy/tsg_olap/file-chunk-combiner) reassembles file chunks parsed from proxy and session metadata (ParseProxyFileMetaFlatMapFunction, ParseSessionFileMetaFlatMapFunction) captured off monitored traffic, then persists whole reconstructed files to HBase and object storage (an "HosSink" and an OSS sink), confirming TSG performs full file-content extraction and durable storage from intercepted sessions, not just flow/metadata logging.

An "IDC阿里服务质量监测报告" (IDC-Alibaba service-quality monitoring report, dated 2022-09-28) generated by the same reporting pipeline lists "Freegate" — a well-known anti-censorship circumvention tool — as a distinctly tracked top-application bucket at 9.05%-31.85% of measured traffic share across different report dates, alongside ordinary entries like Sina, Tencent, and alicdn.com, showing Freegate usage is monitored as a named, quantified category at the IDC/backbone-link level, not just at edge appliances.

Multiple domestic IDC traffic-monitoring reports rank "Freegate" (a well-known GFW-circumvention tool) as a distinct, named top-10 application by traffic volume alongside Bytedance/Tencent/Alibaba/Baidu, with peak 18.92 Gbps and average 5.9 Gbps in one 2022-07-07 report -- confirming Freegate has its own dedicated app-ID classifier tracked at carrier-comparable traffic scale, not merely a low-volume/rare signature.

A domestic Fujian-province deployment was asked by the customer to parse and store call and SMS signaling data (via GTP-C) into the site's ClickHouse-backed OLAP store, extending the existing GTP-C signaling table structure. This domestic (mainland China) request is distinct from the Pakistan RADIUS-correlation deployment, indicating the underlying signaling-ingestion capability is deployed and requested across more than one customer context.

TSG's DNS enforcement plugin (tango/fw_dns_plug, packaged with tsg_master) implements DNS response spoofing as its DENY action, sending forged/deceptive DNS answers, with differentiated behavior for mirror (passive-tap) vs inline deployments: mirror mode only spoofs a response to the request, while inline mode drops the real answer and injects a forged one.

A Postman API collection titled '银河api' (Galaxy API) documents production query endpoints against the tsg_galaxy analytics backend, including dedicated 'radius日志标准查询' / 'raduis日志clickhouse查询' (RADIUS log queries) and 'Traffic Top Intercept Policies By Hits/Bandwidth' endpoints -- showing RADIUS-based subscriber correlation and interception-policy analytics are standard, generally-available query features of TSG's management API rather than a one-off built solely for the Pakistan deployment.

A log-stream double-write Flink program (galaxy/tsg_olap/log-stream-doublewrite) was purpose-built and repeatedly updated for "P19" -- the internal codename for the Pakistan (WMS-UTR) TSG deployment -- replicating TSG session-record logs to a secondary sink, evidencing dedicated engineering investment in the Pakistan customer's log pipeline distinct from the base product.

The same 'tsg_galaxy_v3.session_record' schema carries explicit TLS-interception status fields per session -- proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, proxy_client_side_version, proxy_server_side_version -- confirming that certificate-pinning detection and MITM intercept/bypass outcomes (matching the 'certstore' product's Trusted/Untrusted/Dynamic-Bypass model) are logged at per-session analytics granularity across the whole platform, not just flagged transiently at the gateway.

A Kazakhstan-specific push service (galaxy/K18/galaxy-push-service) tracks per-geographic-area protocol blocking (AreaBlockProtocol, BlockingArea, EventsBlock domain classes) and pushes Top-N blocking analytics on a schedule, indicating K18's blocking is administered and reported at sub-national (area) granularity rather than applied uniformly nationwide.

The Galaxy query-gateway platform's (galaxy/platform/galaxy-qgw-service) statistics/policy-metrics schema had a JA4 fingerprint field added (ticket TSG-23812), confirming TSG's analytics/policy layer captures JA4 -- a modern client TLS/QUIC fingerprint -- as a first-class, queryable field platform-wide, beyond legacy JA3.

Galaxy's platform-wide ClickHouse schema includes subscriber_id, RADIUS on/off, and RADIUS record-log fields as core session-log attributes (not a site-specific add-on), and a companion ArangoDB "knowledge" graph module (SubscriberIdProviderImpl / SubscriberIdPath) resolves subscriber-identity paths, while the platform's schema/API layer separately added KMS/Vault-backed decryption support for fields marked "encrypted, sensitive" -- showing subscriber-identity correlation and its at-rest encryption handling are built into the core multi-tenant analytics platform rather than bolted on per deployment.

TSG's central ClickHouse analytics schema ('tsg_galaxy_v3', deployed on cluster 'ck_cluster') defines a 'session_record' table where every logged session carries subscriber_id, imei, imsi, phone_number, and apn fields alongside client/server geolocation and ASN -- showing that per-session subscriber-identity correlation is a built-in, standard field of TSG's core traffic-log schema (used for ordinary session_record, not a bespoke table), not an add-on limited to the already-documented Pakistan CyberNarrator deployment.

The same TSG QA framework exercises live HTTP/HTTPS content-manipulation proxy actions -- redirect, replace, hijack, insert, and edit_element -- including a documented test case that adds a rule to replace "china"-related content in live Google search results, giving a concrete real-world target example for the platform's live content-injection/rewriting capability.

TSG's QA automation framework (dongxiaoyan/gap_tsg_api) documents the policy engine's app-blocking action taxonomy (default/Drop/RateLimit/Tamper, with "rst" later renamed "reset") and records that, as of a 2022 test-suite update, the circumvention tools Psiphon ("赛风") and Freegate ("自由门") were only supported under a RateLimit (throttle) deny action rather than a hard Drop, while dozens of other apps (WeChat, Telegram, WhatsApp, Tor, WireGuard, TachyonVPN, Instagram, Facebook, etc.) had named test coverage across Allow/Deny/Monitor actions.

The gap_tsg_api QA repo includes commits submitting an Android install package and Android/iOS test scripts for an app labeled "E21VPN" -- E21 being the established internal site codename for the Ethiopia TSG deployment -- indicating Ethiopia-specific VPN-app test targets were built into the same automated policy-validation pipeline used for TSG's general app-blocking QA (which in the same commit already covered ExpressVPN, HotspotShield, NordVPN, Surfshark, ProtonVPN, iTopVPN).

TSG's blocking-policy validation API treats subscriber-identity fields (IMSI, phone number, APN, subscriber/sub ID) as first-class policy match/verification conditions rather than downstream-analytics-only fields, and the same QA suite includes test coverage for carrier-network tunneling and mobile-core protocols (GRE, GTP-C, SIP), indicating the DPI/policy engine is deployed inline within mobile-carrier network cores, not just fixed-line ISP links.

dongxiaoyan/gap_tsg_ui is a Robot-Framework QA automation suite for the TSG admin UI that validates a "Hijack Files" feature using uploaded test payloads of type .apk, .exe, .gif, .html, .jpeg, .png and .svg — confirming the live product can serve/substitute arbitrary file types, including Android APKs and Windows executables, as part of an intercepted-connection hijack action — alongside test cases for GTP-C records (mobile-core signaling) and first-class "subscriber_ids" and "mobile_identites" policy objects.

A static/dependency-scan report of 'source-code.zip' shows TSG-UI's actual source tree lives under path 'Bifang/TSG-UI', with the Vue frontend and Spring backend both referencing the same 'tsg-bifang' MariaDB database and a Java package namespace 'com.nis.tsg.{controller,service,dao}' -- confirming 'Bifang' is TSG-UI's internal codename/product, built under an internal group's 'nis' Java package root distinct from the mesalab.* namespace used elsewhere in the MESA_Platform monorepo.

Two independent internal ops documents (a Bifang deployment manual and a Druid historical-data-migration runbook) hard-code the literal directory name 'ceiec' into TSG infrastructure paths (mariadb_home_path: /home/ceiec/mariadb; HDFS target /data/ceiec/) -- infrastructure-level corroboration, beyond the previously-documented export-channel notes, that CEIEC (China National Electronics Import & Export Corp) is embedded operationally in Geedge/MESA's own deployment tooling, not just named in contract paperwork.

A customer technical Q&A document specifies capacity requirements for a front-end traffic-shunting device sitting ahead of TSG: rule capacity above 10,000 masked/wildcard rules and above 1,000,000 exact-match rules, distributed across multiple X86 boards by rule-category (>16 categories), a rule-load speed above 100,000 rules/second, and sub-1ms rule-effective time, supporting IP/port-based drop, forward, mirror, and loopback actions on innermost addresses under nested MPLS/VLAN/IPv4-v6 encapsulation.

Geedge Networks' own new-hire onboarding deck (积至（海南）信息技术有限公司/Geedge Networks Ltd, Hainan) describes its product evolution 'from NGFW to next-generation security' as explicitly built on 'service chaining, active DPI, and man-in-the-middle' ('服务链、主动DPI、中间人') technologies, and states TSG competes 'in the international market' ('TSG在国际市场') -- company self-description confirming active DPI and MITM interception are core, deliberately marketed capabilities of the exported TSG product, not incidental features.

A recurring weekly 'Tiangou Secure Gateway / Server IP and Location of Overseas APP' report series tracks per-app server-IP geolocation for Instagram, Snapchat, Telegram, and Likee traffic, with entries repeatedly geolocated to Almaty, Pavlodar, and Nur-Sultan, Kazakhstan across late 2023-early 2024 -- consistent with (though not conclusive proof of on its own, given ambiguity over whether the geolocated IPs are CDN edge nodes or another artifact) an operating Kazakhstan TSG deployment continuously monitoring named social/messaging platforms.

An internal 'Data Platform Cluster Deployment Document' (数据平台集群部署文档) for the Galaxy component (Hadoop/HBase/Kafka/Storm/Zookeeper stack, package galaxy_component_install) explicitly names a 'KZ项目' (KZ Project) with its own pre-prepared regional config directory 'config-KZ' and a per-site config file 'component-NUR.conf', and instructs deployers to set the host timezone to Asia/Almaty -- direct internal confirmation of a Kazakhstan deployment matching the leak's K18 codename.

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.

The same Bifang deployment manual configures an 'api' service Kafka consumer on topic 'PXY-EXCH-INTERMEDIA-CERT' (consumer group 'tsg-consumer-cert') -- an explicit proxy/intermediate-certificate exchange channel, i.e. infrastructure-level evidence of how TLS-interception certificates are distributed/synced across the TSG cluster, consistent with the certstore product's described per-connection certificate-profile system.

The Bifang (TSG-UI) automated-deployment manual configures a dedicated 'subid' microservice that consumes a Kafka topic literally named 'RADIUS-RECORD-LOG' under consumer group 'mapping-subid-ip' -- an operational pipeline that ingests carrier RADIUS accounting records specifically to map subscriber identity to IP address in near-real-time -- concrete infrastructure-level detail for the subscriber-identity-correlation capability elsewhere associated with the CyberNarrator/vpn-thwarting component.

GEEDGE's own employee handbook gives a corporate timeline confirming: the company (中电积至(海南)信息技术有限公司 / Geedge Networks Ltd., founded July 2018 in Hainan) signed a strategic cooperation agreement with China National Electronics Import & Export Corp (中国电子进出口总公司 / CEIEC) in December 2018; obtained foreign-trade operating rights in May 2019; won an international competitive bid for its flagship TSG product against Canadian and Israeli competitors in June 2019; and completed phase-2/3 acceptance and delivery of an unnamed overseas project in January 2021.

Geedge Networks' 2023 new-hire onboarding deck gives a corporate timeline: TSG's first international market win (with a codename "Nezha" launching the same month) in September 2018, "网络叙事者" (CyberNarrator) launching November 2020, a "South Asia" country project landing August 2021 (overseas market expansion), and Geedge winning a bid as overall solution provider for an "East Africa" country project in May 2022 — timing and regions consistent with this corpus's existing Pakistan (WMS-UTR/P19) and Ethiopia (E21) site attributions, though the deck itself does not name the countries.

Geedge's internal company timeline dates the launch of 网络叙事者 (CyberNarrator) to November 2020, and states the company won a 'South Asian country' project in May 2021 (consistent with Pakistan/WMS-UTR) and, as overall solution provider, an 'East Africa country' project in May 2022 (consistent with Ethiopia/HDM) -- corroborating the export timeline for those two customers from the company's own materials rather than site-side evidence alone.

TSG's tsg_olap log-completion-schema Flink ETL job enriches raw session logs with subscriber-identifying context by joining flows against GTP-C (mobile-core control-plane signaling) and RADIUS accounting relations (GtpCRelation.java, RadiusRelation.java, backed by HBase), caching upstream/downstream GTP-C TEIDs specifically to complete one-directional flows with subscriber info, gated by a VSYS (multi-tenant) dimension.

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.

At a 'WMS-UTR' project deployment, Huawei DPI equipment operating alongside Geedge TSG at sites abbreviated TWA/PCAP/MSH independently applies a SIP-protocol Deny policy with IP allowlisting -- confirming TSG is deployed in a multi-vendor stack alongside Huawei DPI hardware at the same customer site, not as the sole detection layer.

Recurring named '出入口服务提供商监测报告' (egress/ingress service-provider monitoring reports) track link-level bandwidth and quality specifically for Alibaba, Bytedance, and Tencent as the domestic cloud/CDN 'egress service providers' whose cross-border links the platform monitors, at aggregate scales of roughly 1.2-2.7 Tbps across 22-34 links per provider, produced on a recurring (weekly-to-monthly) cadence from mid-2022 through at least early 2024.

Recurring "entry/exit overall traffic monitoring" (出入口整体流量监测报告) and per-provider "IDC quality monitoring" reports show China domestic gateway links running at up to 1.68 Tbps aggregate (24 links) with per-app (Bytedance, Tencent, Kuaishou, Alibaba, Baidu, Apple, Netease, Pinduoduo, Xiaomi, bilibili) traffic-share, TCP-handshake-latency, and packet-loss-rate breakdowns generated on a routine (near-daily/weekly) automated cadence — dozens of these reports recur across the corpus at different dates.

At least 33 additional recurring reports in this batch ("IDC阿里服务质量监测报告" / IDC Alibaba Service-Quality Monitoring Report, "IDC字节跳动服务质量监测报告" / IDC ByteDance Service-Quality Monitoring Report, and "IDC整体流量监测报告" / IDC Overall Traffic Monitoring Report, plus further variant-named "出入口" ingress/egress reports not individually cited here) span 2022-06 through 2024-02 and show monitoring deployed inline/mirrored at major domestic hyperscaler IDC interconnects — 10 to 22 links, 1 to 1.21 Tbps of aggregate bandwidth — for both Alibaba and ByteDance specifically, indicating the deployment footprint extends beyond telecom carriers (Xinjiang Mobile/Unicom) to major domestic cloud/CDN providers' peering links.

TSG's FQDN-based blocklist matching handles Internationalized Domain Names (Punycode/'xn--' prefixed non-ASCII domains), including automatic transcoding between Unicode and Punycode forms during policy sync between deployment sites -- confirmed via a bug where inconsistent validation of Unicode-vs-Punycode-entered domains broke policy sync between two Fujian sites.

TSG's "IP Learning" subsystem (wanglihui/ip-learning-graph, ArangoDB + Spark/Java) builds a Subscriber-IP-FQDN correlation graph (vertices Subscriber/Ip/Fqdn; relationships LocateSubscriber2Ip, LocateFqdn2Ip, VisitIp2Fqdn) fed by RADIUS session-activity data, and its commit history documents a dedicated "tsg kz" (Kazakhstan) build, directly tying this subscriber-identity correlation infrastructure to the K18 Kazakhstan deployment.

The internal project code 'K18' is confirmed to correspond to a Kazakhstan deployment: a customer fault report about ADC-relayed traffic to amazon.com/twitter.com references testing against 'Nur-Sultan' (Kazakhstan's capital name 2019-2022), corroborating the taxonomy assumption that Geedge's Kazakhstan customer relationship maps to the 'K'-prefixed project codes (K18, K24, etc.) seen elsewhere in this ticket set.

K18_NTCS_WEB/NTC (git.mesalab.cn) is the Java/Spring web console for Kazakhstan's (K18) National Traffic Control System. Its domain model implements per-protocol keyword filtering (App/ASN/DNS/FTP/Mail/P2P/SSL keyword configs), an HTTPS proxy-MITM object (PxyObjTrustedCaCert.java), and explicit content-manipulation templates for HTTPS Redirect and Replace (complex/IP-based) plus Hijack/Insert actions, all managed through this customer-facing K18 control panel.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

The tango/kni (Kernel Network Interface) repo shows TSG's SNI/TLS-ClientHello-based interception logic (kni_entry.cpp) receiving dedicated 2024 fixes for handling TLS ClientHello fragmented across multiple packets ("ssl chello frag") and a "chello first packet hit intercept policy" bug, on top of a long-standing (2020) "dynamic bypass" feature that replaced raw-ClientHello matching with JA3 TLS fingerprints, plus counters for SSL certificate-pinning detection.

A September 2023 IIE/CAS-authored test report for a "流量汇接处理子系统" (Traffic Aggregation Processing Subsystem, built on the sapp/durain_master_maat stack) confirms the system is architected to ingest and process a combined 27Gbps of raw traffic from two aggregation points simultaneously: a general "互联网汇聚口" (Internet aggregation port) and a "政务外网汇聚口" (Government Extranet aggregation port) — i.e. the same DPI processing pipeline documented for public-internet censorship is also deployed against China's internal government-network traffic.

TSG's AppSketch app-detection engine accepts custom Lua scripts for new signatures, feeding a client/server-role heuristic (lower port = server) for UDP policy matching; a custom OpenVPN-detection Lua script failed to trigger Deny specifically because that role-inference logic misclassified the flow's client/server sides.

Under the internal "M22" project (deployment site "YGN-MYTEL" confirms this is Myanmar, at the Mytel carrier), Geedge runs a continuous, individually-tracked signature-extraction pipeline against named commercial VPN apps (Super Unlimited VPN, NotVPN, Avira Phantom, Bitdefender VPN, Thunder VPN, Panda VPN, Mouse VPN, HaloVPN, GoFly VPN, Kiwi/Kuto/Greennet/Gulf Super/Hatunnel+ VPN, and a customer-provided list of 141 more): active probing of app refresh/connect behavior (including automated UI-driving scripts) extracts server IP/FQDN lists, separately for free vs. paid tiers and Android vs. iOS, which are then loaded as blocklist objects and validated against a false-positive ("CT"/穿透) test pass in a separate demo environment before deployment.

The tango/maat rule-matching engine (TSG's core signature/policy compiler behind libmaatframe.so, 1077 commits) has production test fixtures containing a rule category literally named NTC_DNS_FAKE_IP_CB ('DNS fake-IP callback'), alongside NTC_DNS_REGION and NTC_DNS_RES_STRATEGY rule types -- confirming DNS response injection/spoofing is a first-class, named rule category in MAAT's compiled rule format rather than an ad hoc side capability.

MAAT's compiled rule format includes explicit HTTP URL/request-body/response-body matching rule categories (NTC_HTTP_URL, NTC_HTTP_REQ_BODY, NTC_HTTP_RES_BODY) and email content/header matching categories (NTC_MAIL_BODY, NTC_MAIL_HDR), and its scanner backend supports two swappable regex engines -- a Hyperscan adapter (adapter_hs) and a 'Rulescan' adapter (adapter_rs) -- corroborating this corpus's existing understanding that MAAT falls back from Hyperscan to Rulescan above roughly 50K rules.

TSG ships a first-class 'Mail Monitoring and Blocking' feature (confirmed in the product's own v24.08 deployment test checklist alongside HTTP/HTTPS Blocking, DNS Redirection and Monitoring, HTTPS Decryption, and HTTPS Manipulation) that parses SMTP/POP3/IMAP sessions to extract sender/recipient addresses. Field analysis at a Pakistan site found STARTTLS opportunistic encryption accounts for roughly 25-32% of mail sessions and measurably defeats this extraction -- when STARTTLS occurs, the session is logged but mail-address fields are empty. Engineering's response is to add an explicit flag field rather than recover the addresses.

TSG's core Kafka log producer (galaxy/tsg_olap/tsg_galaxy_producer) defines RADIUS_RECORD_LOG as a first-class log bean alongside CONNECTION_RECORD_LOG, PROXY_EVENT_LOG, and SECURITY_EVENT_LOG -- confirming RADIUS-based subscriber data ingestion is built into TSG's general-purpose analytics pipeline, not just the Pakistan-specific CyberNarrator identity-correlation add-on.

TSG's v2.0 real-time analytics stack (Kafka to Storm to Druid to ClickHouse, galaxy/galaxy-integration, hosted at git.mesalab.cn) defines a dedicated sessionInterceptHitsLog Druid ingestion job alongside policyEventLog, per-user topUserLog/topWebsiteDomainLog/topUrlsLog reports, and RADIUS/session-record 'completion' pipelines -- showing individual blocked-session events and per-user browsing destinations are logged and aggregated together with subscriber identity in one OLAP store.

TSG's official automated regression-test suite (dongxiaoyan/autotest_tsg, Robot Framework) includes a dedicated case named AllFlowHTTPSIntercept-001.robot under tsg_adc, alongside tsg-bifang API/policy-object test keywords -- confirming HTTPS/TLS interception is a first-class, explicitly QA'd feature path in TSG rather than an incidental byproduct.

TSG's SSL parsing plugin (MESA_Platform/ssl) explicitly detects and 'detains' TCP-fragmented TLS ClientHello packets, buffering/reassembling them before running SNI/certificate inspection (tickets TSG-16297, TSG-19861), with dedicated per-session detain-timeout metrics added in 2024 -- meaning ClientHello fragmentation is a defeated, not just untested, SNI-blocking evasion technique against this DPI engine.

The SSL plugin's own test corpus includes a pcap explicitly labeled for the E21 (Ethiopia) deployment -- test/pcap/e21/1-E21-target.com-196.188.136.150-151.101.2.187.443.pcap with a matching ssl_e21_target_result.json -- showing the TLS-parsing/JA3/ECH code is validated against real captured traffic from the Ethiopia site, tying this specific detection engine directly to the already-established E21 export deployment.

The same SSL plugin added explicit detection of the Encrypted Client Hello extension (type 0xFE0D) with test cases in June 2023, and separately implements JA3/JA3S (2020) and JA4/JA4S (2024) TLS client/server fingerprint calculation as first-class features -- so TSG-class DPI can flag 'ECH is in use' even without decrypting it, and independently fingerprints TLS stacks via JA3/JA4.

MESA_Platform's "http" repo implements sapp's HTTP protocol-analysis engine (HTTP_Analyze.c, HTTP_Parser.c) and is directly referenced by TSG bug-tracker tickets (TSG-16812, TSG-23776, OMPUB-1170), confirming this parser ships as part of the TSG/sapp DPI pipeline rather than being a standalone tool.

MESA_Platform's "quic" module (built and packaged as stellar-on-sapp/sapp RPMs) implements SNI/User-Agent extraction from both cleartext GQUIC (versions 23-59) and encrypted IETF QUIC RFC9000 ClientHello payloads, and supports a QUIC SNI whitelist -- i.e. the DPI pipeline decrypts/parses encrypted QUIC handshakes to recover the destination domain rather than being blocked by QUIC's encryption.

TFE includes a dedicated DoH (DNS-over-HTTPS) business plugin that parses and reconstructs DoH POST/response traffic, applies MAAT policy scanning to it, and supports a "Redirect-DoH" policy action tracked by a distinct "DoH_hijack" counter -- meaning encrypted DoH queries are actively parsed and redirected/hijacked by policy, not simply blocked outright.

The tango/tfe repository carries a long-lived branch "develop-21.09-K18" (K18 is the established Kazakhstan site codename), showing the core TLS-interception/HTTP-hijack/DoH-redirect engine (TFE) had dedicated customer-specific engineering for the Kazakhstan export deployment, not just generic TSG builds.

The tango/tfe ("TFE") engine ships dual root-CA trust stores (tango-ca-trust-ca.pem / tango-ca-untrust-ca.pem, mesalab-ca.pem) for TLS interception plus a JA3-fingerprint-based certificate-pinning detector with a configurable "Dynamic Bypass"; a 2021 bug ticket documents testing this against Firefox without a root cert installed visiting twitter.com, confirming live-target validation of the MITM/pinning-detection pipeline described under the certstore product.

TFE's "PanGu" business plugin implements live HTTP "insert" and "hijack" policy actions with configurable injected-traffic-rate control, and its test suite includes real Facebook and Google Search HTML pages as fixtures for the rewrite/replace logic; PanGu also serves custom HTTP403/404/451 block pages. This ties the content-injection capability directly to specific real-world sites and to a named internal component, "PanGu," not yet documented as its own taxonomy product.

A leaked Grafana dashboard JSON template ("TSG-X") defines panels querying mrzcpd-exporter Prometheus metrics (rx_drops_total, tx_drops_total, ftx_missed_total, rx_bits_total) keyed per tsg-traffic-engine-vsys service function, confirming mrzcpd (the packet-mirror/inline-injection agent) is operationally monitored for packet loss and throughput as a production Kubernetes/Prometheus-instrumented component of TSG-X deployments.

TSG's data plane runs as containers (firewall, packet-io-engine, proxy, sce, shaping) per TSGX appliance, built on an internal packet framework called Marsio/MRZCPD (config at /opt/tsg/mrzcpd/etc/mrglobal.conf), deployed with 32GB hugepages and tunable TX rate-limiting per bonded NIC.

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.

An 'Equipment label and cable label design' spec's data-center appendix lists far more Myanmar carrier taps than previously documented: Yangon sites for NDC, Mytel, MPT, ATOM, Ooredoo, Frontiir, Campana, GTG, GTMH, StreamNet, China Unicom, MTN and MBT; Mandalay sites for Mytel/MPT/ATOM/Ooredoo/GTG/China Unicom; plus Tachilek, Ketong, Myawaddy and Muse border sites; and a Naypyidaw entry 'NPT-NCCC' alongside 'NPT-MPT', plausibly a tap tied to Myanmar's National Cyber [Security] Coordination Center in the capital. The equipment-type table also confirms 'TSG-X' as the formal hardware model code.

A physical rack-elevation diagram for 'YGN Data Center Container 2' (Yangon, Myanmar -- taxonomy site codename M22) shows multiple 1U servers in racks 7-12 explicitly labeled 'TSG OLAP and Cyber Narrator' interleaved with plain 'TSG OLAP' nodes, each with its own IPMI management IP, directly corroborating that the CyberNarrator component is deployed as live production infrastructure at the Myanmar M22 site rather than only described in internal documentation.

A NEZHA web-dashboard screenshot and four matching MySQL dumps (schema nz-temp, source host nz-prometheus) show Nezha is Geedge's internal physical-infrastructure/asset monitoring platform, tracking endpoints, IDCs, cabinets, links, and Prometheus-backed metrics/alerts per deployed Tiangou Security Gateway project -- the same system credited with detecting the hardware failure in the HDM/Nefas Silk fault ticket.

The NMS network-monitoring-server repo (nms/nmsserver) maintains a dedicated, long-lived "k18-1.0" branch (K18 = Kazakhstan codename) alongside its generic dev/master branches, evidencing a customer-specific fork/release line of the monitoring-server product built for the Kazakhstan TSG deployment.

TSG's firewall 'Deny' security-policy action is confirmed implemented via three interchangeable mechanisms: TCP RST injection, forged HTTP 404 response-page injection, and DNS-redirect. Confirmed via commits to MESA_Platform/sapp and tsg/tsg-os-buildimage GitLab repos (git.mesalab.cn).

TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).

Ethiopia customer (E21/E-site) explicitly requested TSG blocking be extended beyond the baseline (Psiphon 3) to a named list of commercial VPNs: Freegate, CyberGhost, Torguard, NordVPN, IPVanish, VPN Unlimited, ExpressVPN, Surfshark, Windscribe, Hotspot Shield, Ivacy, Atlas VPN, PureVPN, ProtonVPN, Norton Secure VPN. Engineering confirmed delivery of NordVPN and Hotspot Shield signatures with successful field tests.

A ticket from a Beijing TSG test environment (v23.07) reports that a 'Deny Telegram' policy generates hit logs but produces no actual blocking effect; the ticket shows no recorded resolution before closing over a year later.

TSG ships built-in BitTorrent detection apps in its "App Sketch DB" (v23.07). A 2023-08 field test found policies matched but did not block BT downloads; root cause was a UDP source/destination port ordering case (server port > client port) that let the real client IP land in the wrong field for the blocking policy to act on. Fixed via a second security policy rule.

TSG has a named application label "Psiphon-Server-APP" used in its Application-identification/Deny policy engine. A confirmed bug: non-DNS UDP/53 traffic was misclassified by the base protocol-identification plugin as DNS, which suppressed the Deny action even though the session was correctly labeled Psiphon-Server-APP in the security event log — i.e. a competing protocol classifier's (mis)classification silently overrode the intended enforcement action.

Jiangsu domestic deployment streams filtered TSG session-record log fields to a third-party contractor via Kafka-to-Kafka integration ('Real-Time Log Streaming'), at the request of a Nanjing telecom regulatory bureau (南京管局), with the third party also given a Hive table-creation schema for their own ingestion pipeline.

TSG deployments include an inline optical-bypass failsafe (光保) that, on link/health failure, can leave the segment in bypass (fail-open passthrough) mode rather than reverting to inline inspection — a 2023 incident at E21 (MSH-TSGX-02, 120Gbps) had a bypass segment stuck open until manually tuned.

TSG23.07 added support for FQDN substring matching (vs. exact/wildcard only) for the P19 deployment, a detection-capability upgrade.

Geedge's TSG self-check test suite (run against firewall version v23.07.18-591aed7) enumerates the product's full interference capability set: SSL bypass/intercept (including handling of expired, self-signed, and untrusted-root certificates), HTTP/SSL proxy actions (redirect, block, replace, hijack, insert), three distinct firewall deny modes (silent drop, TCP RST, blockpage), and DNS deny modes (silent drop, A-record redirect, AAAA-record redirect, including TTL-range variants).

A performance bug at a domestic Xinjiang test site (25-70Gbps) traced packet-processing lock contention to a plugin named "tsg_vulpes" calling an ONNX Runtime model for real-time "encrypted voice recognition" on live traffic; disabling this ML classifier resolved packet loss, indicating it's an optional, performance-costly add-on.

TSG integrates a licensed third-party DPI engine (versioned separately from TSG/App Sketch DB releases) that repeatedly segfaulted across many E21 (Ethiopia) NPB nodes over Oct-Dec 2023 when processing specific packet-encapsulation stacks (Ethernet->MPLS->IPv4->UDP, VLAN->IPv4->UDP), requiring an App Sketch DB version bump to resolve.

TSG retains full per-session traffic logs (not just blocking events) at national-center scale via ClickHouse, aggregated from provincial sub-centers via ETL; log volume was large enough (~25% daily growth from one sub-center optimization alone) to require dedicated IO-reduction engineering (secondary indexed sub-tables, disabling several sub-table sync views), confirming pervasive session-level traffic logging/retention is a standing capability independent of, and broader than, active blocking.

A confirmed bypass — TSG failed to extract SNI from TLS ClientHello when the SNI extension appeared later than expected in the extension list, letting those flows through unblocked (and incidentally TLS 1.3 flows generally, since clients fell back to 1.3 after 1.2 was blocked); fixed on-site via a patch to the "ssl.so" detection plugin.

TSG's sapp engine requires periodic authorization from an "ACC" server via a "LM Server"; if a TWA device loses management-network connectivity to the LM Server for over ~1 hour, sapp stops running entirely until authorization is re-acquired. Fixed to auto-retry.

Confirms TSG deployment extends beyond Yangon/Mandalay to Myanmar border towns Tachileik, Kengtung, Myawaddy, and Muse, backhauled to the Yangon DC via VPN devices required to meet <100ms latency and >=1Gbps bandwidth.

A TSG deployment was rolled out to Jiangsu's Yangzhou "anti-fraud" project in March 2024, explicitly timed to complete before China's "Two Sessions" political meetings, with dedicated (non-shared) OLAP hardware.

A Deny policy using an SNI "Negate" condition fails to block after a page is refreshed multiple times, a duplicate of a prior known bug (TSG-18234) — indicating a reliability gap for negated-SNI-condition policies under repeated/retried connections.

TSG's appliance hardware line is branded 'TSG-X' running an OS layer called 'TSG-OS'; a performance-tuning ticket requests two TSG-X units built on dual-socket AMD Zen 4 64-core CPUs, indicating the current-generation hardware performance tier for large-scale deployments.

TSG's sapp/firewall components run as Kubernetes pods, built from a "MESA_Platform" monorepo (path fragment .../MESA_Platform/sapp/... visible in a crash log), using jemalloc. A 2024-03 SIP-heavy deployment triggered jemalloc memory-purge deadlocks under high UDP concurrency, crashing the firewall pod every 2-4 days; fixed via jemalloc tuning and a session-count cap in the SIP plugin config.

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.

Fujian's domestic anti-fraud TSG deployment must pass China's MLPS compliance testing, requiring hardware-token (Ukey) login from vendor "数盾科技" (Shudun Technology). Xinjiang's 5G project is slated for the same treatment via a different vendor.

TSG's app/protocol detection ("AppSketch" / context_based_detector plugin, part of the SAPP packet pipeline) is not purely static-signature: each detection rule can be an arbitrary Lua script (APP_SIG_LUA_SCRIPTS table) executed per-session in a per-worker-thread LuaJIT VM, with access to packet payload, session context counters, and helper functions (APP.data, APP.context.c2s_count, APP.log_debug, APP.append_extra_info). A validation CLI tool (luac-tool) checks script syntax, timeout, and return-value type before import.

TSG is deployed across multiple named Myanmar telecom carriers (Mytel and MPT/Myanmar Posts and Telecommunications) at both Mandalay (MDY) and Yangon (YGN) sites -- device naming convention TSG-OS-<city>-<carrier>-TSGX<n> -- confirming a nationwide, multi-operator rollout rather than a single-ISP pilot.

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.

TSG has a Lua-scriptable custom-classifier engine: operators upload a Lua script defining a custom traffic "Attribute", then build custom "App" rules matching on it. A 2024-05 ticket references a script literally named cdn_tunnel_finder.lua -- an operator-authored detector targeting CDN/domain-fronting-style tunneling.

Internal asset naming ("YGN-MYTEL-EF01-SMBIO01") ties a TSG deployment directly to Mytel, the Myanmar telecom carrier, at a Yangon (YGN) site -- corroborating and adding carrier-level specificity to the Myanmar export relationship already documented by Justice for Myanmar's "Silk Road of Surveillance" report.

A K18 customer specifically requested TSG support for TCP-segmented TLS ClientHello messages, confirming this was previously an inspection gap; Geedge shipped a fix ("Hotfix-Inspection-TLS-PQC-Extension") in 2024, and the same hotfix name indicates TSG's TLS inspection also tracks post-quantum-crypto ClientHello extensions.

Geedge ran a live demo for a visiting delegation at its Yizhuang (Beijing) facility specifically showcasing Psiphon3 blocking, alongside a CN console walkthrough — evidence Psiphon-blocking is used as a sales/prospect differentiator, not just a defensive feature.

Confirms the full Ethiopia (E21) deployment site list — Bole, Shashamane, Bahir Dar, Safaricom Kaliti, Safaricom STEP HQ, Dire Dawa, Legehar, Old Airport, Microwave, Nefas Silk, Kirkos — explicitly including Safaricom Ethiopia (the mobile carrier) sites, with aggregate session-log throughput nearly doubling from 728,000/s to 1,383,000/s between March and July 2024.

Project "M22" (running the Turbo VPN/7VPN extraction program) is tied to a site logged as "YGN NDC" -- YGN = Yangon, Myanmar; NDC reads as National Data Center. Corroborates M22 as Myanmar via primary-source project/site code.

Confirms TSG-OS deployment directly on Mytel's (Myanmar carrier) network with named host identifiers at Yangon (YGN-MYTEL-TSGX025, YGN-MYTEL-TSGX026) and Mandalay (MDY-MYTEL-TSGX001), corroborating and specifying the M22/Myanmar deployment beyond what Justice For Myanmar's public report identified.

A burst of UDP traffic at a Xinjiang site (Bole-IGW -- Bole is a Xinjiang city, matching gfw.report's identification of Xinjiang as a domestic TSG deployment region) hitting monitor policies drove all packet-processing-core CPU to >99%, exhausting DPDK mbuf buffers and triggering cascading container restarts across ~10 NPB (Network Packet Broker) devices.

Internal project codename "M22" corresponds to a Myanmar deployment at telecom operator Mytel (site id "YGN-MYTEL", Yangon), running on TSGX hardware appliances (at least 25 units observed at this one site) alongside the TSG-OS software stack — extending prior public reporting (Justice for Myanmar) with the specific internal site/customer codename and confirmed hardware scale.

During QuarkVPN feature extraction, Geedge found client/server roles over UDP distinguishable by port-number heuristic (server's fixed ports 59001/59002/60000 exceed the client's random port), though this heuristic is currently causing misidentification, filed as an open bug.

At the Quanzhou Unicom (Fujian) TSG-OS site, under CPU/traffic pressure TSG's 'overload protection' causes packets to reach SAPP capture but never reach the firewall enforcement stage, producing a confirmed policy bypass ("穿透"). The operational fix disabled policy_sketch, traffic_sketch, overload_protection, duplicate-packet filters, and the SSL_CERT/SSL_JA3/HTTP_GZIP/DNS decoders to reduce CPU load, i.e. detection/enforcement is explicitly traded away to preserve throughput at peak load.

TSG's DNS Redirect firewall action has two modes — "hijack" (constructs and sends a spoofed DNS response, dropping the real request) and "replace" (only modifies the DNS response in transit) — with correct mode depending on inline vs. mirror/passive deployment; a Fujian domestic site (mirror-mode, request-only visibility) hit a bug where the default mode silently had no effect.

Kazakhstan (K18) required a formal written response to its "进出口" trading-company intermediary about an unspecified "中间人" (man-in-the-middle) problem, resolved via a sapp upgrade. The generic "进出口" intermediary language recurs across K18 and E21 threads, consistent with CEIEC as a shared export channel.

At the K18 site, TSG's TLS-interception ("Tera") steering rules failed to cover all of a CDN-fronted site's IPs (avg.com via Akamai): certificate replacement succeeded on one resolved IP (185.189.92.41) but not another (23.61.224.112), indicating Tera's per-IP steering configuration can miss a fraction of a multi-IP CDN's address space.

TSG's SSL interception engine matches wildcard SNI patterns (e.g. "*tumblr.com") to decide whether to intercept (certificate-replace) a connection, but a separately-maintained "SSL Decryption Exclusions" allowlist takes priority over interception policy -- a domain on that list is never intercepted even if it matches an active policy.

Project "E21" is conclusively Ethiopia: names IGW sites by city -- MWV-IGW, BOLE-IGW (Bole, the Addis Ababa airport district), Shashamane-IGW, Bahir Dar-IGW, Dire Dawa-IGW, Legehar -- each with a distinct IP block, indicating a national multi-city topology.

Root-caused an Ethiopia SNI-block-failure incident to the detection mechanism itself: APP_SKETCH's FQDN-scanning module -- which exists specifically to identify Psiphon3 and Freegate via top-N SNI matching -- was CPU-expensive enough to saturate cores, triggering sapp's fail-open DDoS bypass and letting some target connections through uninspected. A signature-structure fix roughly doubled throughput (33K/s to 73K/s new connections) and disabling the fail-open bypass restored reliable blocking.

Project "E21" tested SNI-FQDN-wildcard block policies against international news/media/academic domains -- opride.com (Oromo news), ethiotube.net, Reuters, NYT, Bloomberg, GitHub, ResearchGate, NIH.gov -- from an Ethio-Telecom-range office IP. Most blocks silently failed (shared root cause with OMPUB-466); britannica.com needed a separate deny-quic policy since QUIC bypassed SNI blocking.

TSG maintains a traffic-volume-ranked "Top SNI" / "Top Server IP" allowlist (Galaxy component, learned from live traffic, capped at top ~2000 SNIs / ~40000 server IPs per Nacos config) that is checked before a VPN/circumvention-tool deny policy (including a Psiphon3-specific policy) is enforced. Confirmed empirically: Psiphon3 client traffic whose destination SNI was in the Top SNI list passed through undenied, while traffic to the same client IPs with an SNI not yet in the list was blocked. A 2022-06 incident over-blocked TikTok/BBC/CNN/NYTimes because their SNIs were not yet in the learned allowlist at the time.

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.

TSG's app_proto_identify/app_sketch_local components reference and extend the open-source nDPI project's detectors (specifically openvpn.c) when fixing signatures. "MAAT" is sapp's Redis-backed live-config-sync subsystem, which can enter a bad state requiring an sapp restart to reload policy.

TSG deployed at a Xinjiang site could not reliably block QQ via HOST/SNI matching due to excessive payload-based config, so Geedge added a dedicated OICQ (QQ's underlying protocol) L7 identification capability in the app_proto_identify plugin, extracting LPI-library classification results for WeChat and OICQ as first-class 'App identification' output, released in the 22.08 TSG version.

Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).

A custom rule combining SSL certificate field conditions to block Bilibili had no actual blocking effect despite matching sessions appearing correctly in session records — a gap between detection/logging and enforcement for this rule type.

Internal project code "K18" is a Kazakhstan TSG deployment: a 2022-10 ticket requests updating the "Data-Center" field in ADC device provisioning files from "Nur-Sultan" to "Astana", directly tying K18 to Kazakhstan. A separate cabling-documentation ticket references a physical site in Aktau, a Kazakh Caspian port city.

In late 2022 a Geedge customer ("E21" site) explicitly requested a nationwide (全国范围) deny policy against Psiphon3 and ten other commercial VPN products (ExpressVPN, NordVPN, Surfshark, Ultrasurf, iTop VPN, Hotspot Shield, ProtonVPN, CyberGhost, TurboVPN, TunnelBear). Geedge split feature-extraction work between its engineering and QA teams, packaged signatures as importable appjson files, and tracked per-product blocking effectiveness.

A Fujian-site performance incident (single-core CPU pinned >90%, packet loss) traced to a large keyword-object list (~400 hex-encoded keywords, described as connected-vehicle-related) being scanned per-packet by components named libmaatframe, librulescan, and fw_http_plug. Removing unused keyword objects resolved the packet loss.

A known Psiphon3 relay IP, already in the signature set, wasn't blocked because it used destination port 179 (BGP): TSG's switch/distribution board bypassed port-179 traffic without forwarding it to the compute board for inspection at all (confirmed at the E21/Ethiopia site). A separate domain-whitelist mechanism can also override deny actions. Fixed by routing port-179 to compute.

TSG at Quanzhou Telecom (Fujian, domestic) runs "sip"/"fw_voip" plugins logging call-detail-record fields (caller, callee, User-Agent) specifically for SIP INVITE/BYE (call setup/teardown), by design excluding SIP MESSAGE/REGISTER traffic.

Fujian's anti-fraud "big screen" dashboard treats circumvention-tool use as a first-class flagged category alongside fraud: warning reasons include "visited a fraud-linked site, used an accelerator" and "new user of AiJiaSu" (a named accelerator app), each tied to the individual's phone number and refreshed ~every minute.

sapp has a CPU-overload protection mechanism that bypasses inspection when new-session rate is high enough (observed: 71 threads, ~50K new TCP/sec, ~32K new UDP/sec at a P-POC site). Treated as by-design; only the specific reported instance wasn't reproducible.

Fujian Unicom (福建联通), coordinating with the domestic customer referred to internally as "工联院", requested TSG perform HTTP-host-based redirect blocking (to a Fujian anti-fraud police portal) instead of relying on Unicom's own 303-redirect infrastructure, because TSG's RST-based block executed faster and pre-empted it. TSG at the time only supported URL-based redirect, not host-based, when the malicious URL path was empty.

At export site "E21" (naming consistent with Ethiopia elsewhere in this batch), Traffic Logs run across 13 servers with 40TB disk each (520TB total); Session Records consume ~7TB/day and Security Events ~1.5TB/day, giving a rough sense of logged traffic volume.

TSG's traffic pipeline has an encapsulation-handling layer called "marsio" (versions marsio4/marsio5) sitting in front of "sapp" (the core stream-processing engine). For unencapsulated mirrored traffic, a "wired_graft" plugin injects link/circuit identifiers into the MAC address field of copied packets so downstream session logging can recover which physical link a flow came from; for encapsulated traffic (e.g. VXLAN) marsio itself must expose that metadata.

As of TSG v23.07, FQDN matching supports left-anchored prefix/wildcard matching (e.g. 'voice-group-80x-api.*'), added specifically so a Fujian domestic deployment could detect domains with a fixed subdomain prefix but rotating remainder. Earlier versions only supported exact FQDN match.

A crash backtrace from an Ethiopia-site TSG-OS node reveals internal DPI plugin architecture: a core 'sapp' binary (/opt/tsg/sapp/sapp) loads protocol-dissector plugins (dtls, tsg_master.so) chained through a 'marsio4' packet-processing worker, with a KNI/DPDK-style packet path (eth_entry -> ipv4_entry -> vxlan_entry -> gtp_entry -> dtls dissector). The specific bug was an uninitialized DTLS hello-verify cookie field.

TSG has a configurable, policy-driven TLS interception (MITM) engine (service: certstore) with per-connection 'Trusted'/'Untrusted' certificate profiles, a certificate-pinning-detection classification ('Pinning' vs 'Not Pinning'), and a Dynamic Bypass toggle, tested against *.badssl.com as of TSG 22.11/22.12.

In Fujian's Quanzhou China Mobile 5G deployment (2023-04), sapp crashed repeatedly with the DTLS inspection plugin enabled; disabling sip/dtls/fw_dtls/fw_voip plugins stopped it. Root cause: DTLS parsing layer on an old, buggy version, with a full rewrite planned for v22.06 and DTLS inspection told to stay off meanwhile.

Extensive engineering effort to extend TSG's built-in 'APP Sketch DB' fingerprint database with signatures for major domestic Chinese apps (Douyin, Kuaishou, Mango TV, JD, Tencent Cloud, etc.), primarily via SSL SNI matching, with iterative per-feature test/fail/patch cycles against specific in-app actions (e.g. certain Douyin menu items stayed unblocked after the main signature succeeded).

TSG's Psiphon3 signature is a multi-stage stateful match (IP, then protocol/SNI, then a negative/NOT condition) where the NOT condition is only evaluated once, explicitly at the 8th packet of a session. Sessions carrying fewer than 8 packets never reach that evaluation point and are never flagged as Psiphon, regardless of actual protocol. Confirmed in production (E21) as the root cause of a customer-reported partial bypass.

TSG runs an automated program named 'vpn-thwarting' that calls the CM management API hourly to push freshly-learned Psiphon3 server IPs into a live blocklist object (dynamic_psiphon_ip); at the time of this incident the object held roughly 70,000-73,000 IPs, sourced from a companion automated-learning system referred to as 'CN'.

At export site "E21," TSG has a named detection object "Psiphon-Server-Signature"/"Psiphon-Server-APP"; two near-identical sessions to the same Psiphon-associated IP (82.223.55.87) over SSH/port 22 were logged, but only one was correctly tagged — a session-to-session consistency gap in the signature match.

A debugging ticket for sites "Old Airport-PE" and "Bole-IGW" (naming consistent with Addis Ababa, Ethiopia) confirms the customer verified Psiphon3, YouTube, Facebook, and Telegram blocking as working well during independent testing, and reveals the operational session-correlation method used when packet captures and system logs must be cross-referenced across NAT: JA3_HASH + server IP + client public IP + SSL SNI.

For Hotspot Shield's IKEv2 mode, SNI-only blocking failed because logged SNI hits corresponded to the VPN's own domain/CDN traffic while tunnel-negotiation domains (journalissue.us, middle-island.us) went unlogged; switching the rule to match DNS query name (qname) for those specific domains successfully blocked the connection.

Geedge's QA team tested Hotspot Shield VPN's three underlying protocols (Hydra, IKEv2, WireGuard) against a shipped TSG signature across Windows/Android/iOS. Hydra and WireGuard were blocked on effectively all tested nodes; IKEv2 was NOT blocked on the "Auto" and "Streaming" server-selection modes on any platform tested.

TSG's App Sketch DB includes a "TachyonVPN" signature. A 2023-06 report found ordinary browsing to microsoft.com misclassified as TachyonVPN in security event logs; closed Nov 2024 with no confirmed fix.

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.

TSG's core traffic-processing daemon is named tsg_master (GitLab repo git.mesalab.cn/tango/tsg_master, part of the "TSG Appliance" project group). A 2023-07 field incident (site "P19") showed a single-core deadlock in tsg_master's log-sending path (function tsg_send_log) causing 100% CPU on one thread and packet loss; fixed in tsg_master-6.0.38 and shipped via the tsg-os-buildimage repo.

TSG's URL-blocking (P19 site) failed to block a second, near-simultaneous TCP session Chrome opens per HTTP request when that session's first-data-packet arrival lagged the SYN by 45+ seconds, because TSG's connection 'opening timeout' parameter defaulted to 10s and expired first, letting the session fall out of tracked state. Fixed in a later release by raising the timeout to 60s.

Documents Geedge's standard operating procedure for building a new app-detection signature: collect a target's server IPs and FQDNs, create IP-match and SNI-match (ssl.handshake.extensions_server_name) feature objects, combine them via OR logic into a named custom "application", then validate via session-log reports filtered on that application label.

TSG-OS's boot/installer layer (tsg/tsg-os-onie) is a fork of the open-source ONIE network-switch installer. Commits confirm production support for Dell EMC R7525 x86_64 servers and Huawei Kunpeng 920 (AArch64) servers as TSG appliance hardware, alongside whitebox switch support (Accton).

The galaxy/deployment/online-config repo — the central field/site configuration store — maintains per-customer git branches named E21 (Ethiopia), P19 and P19-POC (Pakistan), and XJ (Xinjiang), each tracking dated "现场配置" (field configuration) commits pinned to specific TSG software versions (e.g. TSG 22.02, 21.11), directly corroborating the E21/P19/XJ site codenames already established in taxonomy and confirming ongoing, versioned field deployments as recently as 2023-07 (a "P19 23.07 online-config" branch commit).

Two hands-on QA 拨测 (dial-test) reports document engineers connecting to Ooredoo Myanmar's mobile hotspot and to a 'Campana' WiFi network supplied by 'NCSC', then repeatedly browsing target sites (pixiv.net, zerohedge.com, internxt.com, littledayout.com, palaceskateboards.com, among others) while packet-capturing and cross-checking TSG 'statistics' policy hits against specific internal tap addresses (YGN-Ooredoo: 10.164.12.x, YGN-CPN: 10.169.12.x) -- direct field verification of inline/mirror tap function at named Myanmar carrier sites.

Internal tickets name an Astana ("K18现场") datacenter by the Kazakh capital's name directly, plus wiring tickets for Karaganda and Zhezkazgan and a training outline describing an Almaty backup datacenter -- corroborating and adding city-level specificity to the Kazakhstan TSG deployment already in this corpus from secondary reporting.

Geedge runs a video-content-fingerprinting pipeline: a crawler pulls YouTube videos by topic, routed through mitmproxy with a custom trusted root CA to intercept TLS and capture per-video traffic, targeting ~100 captures per topic.

Internal test of a standalone DNS server explicitly described as "DNS劫持" (DNS hijacking): baseline resolution passes through upstream, but a test domain (www.baidu.com) is intercepted and returned a different IPv4/IPv6 address than its real one.

Geedge runs standing weekly signature-extraction assignments specifically against Freegate, Psiphon, Ultrasurf, and Tor Browser (by Play Store package name) across at least two projects, each with a dedicated engineer, spanning Android/iOS/Windows.

Domestic (Xinjiang-linked) systematic blocking-capability testing covers a broad swath of ordinary consumer apps well beyond circumvention tools -- named test targets in this single 50-app batch include a Xinjiang police app (新疆公安) and Xinjiang government-affairs app (新疆政务) tested in the same numbered sequence as banking, e-commerce, gaming, and video apps -- indicating the AppSketch pipeline's scope is general internet-content control capability, not solely anti-circumvention.

M22's extraction against "VPN Hero" (OpenVPN-based) recovered 13 FQDN + 13 IP indicators; FQDNs follow a "zampakuto...shop" template. Post-signature testing in the Myanmar demo environment found no successful connections on Android/iOS.

Geedge extracted and analyzed Betternet VPN's underlying protocols (WireGuard, a proprietary "Hydra" protocol using spoofed-domain TLS 1.2, and IKEv2), and found the Hydra protocol could be "completely blocked" via JA3 TLS fingerprinting; IKEv2 was blocked via UDP port 500/4500 policy, and thousands of VPN server IPs were extracted as a supplementary IP blocklist.

Documents the exact methodology used to derive a block signature for 'Giti VPN': TLS interception (fiddler) to decrypt the app's traffic, identifying its control/initialization domain and a second per-session domain pattern, then blocking by those two domain-name features rather than deep packet content.

Geedge's non-VPN app signature-testing program is a numbered catalog reaching at least #551-600 as of 2024-07, tested against current Android/iOS builds -- systematic coverage across hundreds of apps, not a narrow VPN-only list.

Project "M22" runs a standing weekly program to extract and patch detection signatures against "Turbo VPN": automated dial-testing continuously discovers server IPs (tens to hundreds/week), each batch packaged into a dated JSON patch file, validated for both blocking efficacy and false-positive risk before rollout. Ran continuously Aug-Nov 2024 in the source ticket.

The same M22 weekly-extraction program runs in parallel against "7VPN": automated dial-tests repeatedly found its free-tier nodes already non-functional/blocked across weekly checks Aug-Oct 2024, indicating sustained monitoring even absent a signature update.

Geedge extracted ProtonVPN server IPs using the app's own debug-log output to find its server-list API endpoint, directly querying it to harvest ~5,800 server IPs, then used automated repeated connection cycling to extract ~200 additional rotating IPs after the initial list was blocked; the app was subsequently reported fully blocked on Android, iOS, and Windows.

M22's VPN signature-extraction workflow, when API sniffing (fiddler) fails, escalates to decompiling the target APK: jadx-gui, then apktool -- which recovered node information for "Luna VPN" after the first two methods failed.

Myanmar deployment (M22) systematically reverse-engineered and blocked Orbot (Tor's official Android client) and ProtonMail, alongside numerous consumer VPN apps, via the AppSketch feature-extraction pipeline. Orbot: 287 server IPs extracted across multi-hop nodes, one connection mode fully blocked. ProtonMail: mail server IPs/FQDNs extracted, blocking verified as full service denial (cannot send, receive, download attachments, or create a new account) on Android and iOS.

M22 runs a large-scale automated pipeline against numerous commercial VPN apps: APK decompilation + HTTPS-proxy interception to extract servers/FQDNs, automated dial-testing at volume (one app: 17,554 dial-tests, 4,073 servers discovered, 94% 24-hour block rate), and OpenCV-based automated ad-dismissal to keep test automation running unattended.

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.

Weekly TSG 'SNI Report of Overseas APP' and 'Server IP and Location of Overseas APP' reports show continuous SNI/server-IP-and-geolocation classification, at national ISP/IDC scale (up to ~447 Gbps average / ~1 Tbps peak, hundreds of billions of sessions per week), of a fixed watchlist of foreign platforms including Youtube, Facebook, Google, Twitter, Instagram, Telegram, Whatsapp, Viber, Line, Messenger, Snapchat, Gmail, HBO, Netflix, BBC, Discord, ESPN, Hulu, Bigo, and Canvas -- establishing that TSG's core function includes always-on, large-scale identification and cataloguing of exactly the class of foreign communication/circumvention-adjacent platforms that are typical censorship targets, independent of any single export customer.

galaxy/tsg_olap/p19-file-sync-service is a Kafka-consumer-driven Spring Boot file transfer service explicitly namespaced "p19" — matching the taxonomy's WMS-UTR/P19 Pakistan site codename — confirming a dedicated TSG-OLAP infrastructure component built specifically for the Pakistan deployment's file-sync/HOS-storage needs.

Confirms an active Pakistan TSG-OS deployment (ACC license servers 10.10.10.159/10.10.20.159, Sentinel HASP hardware-dongle licensing) as of October 2023, corroborating Pakistan as a live customer, consistent with Amnesty International's 2025 'Shadows of Control' report.

PanGu's multimedia business schema defines dedicated service IDs for blocking AND monitoring based on speaker (voice) recognition, TV/radio station-logo ('台标') recognition, and face recognition (initially 0x10B-0x10D block / 0x18B-0x18D monitor as of Sept 2018, renumbered to 0x10C-0x10E / 0x18C-0x18E later that month) -- i.e. biometric/media-content classification is a native, named blocking capability in TSG's core policy engine, not just protocol/keyword/domain matching.

TSG's core policy-database spec (internal codename 'PanGu') formally defines proxy-layer 'Insert' and 'hijack' manipulation actions with configurable target IP/URL and, from May 2019, response-header fields -- plus a separate 'IP address impersonation' proxy service (business ID 0x206, PXY_INTERCEPT_IP) backed by a spoofing address pool (PXY_OBJ_SPOOFING_IP_POOL) -- i.e. HTTP response injection/hijacking and IP-level spoofing are named, first-class business rules in the schema underlying every TSG deployment, not ad hoc capabilities.

PanGu defines a configurable DNS response-spoofing subsystem (NTC_DNS_FAKE_IP_CB, NTC_DNS_RES_STRATEGY) supporting named 'answer groups' with a configurable number of fake answers returned per group (service ID 0x40 'dns欺骗'), i.e. DNS injection is a general, group-configurable policy primitive in TSG rather than a single hardcoded fake-IP response.

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.

TSG's SSL/IPD logging schema records a hit_pos field on every SSL-blocking log entry (NTC_SSL_LOG, IPD_SSL_IP_LOG) whose value is explicitly one of SNI, SAN, or CN -- confirming TSG's TLS-blocking decision can be attributed to, and therefore driven by, the certificate's SAN or CN fields, not only the ClientHello SNI extension.

PanGu documents a dynamic VOIP-blocking pipeline where a system named 'Eastwatch' generates four-tuple blocking rules from VOIP call-detail ('FD') logs, which are then pushed by the policy gateway ('阀门') to a downstream component named 'C3' (MM_DYN_VOIP_DROP table) -- two previously unseen internal component names in this corpus tied specifically to real-time VOIP call blocking.

Internal project codenames decode to specific customers: M22 = Myanmar (operators Mytel, Ooredoo Myanmar, and ATOM; sites YGN=Yangon, MDY=Mandalay), K18 = Kazakhstan (site renamed Nur-Sultan to Astana in OLAP config), E21 = Ethiopia (operator Safaricom Ethiopia; sites ADAMA-PE/SSM-PE to KLT-IGW/SHQ-IGW), WMS-UTR = Pakistan.

On the E21 (Ethiopia/Safaricom) deployment, TSG blocked Psiphon3 via ~1.69M known server IPs; in one ~3.5hr window, 76,496 unique client IPs still attempted Psiphon3, which accounted for 14% of total bandwidth, 5.96% of sessions, and 1.32% of unique client IPs despite the active Deny policy.

The general-purpose TSG big-data pipeline (galaxy/tsg_olap/dynamic_complement) includes dedicated "FlumeRadiusOnOffInterceptor" and "FlumeSubscriberInterceptor" modules plus a standalone "用户名写入Hbase程序和上下线日志程序" (username-to-HBase-write and login/logout-log program) built against tickets TSG-1845/TSG-2020, showing RADIUS-based subscriber-identity correlation is wired into the general OLAP data pipeline used across deployments, not confined to the Pakistan-specific CyberNarrator subscriber-correlation module already documented.

TSG's galaxy/tsg_olap analytics subsystem runs dedicated Storm topologies (radius-relationship-hbase, log-subscriber-hbase-datacenter) that ingest carrier RADIUS/AAA accounting data and subscriber-ID logs from Kafka and persist account-to-framed-IP relationships into HBase, generalizing the RADIUS-based subscriber correlation documented elsewhere at the Pakistan CyberNarrator deployment into standard TSG OLAP infrastructure not tied to one customer.

A multi-week investigation on Fujian Mobile's network found TSG's RST-injection blocking intermittently failed to reach the client even on a correctly-matched policy, traced to carrier-side loss/delay on the injected-RST path and TCP port-reuse/SYN-retransmission edge cases at one mobile site, with RST send rates up to 40,000-80,000/s during the anomaly.

The same feature spec adds a "定向攻击检测" (targeted-attack detection) mechanism: the front-end tracks per-rule (configID) hit counts against a threshold/interval, and once exceeded can throttle or fully suppress emission of RST/block packets and logs for that rule (action codes include "do not send block packets," "sample block packets") -- an explicit rate-limiting countermeasure against the operator's own RST-injection infrastructure being weaponized for reflection/availability attacks, the same attack class (Bock et al., "Weaponizing middleboxes"; "Your censor is my censor") cited in this same lab's own literature survey (see companion finding 2026-mesa-censorship-research-survey-f8c349).

MESA Lab engineering logs (2020) describe development and TSG-environment testing of a SAPP plugin that identifies encrypted audio/video traffic and distinguishes on-demand from live streams. The workflow uses Fiddler (a TLS MITM proxy) to decrypt traffic client-side and auto-label training data for the underlying ML model, and required a dlopen() workaround to load libpython.so for the model at runtime.

A leaked shell hotfix script shows an operator live-patching a production sapp instance — installing sapp-pr-4.3.59.c5b96a4-1.el8.x86_64.rpm, dropping in traffic_sketch.so under sapp's stellar_plugin directory and libfieldstat4.so under the framework lib, and tuning sapp.toml stream parameters (max_timeouts_per_sec, kickout_udp_stream_enabled, bloom_library, TOPK_UPDATE_MS) — concrete evidence of sapp's plugin architecture and active operational tuning cadence.

TSG's DPI signature engine is organized around named internal components confirmed by config paths and error logs: SAPP (installed at /home/mesasoft/sapp_run or /opt/tsg/sapp), MAAT (config at .../tsgconf/maat.conf, tied to a Redis-backed APP_SIG_SESSION_ATTRIBUTE_STRING table), and App-SketchDB (a versioned, centrally-maintained app-identification signature database pulled periodically by field deployments). One deployment's provincial gateway alone had 1,667 TCP/UDP first-packet payload signature entries active (396 at the IDC site), confirming payload-prefix matching as a live, large-scale detection method, including custom byte-prefix entries for DingTalk and WeChat.

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.

The official SAPP platform manual ("Geedge Networks Confidential And Proprietary") documents an optional signature_enabled config flag that stamps sapp-injected TCP RST packets with a detectable pattern in the ip_id/ip_ttl/tcp_win fields so operators can later verify, via a Wireshark plugin or standalone tool, whether a given RST originated from a sapp instance -- the manual explicitly notes 100% recall but not guaranteed 100% precision. The manual separately documents that sapp supports three distinct wire-injection topologies (sys_route, vxlan_by_inline_device, raw_ethernet_single_gateway) and that its tcpdump_mesa debug tool has a dedicated "inject" packet class covering both TCP RST and forged DNS replies.

Internal 'SAT项目' meeting notes and a progress-report slide describe a new mobile-subscriber-correlation system being built by reusing the existing TSG UI ('NTC or TSG'), whose core open technical problem is reconciling GTP mobile-signaling data with RADIUS billing records to identify a user from IP address alone when no TEID is available in 4G networks; the work is tied to a filed patent, '一种应用服务分类识别方法及系统' (a method and system for application service classification and identification).

A MESA lab engineering project codenamed "SAT" builds a user-station identification module on top of TSG, using the MAAT rule-file format for its front-end/back-end policy (PZ) interface, and ingests LTE mobile-network-element traffic (S1-U interface -- SGW/PGW/eNodeB/MME, captured via a simulated Docker SDR environment) to write subscriber-station status into a "TSG-Radius" table.

The 'galaxy/deployment/schema-updater-tool' repository's test schema catalog enumerates TSG/Galaxy's production log/event table set across ClickHouse, Druid, ES, and HBase backends, including radius_onff_log (RADIUS on/off subscriber events), gtpc_record (mobile-core GTP-C signaling), dos_event, active_defence_event, proxy_event, and security_event_hits_log -- a concrete inventory of the telemetry TSG's analytics layer generates.

TSG's "shaping-engine" (tango/shaping-engine) implements bandwidth-shaping "Profiles" (fair-share token allocation, priority-based bandwidth borrowing, active queue management) driven by rules loaded directly from MAAT (shaper_maat.cpp/h, shaping_maat.json, migrated to MAAT's JSON rule format with UUID rule IDs), providing the likely underlying enforcement mechanism behind app-specific RateLimit deny actions such as the Psiphon/Freegate throttling documented in gap_tsg_api.

A 2020 internal hardware requirements spec ('深串系统需求文档' / 'Shenchuan [deep-serial-tap] system requirements', v1.2, authored by '北京恒光研发部') for a project named '信工所深串接项目' (an Institute of Information Engineering, Chinese Academy of Sciences project) describes an ATCA-chassis inline traffic-tap appliance -- S3200 switch boards plus RTM20XG POS line cards plus 9 x86 processing blades -- that serially intercepts 100GE/40GE/10G/2.5G POS links, filters 60%% of traffic to dedicated 'business X86' boards via domain rules or 'deep DPI' rules, and fails open through an optical bypass protector (OLP) on hardware fault. This is a previously undocumented internal hardware codename ('深串'/Shenchuan) distinct from the named products already in the taxonomy.

A recurring 'IP标签（石河子）报告' (IP Tag (Shihezi) Report) shows a monitoring deployment specific to Shihezi, a Xinjiang Production and Construction Corps city, tracking both IDC links (22 links, 1.21Tbps total / 15 links, 1.14Tbps actively connected) and separate 出入口 egress links (26 links, 2.08Tbps) for the same site and date -- a specific domestic site identity more granular than the general 'Xinjiang' label already in the taxonomy.

Signal's built-in censorship-evasion feature routed traffic through Google infrastructure (SNIs clients3/4.google.com, inbox.google.com, android.clients.google.com), fully bypassing a TSG Deny policy as of July 2024 for messaging/file transfer (voice/video still failed).

A dedicated, actively-maintained TSG_OLAP Flink streaming job (galaxy/tsg_olap/sip-rtp-correlation, 200+ commits through late 2024) fuses one-way SIP signaling records with their corresponding RTP media-stream records into unified bidirectional VoIP call records in real time, keyed by address/session state with configurable expiry -- a production system for reconstructing complete VoIP call metadata (parties, duration/state) from separately-captured signaling and media flows.

At least 67 files in this batch (31 "SNI Report of Overseas APP" + 36 "Server IP and Location of Overseas APP") are automated weekly TSG reports, generated 2023-01 through 2024-03, each processing hundreds of billions to over a trillion log rows and breaking down PB-scale traffic (peaks over 500 Gbps observed) by SNI/domain for ~20-30 named foreign platforms per report (Netflix, YouTube, Facebook, Google, Twitter/X, Instagram, Telegram, WhatsApp, Viber, Signal-adjacent messaging apps, Snapchat, Reddit, Quora, Pinterest, Tinder, Uber, Wikipedia, Zoom, HBO, Gmail, Line, Messenger, etc.), confirming a continuously-operated, nation-scale SNI-based traffic categorization and server-IP/geolocation pipeline for foreign services, not a one-off capability.

For a domestic Fujian deployment, Geedge validated SNI-wildcard blocking (*.sohucs.com, *.sns.sohu.com) as technically effective against a specific Chinese social app ('Huyou'), but rejected it for production because the domain is shared with a third-party SDK platform and would cause false-positive blocking of unrelated services -- falling back to destination server-IP blocking, deployed inline via TCP RST injection.

"stellar-on-sapp" (232 commits) is a plugin/decoder SDK running on top of sapp, providing session/packet management (pub-sub message queue, per-session exdata) for protocol decoder plugins including HTTP, DNS, and GTP tunnel (mobile-carrier) decoding, plus explicit "Layer-7 proxy filtering" support. A separate FTP decoder plugin (stellar/ftp_decoder) built against the same sapp/stellar SDK confirms the plugin architecture covers additional protocols beyond HTTP/DNS/GTP.

TSG's galaxy-data-platform business-API module models 'SubscriberId' as a first-class entity in an ArangoDB knowledge graph (SubscriberIdPath.java, SubscriberIdProviderImpl.java), sitting alongside dedicated FQDN and IP path providers (FqdnProviderImpl, IpProviderImpl) in the same query strategy interface. A separate, actively-maintained Flink topology (radius-account-knowledge) ingests carrier RADIUS accounting records per-VSYS (multi-tenant) dimension to populate this graph, giving analysts a queryable link between a subscriber identity and the IPs/domains it touched.

swarmkv is an internally-built, CRDT-based distributed key-value store (Redis-like, with Bloom filter, HyperLogLog, Count-Min Sketch, and token-bucket data types) referenced directly by TSG ticket numbers (TSG-20539, TSG-21840, TSG-15595) for its Committed-Information-Rate/Committed-Burst-Size (CIR/CBS) token-bucket throttling — the distributed state layer backing TSG's cluster-wide rate-limit/throttling policy actions.

A MESA lab monthly report describes coordinating TSG installation/deployment and a traffic-replay test environment (capture/parse/match module testing) for a project codenamed "TF", alongside separately deploying a "主动防御" (active defense) program from an internal git repo with distinct "flooding" and "reflection" modules that were functionally tested.

A June 2023 MESA engineering report on "TF项目" ("project TF") documents TSG configuration changes alongside CM and OLAP components, and explicitly records resolving a "hijack-injection function" (劫持注入功能) interface issue where policy was not taking effect, followed by completed hijack-effect verification and active-defense (主动防御) effect verification -- naming two further internal tools, netflood and houyi, used alongside sapp for packet injection, plus a git.mesalab.cn/active-defense repository.

The tango/tfe-kmod repo is a DKMS Linux kernel module that reconstructs live TCP connections from out-of-band control messages (CMSG), using the TCP_REPAIR_WINDOW socket option to set window state without a handshake and adding special-case handling for protocols such as SSH where the server sends the first packet -- kernel-level infrastructure letting a userspace process ("TFE") transparently take over or inject into an in-progress TCP flow.

TSG's SSL decoder could not parse TLCP (China's national TLS variant) SNI as of v24.02, classifying such flows as generic BASE traffic and defeating server-name blocking; TLCP parsing was added in v24.08/24.09 per a tracked MESA_Platform/ssl commit.

chongming/traffic_replay is a Flask/tcpreplay-based QA harness that replays curated pcaps against a TSG instance to exercise its decoders, including SSL fixtures specifically named ssl_ech_false.pcap, ssl_no_sni.pcap and ssl_tls13.pcap alongside esni.pcap, openvpn.pcap, and major-platform captures (facebook/google/twitter/ youtube). A companion update_tsg_ca.py/tsg_ca.txt installs a TSG-issued CA cert on the test client, confirming the QA environment exercises TLS interception as part of routine detection testing.

A SQL migration renaming TSG's audit-log 'op_target_type' enum from human-readable admin-UI labels to API slugs exposes the full first-class feature list of the TSG management console, including 'Insert_Script'->insert_script and 'Hijack_File'->hijack_file (content-injection features distinct from the previously-documented cert-implant side), alongside 'Decryption_Keyrings'->ssl_keyrings, 'Trusted_Certificate_Authorities'->trusted_ca_cert, 'Response_Page'->response_page, 'Cached_Intermediate_Certificates'->exch_intermedia_cert, and 'HSM'->hsm, corroborating and extending the certstore/content-injection capability descriptions with concrete named UI object types.

Internal TSG project chat logs show engineers tasked with determining how many distinct clients sit behind a single client IP for the TSG project, starting with User-Agent field analysis and researching offline WHOIS/domain-registration databases as a supplementary signal -- i.e., detecting shared-connection/NAT'd usage (including likely VPN gateways) is an explicit TSG feature requirement.

TSG's proxy-manipulation policies go well beyond blocking: confirmed live capabilities include Redirect, Insert, Hijack, and Replace actions, demonstrated live-testing JavaScript injection into an intercepted HTTPS response (Bilibili/Baidu search-box word substitution via injected event listeners) and Request-Body content replacement against Google/YouTube's live API traffic (youtubei/v1/search), both requiring full TLS interception of major-platform HTTPS traffic.

TSG ships a built-in periodic-report feature ("Tiangou Secure Gateway" branded PDF exports) that breaks down traffic per major global platform — observed for YouTube, Facebook, Instagram, Netflix, Snapchat, BBC, and Bigo across six independent report exports — via "SNI Report of Overseas APP" and "Server IP and Location of Overseas APP" tables, giving operators granular, per-platform SNI- and IP-geolocation-based usage visibility as a standard dashboard capability, not just blocking.

A MESA Lab monthly report describes functional testing of a "TSG DoH proxy" (TSG DoH代理) covering availability, HTTP version support, server-side behavior, and HTTP header fields, with results posted to the internal Confluence wiki (docs.mesalab.cn), under a project labeled XDC. The same reporting period covers a separate autoencoder-based DoH-traffic-detection paper with an "improved active-verification method" for discovering additional DoH resolvers.

A MESA Lab experiment re-identifies individual users across time solely from which domains they visit, using one-hot/frequency "domain access vectors" (Jaccard, overlap-coefficient, cosine, Euclidean) computed against real production HTTP logs pulled from a ClickHouse table named tsg_galaxy_v3.connection_record_log_http_domain. The best-performing configuration (Alexa top 100-10000 domain list, overlap coefficient) distinguished the same user's adjacent-hour sessions from other users' sessions with high separation (~0.19 vs ~0.88 average difference).

A ClickHouse SQL query against table tsg_galaxy_v3.session_record_local implements a heuristic for flagging likely proxy/circumvention-tool usage: within 5-second windows, it flags any client IP that connects to 30+ distinct server IPs on high ports (>=10000) with small, tightly-bounded packet counts (6-15 sent, 4-15 received) where the session's application-layer protocol is unclassified (app_transition = 'unknown'). "tsg_galaxy_v3" indicates a named TSG data-warehouse/analytics layer distinct from the sapp/maat real-time inspection path.

The official TSG Administrator's Guide (customer-facing LaTeX source in tsg-manual/tsg-admin-guide, versioned releases through 2021) contains a dedicated 'Decryption' chapter and ships an 'AppSketch_Model' architecture diagram alongside chapters on Policies, Objects, and Monitoring -- confirming TLS interception and AppSketch-based app identification are documented, customer-configurable features of the exported TSG product rather than undisclosed internal-only capabilities.

A TSG MIB Specification (SNMP, registered enterprise OID 1.3.6.1.4.1.54450) documents the TSG chassis as four CPU sleds ('MCN') plus one switch sled ('MXN') monitored via IPMI for temperature/voltage/fan health, and a companion install manual names the specific model 'TSG-7400' using an ONIE-based boot/installation flow -- concrete hardware architecture detail for the exported gateway product.

A "TSG系统安装手册" (TSG System Installation Manual, dated 2021-05-28) documents clustered install architecture with three named components (OLAP, CM, ADC) deployed via Ansible + Docker on CentOS 7.4 nodes (24+ cores, 32GB+ RAM, 2TB disk each); a separate "Installation" manual documents bare-metal TSG-OS install/upgrade via ONIE (Open Network Install Environment), confirming TSG-OS ships on white-box networking hardware rather than a proprietary appliance image.

Four separate TSG "Server IP and Location of Overseas APP" reports (Instagram/Facebook CDN traffic) list Kazakhstan locations (Almaty, Pavlodar) as significant contributors to top-50-by-bytes tables alongside US/France/Hong Kong entries, consistent with a TSG vantage point that has substantial visibility into Kazakhstan-bound consumer traffic — corroborating the corpus's existing K18 (Kazakhstan) site attribution with independent network-traffic evidence.

Two independently-leaked TSG session-log CSV exports share an identical 224-field schema whose proxy_* columns (proxy_action, proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_intercept_error) log the outcome of TLS interception per session, alongside ssl_ja3_hash/ssl_ja3s_hash, ssl_esni_flag, ssl_ech_flag, and quic_sni fields — confirming MITM/cert-pinning-bypass instrumentation and TLS/QUIC fingerprinting are built into TSG's standard traffic-logging pipeline, not a bolt-on feature.

The same TSG session-log schema carries subscriber_id, imei, imsi, apn, and phone_number as first-class columns on every logged network session (alongside client/server IP, app-ID, and full HTTP/mail/DNS/TLS detail), meaning subscriber-identity correlation is a built-in field of TSG's default traffic log, not a separate add-on module.

TSG ships a Lua-scripting DPI extension module (pxz/tsg_lua_module, shared library "elua") whose example/test suite includes scripts that extract WeChat account IDs and QQ numbers from captured traffic (handle_weixinnum.cpp, handle_qqnum.lua) alongside a generic protocol_recognition.lua script, indicating the DPI pipeline supports custom, scriptable extraction of IM account identifiers from live traffic, not just protocol/app classification.

A recurring TSG dashboard panel titled "各省份流量速率" (per-province traffic rate) breaks domestic traffic down by Chinese province; across these four report exports alone the provinces named include Xinjiang, Shaanxi, Shandong, Jiangsu, Anhui, Henan, Guangdong, Gansu, Zhejiang, Fujian, Ningxia, Qinghai, Hebei, Shanxi, Beijing, Hubei, Hunan, Chongqing, Sichuan, Nei Mongol, Jilin, Heilongjiang, and Liaoning — a far wider domestic footprint than the three provinces (Xinjiang, Jiangsu, Fujian) previously documented in this corpus's taxonomy notes.

The "TSG OAM CLI User Guide" describes TSG hardware as a chassis of "four CPU sleds (MCN) and one switch sled (MXN)"; the OAM CLI runs on the switch sled and dispatches jobs to per-blade CLI agents on each MCN sled via a named internal management API called "Bifang API" for policy-related information -- a previously undocumented internal component name.

The "TSG OAM CLI User Guide" describes TSG's physical hardware architecture as four CPU sleds (MCN) plus one switch sled (MXN) per chassis, with CLI commands issued on the MXN sled and dispatched to each MCN sled via a per-sled CLI agent, running on top of CentOS — a concrete confirmation of TSG's modular blade-chassis hardware design and OAM access model.

TSG ships a dedicated 'OAM' (Operations, Administration and Management) subsystem with its own versioned install/deploy guide (v0.6, changelog entries since 2020-01-15) and CLI user guide (v0.83); a package install command confirms the runtime path '/opt/tsg/sapp/' and package naming 'tsg-traffic-engine-vsys-1', extending the sapp/Kubernetes deployment details already established in the taxonomy with the specific RPM packaging and OAM management-plane details.

The galaxy/deployment/tsg-olap-data-initialization repo defines TSG's production big-data backend (ClickHouse/Druid/HBase/Kafka via "groot-stream" ETL) and includes a named multi-datacenter pipeline "pxy_exch_intermedia_cert_kafka_to_ndc_kafka" that streams proxy-exchange intermediate (MITM) certificates from a site datacenter to a "national datacenter" (ndc) Kafka cluster, alongside session/transaction/VOIP record and DOS-event pipelines with per-site vs. national-datacenter topology.

A TSG-Application blocklist test found that disabling Facebook/Twitter in TSG's per-app policy did not stop Psiphon3 traffic from reaching those services in practice, because Psiphon3's dual-stack fallback drove the tunneled Facebook traffic over IPv4 QUIC, which TSG's classifier failed to attribute to Facebook -- in contrast to Taobao/Bilibili/Youku/JD, which TSG blocked successfully in the same test.

The tango/tsg-service-chaining-engine (SCE) repo implements TSG's traffic-steering core: it VXLAN-encapsulates and routes both "raw" and "decrypted" copies of a session (four tracked metadata directions) through a chain of up to 32 third-party "Service Functions", with explicit per-flow actions of block, bypass, forward, and rx_drop for both mirrored and inline-steered traffic, coordinating with SAPP, mrzcpd (packet capture/re-injection), and MAAT4 (rule engine) via control-plane messages.

A leaked TSG session-log CSV schema (device XXG-TSG-BJ) includes built-in per-session fields for TLS interception status (proxy_intercept_status, proxy_cert_verify, proxy_pinning_status, proxy_passthrough_reason) alongside JA3/JA3S TLS fingerprints and explicit ssl_esni_flag/ssl_ech_flag columns, confirming TSG logs whether a session was MITM'd and whether it used ECH/ESNI.

The same TSG session-log schema includes per-session subscriber-identity fields (subscriber_id, imei, imsi, phone_number, apn) plus cleartext-credential-capture fields (mail_password, ftp_account) and full HTTP request/response body columns, confirming the platform is built to tie flagged traffic directly to a subscriber's phone number/IMSI and to capture credentials/content, not just classify protocols.

The full TSG session-log CSV schema header discloses the complete set of per-session fields the platform records, including TLS JA3/JA3S fingerprint hashes, explicit ssl_esni_flag/ssl_ech_flag columns, QUIC/DTLS SNI and JA3 fields, and direct subscriber-identity fields (subscriber_id, imei, imsi, apn, phone_number) captured on every logged session alongside ordinary network 5-tuple data.

Dozens of weekly "Tiangou Secure Gateway" auto-generated reports ("SNI Report of Overseas APP" / "Server IP and Location of Overseas APP") in this batch break out per-application SNI and server-IP/geolocation tables for Facebook, YouTube, Twitter, Instagram, Telegram, WhatsApp, Viber, Snapchat, Signal-adjacent messaging apps, and others, at up to 828 TB/week and 12+ Tbps peak processed traffic -- direct operational evidence of continuous, automated, per-app SNI-based classification of outbound "overseas app" traffic at production scale.

TSG runs a recurring, fully-automated weekly analytics job -- literally titled 'Tiangou Secure Gateway SNI Report of Overseas APP' and a companion 'Tiangou Secure Gateway Server IP and Location of Overseas APP' report -- that processes roughly 300 billion to 10 trillion traffic rows per week and produces per-platform SNI and server-IP/location breakdowns (Top10/Top50) for YouTube, Facebook, Google, Twitter, Instagram, Telegram, WhatsApp, Viber, Line, Messenger, Snapchat, Gmail, HBO, Netflix, Discord, BBC, Bigo, ESPN, and Hulu, plus a dedicated Top-100 SNI table for QUIC-protocol traffic.

A DerScanner SAST report on 'source-code.zip' (322K lines, Dec 2020) reveals internal package/module names for TSG's control-plane codebase: a Java web console under cn.nis.ntc ('bifang-api', modules ntc-admin/ntc-api/ntc-service handling TsgIpLocationService/TsgProfileDecryptionController policy objects), a Storm+HBase log-processing pipeline under cn.ac.iie.storm (tying the codebase to CAS's Institute of Information Engineering), and a nezha_code/nz-confagent module -- the first direct source-level map of how TSG's web console, the Nezha monitoring agent, and the big-data log pipeline relate as one codebase.

An internal field-mapping schema for TLS/SSL session logging (cross-referenced against multiple internal system versions, one explicitly labeled "tsg") shows JA3 and JA3S TLS ClientHello/ServerHello fingerprint hashes are captured as standard logged fields alongside SNI, negotiated cipher suites, and the full server and mutual-TLS client certificate chains (issuer, subject, serial, validity window, raw public key).

tsg-ui/demo is a TSG v3.0 "Security Policy" UI prototype (logo file literally named "TIANGOU logo", confirming TSG's Tiangou naming origin) whose page inventory enumerates the product's full policy-object model: certificate management (keyrings, SSL-decryption exclusion, trusted CA authorities), policy objects including keyword (kw) and subscriber-ID (sid) categories and a "proxy manipulation policy" object, and per-profile "Hijack Files", "Insert Scripts", "Response Pages", and "Traffic Mirror Profiles / decrypted-traffic-forwarding" configuration screens.

A MESA lab engineer's monthly report lists "TSG project: webroot library-table label mapping" as completed work, indicating TSG maintains a "webroot" reputation/category database with an active label-mapping process as part of its classification pipeline.

The TSG-9140 hardware repo documents supporting infrastructure: a Network Packet Broker (NPB, jut_shm) for traffic mirroring/distribution, NEZHA monitoring dashboards, and an OEO6500-OLP-TBP optical-line-protection/bypass device — the last ensuring inline link continuity if the TSG-9140 DPI node fails, a resilience feature specific to inline (not mirror) deployments.

Geedge's production inline-deployment container bundle (tango/tsg_container) wires mrzcpd (capture/inject), sapp (DPI via maat rules), and a third component "tfe" (traffic-forwarding engine) together via Docker Compose; tfe ships a dedicated doh.conf (DNS-over-HTTPS handling) and the firewall-mode container's sapp config includes a send_raw_pkt.conf, a KNI (kernel network interface) config, an "asymmetric_presence_layer.conf" for mirror/asymmetric-routing deployments, and a "pangu" proxy module (pangu_pxy.conf / pangu_http.json).

The tsg/tsg-deploy repo (2019-2020) shows TSG's full commercial deployment stack: a "bifang" API service deployed via Docker, a packaged TSG-web v2.01 Pro frontend, and bundled infrastructure components (Consul, Minio, Grafana, InfluxDB, MariaDB, Redis, JDK 1.8) for on-prem/offline installs — giving a concrete picture of the commercial appliance's supporting architecture beyond the DPI engine itself.

TSG's self-diagnostic suite (tsg/tsg-diagnose) imports the full badssl.com test-certificate corpus (superfish, eDellRoot, mitm-software, captive-portal, revoked, weak-key variants, etc.) to continuously validate its own TLS-interception logic in production, adds test cases for TLS ClientHello fragmentation handling by the intercept engine, and documents that firewall DENY blocking was changed from sending only a FIN to sending FIN-then-RST to close connections.

TSG's own policy API documentation (tsg/tsg-doc) defines dedicated database/API objects for live content manipulation: a content-hijack policy-file table (内容劫持策略文件) with a contentName field, and an injected-script policy-file table (注入脚本) with an insertOn (injection point) field, alongside a block-page (访问阻断页面) policy-file type — confirming content injection and block-page replacement are first-class, documented TSG policy actions.

The same TSG API/DB documentation shows subscriber-identity fields (TSG_DYN_SUBSCRIBER_IP table, RADIUS attribute support added 2019-11-08) are built into TSG's core security-policy schema itself, not only into the separate CyberNarrator add-on — session-to-subscriber correlation is a base-platform capability at any TSG deployment, carrier-RADIUS-integrated or not.

A TSG OAM (Operations & Maintenance) install guide v0.4 (2020) documents sub-components OAM_CORE, OAM_CLI, OAM_CLI_Agent, OAM_SNMP, and OAM_Cluster deployed across MXN/MCN/OAM-Cluster-Server tiers, backed by MariaDB and InfluxDB, and includes a hardcoded default datasource password (`tsg2019`) in cleartext in the operational documentation itself.

TSG's field operations-and-maintenance toolkit (lijia/tsg_oam) runs certstore, kni, tfe, and tsgenv each as independent systemd services on TSG appliances, and includes a dedicated tsg_monit_intercept.py monitoring script alongside per-protocol monitors (tsg_monit_protocol_v3.py/v4.py) and a marsio-based traffic reader (get_traffic_by_marsio.py) -- showing the certstore/interception subsystem is treated as its own independently-monitored production service rather than an incidental sapp sub-feature.

A Storm-based OLAP pipeline (galaxy/tsg_olap/storm/log-address-hbase) includes a dedicated "SubscriberIdBolt"/"SubcribeIdBolt" topology stage that writes RADIUS session data into HBase, alongside a subscriber-config.properties file. This is distinct infrastructure evidence (2018-2021) that TSG's big-data/OLAP layer, not just the CyberNarrator subsystem, ingests and persists RADIUS-derived subscriber identity data at scale.

The 'galaxy/tsg_olap/tsg-complement' repository implements two custom Flume interceptors -- FlumeRadiusOnOffInterceptor and FlumeSubscriberInterceptor -- that write RADIUS session on/off events and subscriber data into HBase, confirming a dedicated pipeline for correlating network sessions to RADIUS-derived subscriber identity within the TSG/Galaxy analytics stack.

TSG's Ansible deployment platform ('tsg/tsg-scripts-platform') installs per-protocol firewall RPM modules -- dedicated dns, ftp, http, mail, quic, and ssl packages -- alongside the sapp DPI engine and mrzcpd packet-mirror/inject agent, confirming TSG ships a purpose-built QUIC/HTTP3 blocking module as a first-class protocol-firewall component.

TSG's policy-API test suite (zhaokun/tsg_policy_api, 508 commits) enumerates the full deny-action taxonomy exercised against combinations of IP/SNI/APP/flag match conditions and negation: deny_alert (HTTP 200 with profile or text body), deny_block (403/404 with profile or text), deny_drop, deny_noreset, deny_redirect (DNS with 1-3 forged answers), and deny_rate_limit (high/low), plus "allow" and "shunt" (traffic-diversion) actions — a precise map of TSG's blocking/throttling/redirect action space.

The tsg-scripts Ansible deployment repo (git.mesalab.cn:tsg/tsg-scripts) contains dedicated per-city deploy configs for well over a dozen Kazakhstan locations (Astana/Nur-Sultan, Almaty, Karaganda, Zhezkazgan, Aktau, Shymkent, Petropavl, Pavlodar, Semey, Taraz, Kostanay, Taldykorgan, Uralsk, Kokshetau, Ust-Kamenogorsk, Aktobe/Aktubinsk, Kyzylorda), consistent with and substantially extending the K18 Kazakhstan site codename. A single 2020-10-24 commit was authored directly from a '[email protected]' account 'at K18-2 Control Center', concretely tying CEIEC (China National Electronics Import & Export Corp) to on-site K18/Kazakhstan deployment access.

The same TSG QA suite includes purpose-built "hijack" test fixtures for at least seven content types (APK, EXE, GIF, HTML, JPEG, PNG, SVG) alongside JS/CSS insertion scripts and Lua replace/insert manipulation scripts, and its UI/API test cases reference a "Manipulation" policy object with replace/hijack/deny(drop) actions triggered by "Keywords" objects inside "http_signature" matching and an explicit "no_sni" traffic-matching condition; separate pcap test fixtures (esni.pcap, ssl_ech_false.pcap, ssl_no_sni.pcap, ssl_tls13.pcap) show this is specifically regression-tested against ESNI/ECH and SNI-less TLS 1.3 traffic.

Geedge's TSG QA automation suite (chongming/tsg_test) ships dedicated certstore test fixtures -- a full "trust" and "untrust" CA chain (tango_ca_v3_trust_ca / tango_ca_v3_untrust_ca certs and keys) plus multi-level intermediate/root test certificate chains -- used to validate TLS-interception (certstore) behavior end-to-end as part of routine regression testing.

TSG-X's NEZHA monitoring-dashboard repo (tango/tsgx_hardware) shows certstore-specific dashboard charts being added ("Add certstore charts") and, three weeks later, the dashboard-template set updated explicitly sourced from the M22 (Myanmar) deployment ("sync chart from m22"), confirming certstore (TLS-interception) has its own operational monitoring and that NEZHA dashboard templates are shared from the Myanmar site into the general TSG-X product line.

TSG's security-policy verification engine (tango/verify-policy) supports 'ssl.no_sni', 'ssl.ech' (Encrypted ClientHello), and 'ssl.esni' (Encrypted SNI) as first-class Boolean match conditions in its policy language (TSG-18943), meaning TSG can write and evaluate blocking/monitoring policies that specifically trigger on TLS connections carrying no SNI, ECH, or ESNI.

TSG's policy-verification engine added IMEI as a scannable/matchable attribute (TSG-17514), alongside its existing CallingStationID and ASN/geolocation match conditions -- confirming device-identity (IMEI) correlation is a formal, policy-actionable input in TSG's security-policy engine rather than an ad-hoc export-specific add-on.

TSG formally distinguishes a 'Proxy-Intercept' policy action type from generic security policy (TSG-14954/14955, later merging their underlying MAAT rule-engine handles) and layers service-chaining/traffic-shaping actions with a defined priority order (Shunt > Allow(monitor) > Deny(monitor)) -- confirming TLS/traffic interception (MITM) is a named, first-class policy category in TSG rather than an implicit side effect of blocking rules.

The galaxy/tsg_olap/log-stream-voip-relation repo is a Flink/Kafka streaming job (VoIpRelationTopology) that correlates SIP signaling flows with their corresponding RTP media flows across VSYS (virtual-system) boundaries, reconstructing complete VoIP call sessions from separately-observed signaling and media traffic.

Geedge runs an ongoing, weekly-cadence feature-extraction and blocking program against a customer-curated list of at least 282 named commercial VPN/circumvention apps (including Fly VPN, Secure VPN, NotVPN, letsVPN, VPN Hero, BeastVPN, Cafe VPN, Blockless VPN, BlackVPN, FinchVPN, Cisco Secure Client/ocserv, DelightVPN, NordVPN), plus separate systematic testing of 400+ non-VPN apps. The methodology extracts destination server-IP lists (hundreds to thousands of IPs per app) and app-specific FQDNs, tests each in staging for false positives before deploying, and for at least one target stood up their own clone of the target VPN server software to capture and analyze its real protocol handshake.

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).

Session-log exports from a Beijing test/demo TSG device ("XXG-TSG-BJ") show live "Deny" enforcement actions (security_rule_list "Deny_VPNHero", "deny_TowerVPN") against traffic the app-ID engine classified with nested app chains "VPNHero" and "OPENVPN.TowerVPN.Psiphon Provider.Psiphon-Server" -- i.e. TowerVPN is specifically tagged internally as riding on Psiphon infrastructure, and both it and VPNHero are actively blocked, not just logged, on this device.

The tsg/wannat-ansible-deploy repo bundles a "wannat_natgw" NAT gateway role together with OpenVPN-server and PPTPD-server Ansible roles, both integrated with FreeRADIUS (radius_server/radius_client roles, radiusplugin.so for OpenVPN), as part of the standard TSG deployment stack (synced to "TSG v21.09" releases, tracked under TSG-8xxx tickets). Whether this VPN-terminating gateway exists for TSG field-engineer remote access or for a VPN-interception use case is not established from this metadata alone.

A URL/domain-classification service (yinjiangyi/webskt-query-agent) integrates the third-party BrightCloud (Webroot) URL-categorization API (BrightCloudUtils.java, brightcloud.properties, map_clf2brightcloud.csv) alongside its own reputation/whois lookups, suggesting TSG's category-based content policies (e.g. block-by-category) are informed by a licensed external URL-reputation database rather than purely in-house classification.

An internal methodology memo for the '新疆省口项目' (Xinjiang provincial-gateway project) and '联通IDC项目' (Unicom IDC project) states both rely on 现有的系统（TSG与CN） (the existing TSG and CN [CyberNarrator] systems) to Block/Monitor/identify mainstream apps, and describes a largely manual signature-engineering workflow -- download the target app, capture traffic with 科莱(Colasoft Capsa)/Wireshark, extract fingerprint fields (http.host, http.user_agent, quic.sni, ssl.handshake.extensions_server_name) by hand, and register a per-app signature -- extending CyberNarrator's documented role beyond Psiphon-IP-harvesting/Pakistan subscriber correlation into general domestic app-blocking alongside TSG.

TSG produces recurring monthly per-application traffic breakdown reports for a Xinjiang deployment, splitting generic protocol buckets (bmff/http2/mpegts) down to specific apps (Kuaishou, Douyin, JD, Vivo services), delivered to the customer.

A weekly '新疆联通流量分析报告' (Xinjiang Unicom Traffic Analysis Report), one of a recurring carrier-specific series also produced for Xinjiang Mobile, shows the same TSG 'overseas APP' server-IP-and-location tracking (BBC, Bigo, Canvas, Discord, ESPN, Facebook, Gmail, etc.) plus domestic APP rankings and QUIC-domain rankings, produced specifically at the China Unicom carrier level within Xinjiang -- direct evidence that TSG's national-scale overseas-app monitoring capability is also deployed and reported at individual-carrier granularity in a specific, named domestic region under heavy surveillance.

Recurring weekly '新疆移动流量分析报告' / '新疆联通流量分析报告' (Xinjiang Mobile / Xinjiang Unicom traffic analysis reports) document a domestic monitoring deployment covering China Mobile Xinjiang (total capacity 4.4Tbps, ~1Tbps actively monitored, observed peak 1275.49Gbps) and China Unicom Xinjiang, breaking traffic into intra-Xinjiang, domestic, and overseas flows and reproducing the same per-foreign-platform (YouTube/Google/Facebook/Twitter/Instagram/Telegram/WhatsApp/etc.) server-IP breakdown used in the national TSG SNI reports, at a carrier-and-province-specific granularity.

Weekly "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report) documents, produced by an internal "运营商前端分析团队" (Carrier Frontend Analysis Team) and spanning January-July 2023, give carrier-level domestic deployment scale for Xinjiang: China Mobile Xinjiang alone reports 4.4 Tbps total bandwidth / 1 Tbps access bandwidth, with weekly throughput up to 22.73 PB and rate peaks over 580 Gbps. Both reports include a dedicated "国外APP应用概况" (foreign app overview) section enumerating server IP/location for ~29 named foreign platforms (BBC, Discord, Facebook, Gmail, Google, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Whatsapp, Youtube, Zoom, etc.) alongside domestic app traffic, directly corroborating the taxonomy's Xinjiang domestic-deployment note at the level of two named carriers with concrete recurring cadence.

Weekly '运营商前端分析团队' (carrier frontend analysis team) reports for Xinjiang Mobile (4.4 Tbps total bandwidth, 1 Tbps access bandwidth, 28.86 PB/week throughput) and Xinjiang Unicom (1.88 Tbps total, 880 Gbps access, 12.88 PB/week) break out domestic-vs-cross-border traffic ratios (e.g. Xinjiang-internal-to-overseas traffic 0.83 PB / 2.88% of total for Mobile) and rank the same roughly 30 international platforms (Facebook, YouTube, Telegram, WhatsApp, etc.) seen in TSG's app-classification reports, confirming named carrier-level, multi-Tbps domestic deployments in Xinjiang that specifically distinguish cross-border flows.

Weekly "XX联通/移动流量分析报告" (Xinjiang Unicom / Xinjiang Mobile Traffic Analysis Reports) explicitly name the carrier and report total provisioned bandwidth (Unicom 1.88 Tbps total / 880 Gbps access; Mobile 4.4 Tbps total / 1 Tbps access) with weekly throughput up to 44.26 PB and domestic vs. cross-border traffic ratios broken out per day, confirming Xinjiang-wide, carrier-level DPI deployment at multi-terabit scale across both major carriers.

A dedicated log-ETL pipeline repository named 'xj-log-etl' ('xj' = Xinjiang, per the taxonomy's domestic-deployment notes) lives under the TSG/Galaxy OLAP namespace, indicating a Xinjiang-specific instance of TSG's big-data log-processing pipeline distinct from the generic platform code, corroborating a named domestic (China) TSG deployment location.

A dial-testing ('拨测') log documents systematic active-probing/reachability testing from a 'YGN-GTG' (Yangon Gateway, Myanmar) network node against six overseas test sites in Singapore, France, the US, New Zealand, South Africa, and Chile, using packet capture plus flow statistics to quantify one-way vs two-way flow completion (0-45%% flow loss observed per site) through gateway node IPs 'YGN-GTG: 10.173.12.x' -- direct empirical evidence of connectivity/blocking-effectiveness QA testing tied to the Myanmar (M22) Yangon deployment, run against an 'NCSC'-provided 'Campana' test WiFi network.