Multi-engineer forensic investigation (pcap, JA3 hashing, TSG session-log correlation) at an Ethiopia site into tv.cctv.com being intermittently unreachable concluded the blocking was NOT done by TSG itself but by a separate, more-client-proximate network censorship system. That system dropped ClientHello-stage TLS1.2 sessions matching cctv.com's SNI, had degraded filtering ability once the client renegotiated to TLS1.3, and at one point misclassified cctv.com traffic as TikTok.
结论：tv.cctv.com的访问，存在被其他(除TSG之外的)网络审计系统丢弃的情况... 推测该系统对TLS1.3的过滤能力不佳... [2023-05-15] 郑超: cctv.com被误识别为tiktok
Defense implications
- Evidence of a separate, non-Geedge censorship layer co-located in at least one TSG deployment's network path. Its TLS1.3 handling was weaker than its TLS1.2 handling at the time of this ticket (2023), and its classifier produced at least one confirmed false-positive SNI/JA3 collision -- worth independently verifying rather than assuming it generalizes or persists.
Related findings
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.
An internal risk memo, "Signal审查规避模式阻断风险说明" (Signal circumvention-mode blocking risk explanation), documents that after the operator pushed a "Deny Signal APP" policy, users with Signal's censorship-circumvention (domain fronting via Google infrastructure) enabled could still send messages/files; packet capture showed the fronted traffic used Google SNIs (clients3/4.google.com, inbox.google.com, android.clients.google.com, www.google.com), and the team built a targeted FQDN+JA3+payload signature specifically to block this fronted traffic while flagging a residual risk of false-positive blocking of legitimate Google services.
TSG's blocking of YouTube/Facebook/Twitter/Tencent at Ethiopia's IGW nodes fails for a large fraction of sessions because those sessions structurally never traverse the inspection point — quantified per-site traffic-completeness rates ranged from 0% to 40% (vs. ~100% completeness at the upstream PE node), with roughly half of sampled YouTube/Facebook sessions missing entirely from IGW-side logs. Root cause was traffic-splitting/mirroring architecture, not a detection failure of the DPI engine itself.
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 raw production SSL/TLS session log from sapp's monitoring pipeline (timestamps dated 2021-08-23, client IPs in domestic Chinese carrier ranges) shows the per-connection logging schema includes dedicated fields for a captured certificate chain (INDIVIDUAL_CERT_FILE, MIDDLE_CERT_FILE, ROOT_CERT_FILE, CHAIN_CERT_FILE) and for any injected packet (INJECTED_PKT_FILE), alongside SNI and TLS version -- confirming sapp's live SNI-logging and MITM-cert-capture instrumentation was operating against real user traffic to services including huobi.com, steamcommunity.com, and dropbox.com.
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.