Hello Tor Project team,
I’d like to propose work on two pluggable-transport (PT) approaches that
are under-represented and promising for censorship-resistant connectivity:
1.
DNS-over-HTTPS (DoH) — lightweight bootstrap/control channel
2.
gRPC over HTTP/2 — medium-bandwidth API-style cover as an alternate path
Summary / motivation
-
DoH is already ubiquitous for resolver traffic and makes an excellent
low-bandwidth, hard-to-block bootstrap or handshake channel if its TLS and
HTTP semantics are convincingly matched.
-
gRPC over HTTP/2 approximates modern microservice API traffic: it
supports binary protobufs, multiplexing, and request patterns that could
plausibly hide Tor control or medium-bandwidth traffic when implemented
correctly.
What needs to be matched (technical fingerprint checklist)
DoH (bootstrap/control)
-
Proper HTTP semantics: GET vs POST usage, request URLs, query
parameters, Content-Type: application/dns-message.
-
TLS ClientHello profile: cipher suites, extensions, and ordering that
match real DoH clients.
-
Resolver behaviour: realistic query timing, distribution of queried
names, EDNS padding patterns, caching/TTL behaviour.
-
Endpoint selection: plausible resolver IPs or cooperating resolvers;
avoid impersonating a single provider verbatim.
gRPC over HTTP/2
-
Correct HTTP/2 SETTINGS and initial frame ordering, window sizes, and
flow control behavior.
-
HPACK header ordering and dynamic table behaviour consistent with real
clients.
-
content-type: application/grpc framing (5-byte prefix) and protobuf
payload size/patterns.
-
Multiplexing and concurrent stream lifetimes that match typical
microservice usage.
-
TLS+ALPN indicating h2 and realistic client TLS fingerprints.
High-level design suggestion
-
Hybrid approach: implement gRPC/HTTP2 as the main data channel; use DoH
as a minimal, stealthy bootstrap/handshake channel.
-
Prototype in stages: DoH is lower complexity and valuable for learning
how strict TLS/HTTP fingerprints must be. gRPC/HTTP2 can be tackled next
for medium-bandwidth traffic.
-
Testing: capture real traces from modern browsers/clients and create
behaviour models (packet sizes, timings, SETTINGS sequences) to drive
deterministic emulation. Validate against both signature-based DPI and ML
flow detectors.
-
Ethical/legal: avoid impersonating a specific cloud provider or critical
service verbatim. Prefer “class” mimicry (generic HTTPS/API behaviour) or
cooperative fronting partners. Test only in controlled environments and
with clear user consent.
Risks & caveats
-
Censors increasingly use ML/flow analysis; simple header/TLS mimicry is
insufficient — flow-level statistics must be matched.
-
Impersonating major cloud providers/resolvers can create legal or
service-impact risks; this requires careful consideration and preferably
cooperation.
Requested next steps
1.
Is the Tor Project interested in exploring DoH and/or gRPC/HTTP2 as new
pluggable transports?
2.
If yes, would you prefer a short design doc + sample traces (DoH first),
or should I open a GitHub issue with a proposed roadmap and prototype tasks?
3.
Are there legal/ethical constraints I should be aware of when proposing
specific endpoint classes (e.g., cooperating CDN vs. impersonation)?
Thank you for considering this. I’m happy to iterate on the proposal,
provide technical traces, or collaborate on a prototype.
Best regards,
Kes Pembroke
This email pembrokekester80(a)gmail.com
