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.
key_keeper_async_ask, CertStore query: http://192.168.40.161:9991/ca?keyring_id=1&sni=update.googleapis.com&is_valid=1 ... Received request for uri, kering_id:1, sni:services.gfe.nvidia.com, valid:1
Defense implications
- Assume any TSG-fronted network path can present a locally-trusted forged certificate for high-value domains (this log shows Google and Nvidia infrastructure specifically); certificate pinning / out-of-band cert verification is warranted rather than trusting the local root store on networks suspected to sit behind a TSG deployment.
- certstore's per-SNI keyring validity check (is_valid=0/1) suggests MITM targeting is selective by domain, not blanket — probing suspected TSG links by comparing served certs for a known-good domain vs. a plausibly-targeted one is a viable detection technique.
Related findings
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.
Session records log MITM-proxy decision fields per session -- proxy_action, proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_intercept_error, and proxy_passthrough_reason -- alongside security_rule_list/security_action and shaping_rule_list. This confirms, at the OLAP schema level, that TLS-interception outcomes (intercepted vs. passed through, including why -- e.g. detected certificate pinning) are retained per session, corroborating the certstore product's Trusted/Untrusted/Dynamic-Bypass model. Two adjacent columns, sc_rsp_raw/sc_rsp_decrypted, sit next to these but their exact semantics were not confirmed from schema alone.
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 name redacted, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.
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.
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.