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.
c98f442d|2019-06-18|1.修改将SNI写入签发的实体证书的SNA 2.修改certstreo打包脚步 ; d581a972|2024-10-16|TSG-22708 Adapt to the change in the DECRYPTION_KEYRING table name ; 1511bb1a|2019-12-30|支持签发证书公钥ECC椭圆加密算发 支持椭圆曲线secp192r1、secp256r1 ; 0cd8b50b|2022-11-11|TSG-12599 certstore适配非可信证书读取keyring_id (tango/certstore.bundle)
Defense implications
- certstore mints per-connection leaf certificates keyed off the client's plaintext SNI in real time -- any circumvention transport that presents SNI inside a TLS-like handshake is directly interceptable by this exact mechanism. Prioritize ECH/ESNI or transports that don't expose a plaintext SNI-equivalent.
Related findings
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.
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.
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 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.
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.
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.