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.
UI/links/profile-...-hiject-files挟持文件.html (Hijack Files), UI/links/profile-...-insert-scripts-注入脚本.html (Insert Scripts), UI/links/profile-...-traffic-mirror-profiles解密流量转发.html (decrypted traffic forwarding), UI/links/policyobject-...-sid类别-编辑.html (SID category), UI/links/certificate-management-证书管理-trusted-certificate-authorities信任证书颁发机构....html
Defense implications
- The product models a 'Traffic Mirror Profile' that forwards decrypted (post-MITM) traffic elsewhere, matching the pxy_exch_intermedia_cert_kafka_to_ndc_kafka pipeline seen in the TSG-OLAP repo — decrypted plaintext from intercepted TLS sessions is designed to be exported out of the inspection point itself, not just consumed in place.
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.
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 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.
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.
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.
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.