Blocking-resistant communication through domain frontingcore

Domain fronting exploits the fact that major CDN providers (Google, Amazon CloudFront, Akamai, Microsoft Azure) terminate TLS at the edge before inspecting the Host header, so the SNI visible to a censor names a permitted CDN domain (e.g., www.google.com) while the inner HTTP Host header routes the request to a blocked destination. Blocking the fronted service requires blocking the entire CDN, creating collateral damage that most censors are unwilling to accept for major providers.

§2 defense sni-blockingdpi cnirrugeneric

The meek pluggable transport, implementing domain fronting over HTTPS, achieved median download throughput of roughly 1–2 Mbps in controlled tests from censored regions (China, Iran), confirming that CDN-fronted tunnels are viable for real users at consumer broadband speeds. Latency overhead compared to direct connections was measurable (tens of milliseconds per round-trip through the CDN edge) but acceptable for browsing workloads.

§5 evaluation sni-blocking cnir

The paper formally characterizes the censor's visibility gap: the SNI field in the TLS ClientHello and the HTTP Host header inside the tunnel are the two places that reveal destination, and CDNs that terminate TLS before forwarding HTTP requests prevent censors from correlating them. Any censor capable of correlating SNI to inner-Host (e.g., through CDN cooperation or plaintext HTTP/2 framing) can defeat domain fronting without CDN blocking.

§3 detection sni-blockingdpi genericcnirru