Auto-ingest: 10 new papers (2026-10-26)

corpus/findings/2014-cao-survey-encrypted-traffic__dpi-fails-encryption-statistical-survives.yaml

@@ -0,0 +1,17 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2014-cao-survey-encrypted-traffic
+kind: detection
+summary: Standard DPI and port-based classification methods fail against encrypted traffic because payload bytes are opaque and applications increasingly use non-standard or randomized ports. The survey identifies statistical and behavioral flow-level analysis as the primary viable approaches for classifying encrypted traffic, as they operate on metadata observable without decryption.
+techniques:
+    - dpi
+    - port-blocking
+    - traffic-shape
+    - ml-classifier
+censors:
+    - generic
+defense_implications:
+    - Circumvention protocols must defeat not only DPI payload inspection but also flow-level statistical fingerprinting — packet sizes and inter-arrival times remain observable even under encryption.
+    - Protocol designers should randomize or normalize observable flow statistics (packet size distributions, inter-arrival times, flow duration) to resist ML classifiers that don't require payload access.
+section: Abstract / §2
+extracted_by: claude-sonnet-4-6

corpus/findings/2014-cao-survey-encrypted-traffic__host-behavioral-analysis-encrypted-service-classification.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2014-cao-survey-encrypted-traffic
+kind: detection
+summary: Behavioral and host-profiling approaches (BLINC, host-based P2P detection) enable fine-grained classification of encrypted traffic at the service level — distinguishing not just application type but specific traffic classes within an application — by correlating network communication patterns across hosts and time rather than inspecting individual flows.
+techniques:
+    - ml-classifier
+    - traffic-shape
+censors:
+    - generic
+defense_implications:
+    - 'Single-flow obfuscation is insufficient: censors can correlate a client''s entire communication pattern across connections and time, so circumvention tools should avoid persistent behavioral patterns such as fixed polling intervals or predictable connection establishment sequences.'
+    - Use of CDN or shared infrastructure distributes traffic among many legitimate users, making host-level behavioral fingerprinting harder by blending circumvention flows with benign traffic.
+section: §3 (behavioral classification)
+extracted_by: claude-sonnet-4-6

corpus/findings/2014-cao-survey-encrypted-traffic__mimicry-morphing-countermeasures-fail-statistical-classifier.yaml

@@ -0,0 +1,22 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2014-cao-survey-encrypted-traffic
+kind: defense
+summary: 'The survey catalogs the major circumvention countermeasures extant as of 2014: obfsproxy/obfs3 (randomized handshake), StegoTorus (steganographic camouflage), traffic morphing (Wright et al.), SkypeMorph (Tor bridge mimicking Skype), and Format-Transforming Encryption (FTE). It also cites ''Peek-a-boo, I still see you'' (Dyer et al. 2012) and ''The Parrot is Dead'' (Houmansadr et al. 2013) as demonstrating that naive traffic-analysis countermeasures and protocol mimicry approaches fail against statistical classifiers.'
+techniques:
+    - traffic-shape
+    - ml-classifier
+defenses:
+    - obfs4
+    - pluggable-transport
+    - mimicry
+    - format-transform
+    - randomization
+    - steganography
+censors:
+    - generic
+defense_implications:
+    - Protocol mimicry ('be the parrot') approaches that imperfectly replicate the target protocol's statistical properties are detectable; countermeasures must achieve statistically indistinguishable distributions, not just superficial format similarity.
+    - FTE and traffic-morphing techniques that reshape only packet sizes while leaving inter-arrival timing unchanged remain vulnerable — effective defenses must jointly normalize all observable flow features.
+section: §4 (countermeasures) / References 17–19, 38–42
+extracted_by: claude-sonnet-4-6

corpus/findings/2014-cao-survey-encrypted-traffic__ml-classifies-encrypted-flows-metadata-only.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2014-cao-survey-encrypted-traffic
+kind: detection
+summary: Machine-learning classifiers applied to flow-level features (packet sizes, inter-arrival times, byte counts, flow duration) can identify encrypted application protocols including SSH and Skype without inspecting payload content. Supervised and unsupervised approaches reported in the survey demonstrate that encrypted traffic classification is practically feasible using only transport-layer metadata.
+techniques:
+    - ml-classifier
+    - traffic-shape
+censors:
+    - generic
+defense_implications:
+    - Traffic shaping that only pads packet sizes is insufficient — inter-arrival timing, flow duration, and byte-count distributions must also be normalized to defeat ML classifiers.
+    - Circumvention tools should evaluate their flows against published ML classifiers (BLINC, flow-based SSH detectors) before deployment to verify statistical indistinguishability.
+section: §3 (ML classification)
+extracted_by: claude-sonnet-4-6

corpus/findings/2014-cao-survey-encrypted-traffic__three-level-classification-coarse-app-fine-grained.yaml

@@ -0,0 +1,16 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2014-cao-survey-encrypted-traffic
+kind: evaluation
+summary: 'The survey frames encrypted traffic classification as a three-level problem: coarse (encrypted vs. unencrypted), application-level (which app/protocol), and fine-grained (which service within an app, e.g., Skype voice vs. video). Fine-grained classification of encrypted traffic remains an open challenge as of 2014, with host-profiling and flow-correlation methods achieving the best results but requiring sustained observation windows rather than per-packet or per-flow decisions.'
+techniques:
+    - ml-classifier
+    - traffic-shape
+    - flow-correlation
+censors:
+    - generic
+defense_implications:
+    - Fine-grained traffic classification requires sustained observation; circumvention transports that limit session duration or use many short connections reduce the censor's observation window and degrade classifier accuracy.
+    - Traffic multiplexing (combining multiple logical streams over one encrypted tunnel) makes fine-grained service-level classification harder by mixing signal from different traffic classes.
+section: §2–§3 (classification taxonomy)
+extracted_by: claude-sonnet-4-6

corpus/findings/2022-gfw-report-great-firewall-china__gfw-business-hours-stun-selective-lift.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2022-gfw-report-great-firewall-china
+kind: deployment
+summary: The SNI and DNS censorship events both started during Chinese business hours, consistent with deliberate operator-initiated rule changes rather than automated triggers. The blocking of stun.l.google.com (a STUN server used by WebRTC/ICE) was later selectively lifted by early 2024 (confirmed via OONI stunreachability measurements), while core services like docs, drive, and accounts remained blocked.
+techniques:
+    - sni-blocking
+    - dns-poisoning
+censors:
+    - cn
+defense_implications:
+    - WebRTC-based pluggable transports (e.g., Snowflake) that use Google STUN servers should verify STUN reachability per-region, as GFW blocking of STUN infrastructure can be selectively toggled.
+    - Censorship rule changes occur on human timescales during working hours; circumvention infrastructure should detect and adapt to sudden blocking events rather than assuming static censor behavior.
+section: Issue body and wkrp comment Jan 31 2024
+extracted_by: claude-sonnet-4-6

corpus/findings/2022-gfw-report-great-firewall-china__gfw-dns-injector-nonuniform-coverage.yaml

@@ -0,0 +1,14 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2022-gfw-report-great-firewall-china
+kind: deployment
+summary: Three distinct GFW DNS injector fingerprints were identified; google.com was censored by all three injectors, while *.google.com was only censored by DNS Injectors 2 and 3 (not Injector 1). This differential coverage reveals that GFW's DNS injection infrastructure is not monolithic and rule deployment is not uniform across injector clusters.
+techniques:
+    - dns-poisoning
+censors:
+    - cn
+defense_implications:
+    - When probing for censorship, testing from a single vantage point may give incomplete results; multiple geographic/carrier vantage points are needed to confirm uniform blocking.
+    - Non-uniform DNS censorship means some users inside China may resolve the same domain differently depending on which injector cluster their ISP routes through.
+section: 'Q: What else have you observed about the blocking? (Oct 1 2022)'
+extracted_by: claude-sonnet-4-6

corpus/findings/2022-gfw-report-great-firewall-china__gfw-google-partial-rollback-47-domains.yaml

@@ -0,0 +1,14 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2022-gfw-report-great-firewall-china
+kind: evaluation
+summary: 'By February 1, 2023, the GFW had rolled back the wildcard *.google.com DNS censorship to a selective list: only 47 of the original 1,147 blocked domains remained censored, including high-sensitivity services (docs.google.com, drive.google.com, accounts.google.com, play.google.com) while lower-sensitivity domains (e.g., translate.google.com) were unblocked. The GFW''s injected DNS responses for google.com use real IP addresses belonging to other tech companies (e.g., 69.63.184.14 belonging to Facebook).'
+techniques:
+    - dns-poisoning
+censors:
+    - cn
+defense_implications:
+    - GFW censorship of a domain is not permanent; circumvention tools should maintain live reachability checks rather than static blocked-domain lists, as enforcement scope can shrink or expand.
+    - GFW DNS injection with real third-party IPs (rather than known bogon addresses) means naive detection based on RFC1918 or known-bogon checks will miss injected responses; detectors must validate that returned IPs actually serve the expected TLS certificate.
+section: gfw-report comment, Feb 1 2024
+extracted_by: claude-sonnet-4-6

corpus/findings/2022-gfw-report-great-firewall-china__gfw-google-sni-dns-sequential-block.yaml

@@ -0,0 +1,16 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2022-gfw-report-great-firewall-china
+kind: deployment
+summary: The GFW deployed SNI-based blocking on google.com and all *.google.com on September 22, 2022 (between 6:23 AM and 7:33 PM Beijing Time), then added DNS-based blocking eight days later on September 30, 2022 (between 1:56 PM and 2:35 PM Beijing Time). All 1,147 tested *.google.com domains were blocked without exception under the wildcard rule.
+techniques:
+    - sni-blocking
+    - dns-poisoning
+    - rst-injection
+censors:
+    - cn
+defense_implications:
+    - Protocols that rely on the TLS SNI field for routing or identity must assume SNI is inspected and acted upon by the GFW; any circumvention transport must either encrypt or omit the SNI.
+    - DNS resolution of proxy server hostnames cannot be trusted inside China; circumvention tools should distribute server IPs out-of-band or use DoH/DoT over trusted channels rather than relying on the system resolver.
+section: Issue body (gfw-report, Oct 1 2022)
+extracted_by: claude-sonnet-4-6

corpus/findings/2022-gfw-report-great-firewall-china__gfw-sni-dns-detection-methodology.yaml

@@ -0,0 +1,17 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2022-gfw-report-great-firewall-china
+kind: evaluation
+summary: 'The report documents a reproducible methodology for detecting GFW SNI blocking and DNS injection: SNI blocking is confirmed by sending a TLS ClientHello with the target SNI to an open port of an external server and observing TCP RST (errno=104); DNS injection is confirmed by sending a DNS query to a non-DNS IP outside China and receiving any response, since a non-DNS server cannot legitimately reply.'
+techniques:
+    - sni-blocking
+    - dns-poisoning
+    - rst-injection
+    - measurement-platform
+censors:
+    - cn
+defense_implications:
+    - Circumvention tool health checks can use the same technique (ClientHello with known-blocked SNI to a probe server) to confirm that a user is behind GFW SNI filtering before attempting a bypass.
+    - Sending DNS queries to non-DNS IPs is a lightweight, side-channel-safe method to probe for GFW DNS injection without relying on known-bad IP lists that may become stale.
+section: Detection methodology section (Oct 1 2022)
+extracted_by: claude-sonnet-4-6

corpus/findings/2023-rprx-watch-out-hidden__downgrade-attack-sni-whitelist-hypothesis.yaml

@@ -0,0 +1,18 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2023-rprx-watch-out-hidden
+kind: policy
+summary: 'RPRX argues the combination of SNI-whitelist plus non-blocking of fully-randomized protocols constitutes an intentional ''downgrade attack'': coercing users from TLS (which has forward secrecy) toward bare random protocols that lack forward secrecy, meaning a single key compromise enables retroactive decryption of all past and future traffic. The hypothesis is that surveillance rather than blocking is the goal in these pilot regions.'
+techniques:
+    - sni-blocking
+    - fully-encrypted-detect
+defenses:
+    - shadowsocks
+    - reality
+censors:
+    - cn
+defense_implications:
+    - Prefer protocols with TLS 1.3 forward secrecy over bare encrypted protocols even when bare protocols appear to work unblocked — the absence of blocking may be intentional surveillance tolerance
+    - Treat forward secrecy as a non-negotiable property for any circumvention protocol, not merely a performance tradeoff
+section: Issue body / original post
+extracted_by: claude-sonnet-4-6

corpus/findings/2023-rprx-watch-out-hidden__gfw-cost-saving-rules-strategic-nonblock.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2023-rprx-watch-out-hidden
+kind: detection
+summary: GFW's 'cost-saving rules' (documented in the USENIX Security 2023 paper on fully-encrypted protocol detection) are already capable of precisely blocking fully-randomized protocols without expensive machine learning. The deliberate non-use of this detection capability in Quanzhou/Fuzhou SNI-whitelist regions indicates the non-blocking is a strategic choice, not a technical limitation — making 'detection cost' arguments unreliable for protocol designers.
+techniques:
+    - fully-encrypted-detect
+    - ml-classifier
+censors:
+    - cn
+defense_implications:
+    - Do not rely on detection-cost arguments when choosing between protocol designs — a censor may choose not to block a detectable protocol for strategic rather than technical reasons
+    - Assume any fully-randomized protocol that is detectable in principle will be selectively blocked or allowed based on censor strategy, not detection capability
+section: RPRX comment, May 25 2023
+extracted_by: claude-sonnet-4-6

corpus/findings/2023-rprx-watch-out-hidden__iran-cn-tls-anchor-reality-only-survivor.yaml

@@ -0,0 +1,19 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2023-rprx-watch-out-hidden
+kind: evaluation
+summary: 'Iran''s censorship strategy (cross-referenced in net4people/bbs issue #253, concurrent with this discussion) mirrors the SNI-whitelist pattern: UDP is interfered with broadly, and on TCP only common protocols resembling legitimate TLS survive an SNI whitelist, leaving REALITY-type protocols as the only reliable circumvention option. This convergence between China''s pilot regions and Iran''s nationwide blocking strengthens the case that TLS-anchored protocols outperform bare randomized protocols under aggressive censorship.'
+techniques:
+    - sni-blocking
+    - http3-quic-block
+    - fully-encrypted-detect
+defenses:
+    - reality
+censors:
+    - cn
+    - ir
+defense_implications:
+    - Design circumvention protocols to survive simultaneous UDP interference and SNI-whitelist TCP filtering — QUIC-based and bare-random transports are non-starters in the most restrictive environments
+    - TLS-anchored protocols (REALITY, Trojan) should be the default recommendation for users in high-restriction environments, not bare randomized protocols that appear to 'work' under selective non-enforcement
+section: RPRX comment, May 25 2023
+extracted_by: claude-sonnet-4-6

corpus/findings/2023-rprx-watch-out-hidden__reality-recommended-sni-whitelist-regions.yaml

@@ -0,0 +1,17 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2023-rprx-watch-out-hidden
+kind: defense
+summary: RPRX reports that REALITY remains usable in SNI-whitelist regions as of May 2023, and addresses the CA trust risk inherent in conventional TLS-based circumvention. The recommended configuration is REALITY or REALITY-over-SS for users in SNI-whitelist areas, as it provides forward secrecy without relying on CA infrastructure that is potentially compromised.
+techniques:
+    - sni-blocking
+defenses:
+    - reality
+    - shadowsocks
+censors:
+    - cn
+defense_implications:
+    - Deploy REALITY-based transports as the primary recommendation for SNI-whitelist regions — it survives SNI-whitelist filtering while providing forward secrecy without a trusted CA dependency
+    - Eliminate CA infrastructure dependency from circumvention protocols to remove a surveillance attack surface that does not exist in REALITY's TLS handshake-forwarding design
+section: Issue body / original post
+extracted_by: claude-sonnet-4-6

corpus/findings/2023-rprx-watch-out-hidden__sni-whitelist-anomalous-nonblock-randomized.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2023-rprx-watch-out-hidden
+kind: detection
+summary: In SNI-whitelist pilot regions of China (documented in Quanzhou and Fuzhou, Fujian since at least May 2022 across home broadband, 5G, and 4G), IPv4 TCP blocks TLS connections via SNI whitelist but does NOT block fully-randomized bare protocols such as Shadowsocks and VMess. GFW in other regions readily identifies and blocks these same fully-randomized protocols, making the non-blocking anomalous.
+techniques:
+    - sni-blocking
+    - fully-encrypted-detect
+censors:
+    - cn
+defense_implications:
+    - Do not treat 'not currently blocked' as a safety signal — an anomalous non-block may indicate deliberate surveillance tolerance rather than inability to detect
+    - Treat differential regional blocking behavior as evidence of active censor strategy and design for the worst-case region, not the current observed region
+section: Issue body / original post; RPRX September 2023 addendum
+extracted_by: claude-sonnet-4-6

corpus/findings/2025-chen-miett-multi-instance-encrypted__miett-sota-five-datasets-zero-shot-generalization.yaml

@@ -0,0 +1,15 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2025-chen-miett-multi-instance-encrypted
+kind: detection
+summary: MIETT achieves state-of-the-art performance across five encrypted-traffic classification datasets using a transformer foundation model pre-trained with unlabeled traffic, indicating that modern ML classifiers can generalize to previously unseen encrypted protocols without labeled training data for those protocols.
+techniques:
+    - ml-classifier
+    - fully-encrypted-detect
+censors:
+    - generic
+defense_implications:
+    - Zero-shot generalization means new circumvention protocols cannot rely on novelty alone to evade ML classifiers trained on unrelated traffic; protocol designers must target specific measurable feature distributions
+    - Consider explicitly shaping flows to match the statistical fingerprint of a high-volume allowed application (e.g., video streaming) that was included in the classifier's unlabeled pre-training corpus
+section: Abstract
+extracted_by: claude-sonnet-4-6

corpus/findings/2025-chen-miett-multi-instance-encrypted__miett-surpasses-prior-encrypted-traffic-classifiers.yaml

@@ -0,0 +1,16 @@
+# Auto-extracted by corpus-findings from full paper text.
+# Review summary + tags before relying.
+paper: 2025-chen-miett-multi-instance-encrypted
+kind: evaluation
+summary: The paper benchmarks MIETT against prior encrypted-traffic classifiers across five datasets, spanning multiple application types and network conditions, and reports state-of-the-art results — establishing that multi-instance transformer models have surpassed earlier DPI and convolutional approaches for fine-grained encrypted-traffic classification.
+techniques:
+    - ml-classifier
+    - dpi
+    - traffic-shape
+censors:
+    - generic
+defense_implications:
+    - The gap between transformer-based classifiers and traditional DPI is closing; circumvention tools that assumed ML-based classifiers were impractical at line rate should revisit that assumption as foundation-model inference is increasingly feasible on dedicated hardware
+    - Academic SOTA on public benchmarks underestimates censor capability — nation-state censors with proprietary labeled datasets and hardware may already have deployed equivalent or superior classifiers
+section: Abstract / Experiments
+extracted_by: claude-sonnet-4-6