MESA Lab's "stellar" SSL/TLS decoder (ssl_decoder, packaged in test fixtures as "stellar-on-sapp") ships a dedicated regression test case captured against an Ethiopia (E21) target host, alongside TLS 1.3 ESNI, encrypted ClientHello (ECH), and TachyonVPN-client test pcaps, showing the decoder is validated both against E21-deployment-style traffic and emerging TLS privacy extensions.
File tree: test/case/e21/1-E21-target.com-196.188.136.150-151.101.2.187.443.pcap, test/case/e21/ssl_e21_target_result.json, test/case/ssl/2-ssl-v1.3-esni-192.168.50.38.52391-104.16.123.96.443.pcap, test/case/ssl/3-tls_ech.pcap, test/case/close_contains_payload/1-TachyonVPN-192.168.50.28.63669-18.163.185.193.443.pcap. Env packages: stellar-on-sapp-2.1.2.20b65ae-1.el8.x86_64.rpm
Defense implications
- Confirms Geedge is actively building/testing ESNI and encrypted-ClientHello (ECH) decode paths in production SSL decoding, so relying on ECH alone for SNI concealment against TSG should not be assumed safe long-term.
- A TachyonVPN-specific test case shows individual commercial VPN client traffic is a named regression-test target for the SSL decoder, not just generic TLS; expect similarly specific fingerprinting attempts against other VPN/circumvention clients' TLS behavior.
Cited artifacts
mesalab_git—stellar/ssl_decoder.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
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.
A raw TSG session-log export shows the full production log schema: per-flow fields include subscriber_id, imei, imsi, phone_number and apn alongside ssl_ja3_hash/ja3s_hash, ssl_esni_flag, ssl_ech_flag, quic_sni, dtls_ja3_fingerprint, and proxy_pinning_status/proxy_intercept_status/ proxy_cert_verify fields for the MITM proxy path. This confirms TSG's session logging natively joins network-flow identity to subscriber identity and captures TLS fingerprint/ESNI-ECH state and MITM-interception outcome in the same record.
The same SSL plugin added explicit detection of the Encrypted Client Hello extension (type 0xFE0D) with test cases in June 2023, and separately implements JA3/JA3S (2020) and JA4/JA4S (2024) TLS client/server fingerprint calculation as first-class features -- so TSG-class DPI can flag 'ECH is in use' even without decrypting it, and independently fingerprints TLS stacks via JA3/JA4.
TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).
A leaked SQL migration renames/normalizes a session-attribute-dictionary entry to `ssl.analysis.sni_absent` (backed by virtual_table `ATTR_SSL_NO_SNI`), confirming the detection pipeline maintains an explicit, first-class boolean signal for "TLS ClientHello with no SNI present" — a classic tell for ECH, domain fronting, and custom TLS stacks that omit SNI to evade SNI-based blocking.
Two independently-leaked TSG session-log CSV exports share an identical 224-field schema whose proxy_* columns (proxy_action, proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_intercept_error) log the outcome of TLS interception per session, alongside ssl_ja3_hash/ssl_ja3s_hash, ssl_esni_flag, ssl_ech_flag, and quic_sni fields — confirming MITM/cert-pinning-bypass instrumentation and TLS/QUIC fingerprinting are built into TSG's standard traffic-logging pipeline, not a bolt-on feature.