Hello Kester, Thank you for experimenting with new ideas for PTs. Quoting Kester Pembroke via anti-censorship-team (2025-10-21 17:26:16)
- Prototype a PT that mimics browser extension filter-list update checks (ad‑blocker‑like traffic) to carry an encrypted tunneled payload.
Is your idea to use existing filter-list hosting to tunnel Tor's traffic? Are those hostings public and we can put traffic on them? Or the idea is that each bridge will have their own HTTP server in their own domain hosted by themselves? If is selfhosted, How are filter-list updates different from any other web traffic? There is already two PTs using web traffic: * meek uses HTTP GET requests * webtunnel uses websockets What will be the benefit of using filter-list updates?
Questions I have for you / requested guidance
1. Is this façade approach acceptable for a Tor pluggable transport from the Tor Project’s perspective (network safety, abuse potential, collateral damage)?
2. Are there existing PT design constraints / packaging rules I should follow (besides the obvious obfs4/meek references)? Any docs you recommend for integrating with the ClientTransportPlugin flow and signing/release packaging?
Not sure, I need to understand more about it to answer this.
3. Any security pitfalls I missed (e.g., observable TLS fingerprint mismatches, directory authorities concerns, recommended key exchange patterns)?
To avoid TLS fingerprinting we use uTLS in many places: https://pkg.go.dev/github.com/refraction-networking/utls -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.