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.
proxy_action String, proxy_pinning_status Nullable(Int32), proxy_intercept_status Nullable(Int32), proxy_passthrough_reason String, proxy_client_side_latency_ms Nullable(Int32), proxy_server_side_latency_ms Nullable(Int32), proxy_client_side_version String, proxy_server_side_version String, proxy_cert_verify Nullable(Int32), proxy_intercept_error String
Defense implications
- Any protocol relying on TLS to a real-looking backend should assume the operator logs, per session, whether certificate pinning was detected and whether interception succeeded, failed, or was passed through -- design for detecting on your own side when a handshake looks pinned-and-bypassed vs silently MITM'd, since the operator is clearly tracking and likely tuning against both outcomes.
Related findings
TSG's inline blocking capability (the kni role) is implemented as separate per-protocol plugins — fw_dns_plug, fw_ftp_plug, fw_http_plug, fw_mail_plug, fw_ssl_plug, fw_quic_plug, fw_voip_plug — while a distinct 'TFE' role handles forwarding of TLS traffic decrypted by certstore's MITM stage, per a 2019 commit adding 'TFE配置文件中关于解密流量转发的配置' (config for decrypted-traffic forwarding in the TFE config file); TFE's Ansible role explicitly requires mrzcpd (require-mrzcpd.conf.j2). TFE is not currently a named entry in the products taxonomy despite being a core, independently-versioned component (tfe-4.3.x rpm series) present in every TSG deployment in this repo.
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.
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.
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.
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.