The "stellar" HTTP decoder plugin identifies HTTP CONNECT-method proxy tunnels (httpd_tunnel_identify) and, once a successful CONNECT response is observed, re-enters the payload as a nested HTTP stream (tracking tunnel_state transitions through session exdata) so that traffic carried inside an HTTP CONNECT tunnel continues to be parsed as HTTP rather than treated as opaque bytes — i.e. the DPI follows through simple HTTP-proxy tunneling rather than losing visibility at the CONNECT boundary.
if (httpd_tunnel_identify(httpd_env, FLOW_DIRECTION_C2S, half_data)) { exdata->tunnel_state = HTTP_TUN_C2S_HDR_START; http_decoder_stat_update(&httpd_env->hd_stat, thread_id, HTTPD_STAT_TUNNEL, 1); } if (httpd_is_tunnel_session(httpd_env, exdata)) { ... }
Defense implications
- A naive 'wrap circumvention traffic in an HTTP CONNECT tunnel and stop' design is not sufficient camouflage against this DPI class — it actively re-parses the tunneled content as HTTP looking for further structure, so any defense relying on CONNECT-tunneling for cover needs the inner traffic to also look like ordinary HTTP/TLS, not just be wrapped by a CONNECT request.
Cited artifacts
mesalab_git—stellar/http_decoder.bundle:src/http_decoder.cpp(source-code)mesalab_git—stellar/http_decoder.bundle:src/http_decoder_table.cpp(source-code)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
Internal engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core Xeon E5.
TSG runs two separate detection engines: a licensed third-party DPI engine for general app/protocol identification (requires per-environment authorization -- absent in a demo environment caused a detection gap), and a Geedge-built component ('glimpse_detector') specifically for VPN protocol identification (WireGuard, OpenVPN). App-ID numbering (e.g. built-in wireguard=3700) can be silently shadowed by environment-specific custom IDs, causing detection to fail even when the underlying protocol is correctly classified.
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's 'APP' classification feature has named, purpose-built signatures for specific circumvention tools — the ticket explicitly configures active-client-IP tracking for the APP categories Freegate, Psiphon3, and Tor.