[tor-dev] A meta-package for Pluggable Transports?

Ximin Luo infinity0 at torproject.org
Tue Jul 5 16:45:09 UTC 2016

> Ximin Luo:
>> I made something like this a few years ago:
>> https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/
> A general question, but related to the sample configuration you've
> provided here, as well as other instructions I've seen online:
> I've heard that the Chinese government tests suspected bridges by
> attempting to connect to them and seeing if they respond to the Tor
> protocol. Whether China is actually doing this or not, it would not be a
> terribly difficult thing for any competent censor to do.
> So with this in mind, wouldn't it be best for new bridges to support
> ONLY obfs4, and not any of the older protocols?
> In particular, it seems like a very bad idea to enable the default
> ORPort (9001), unless I'm missing something. Is it actually necessary to
> have an open ORPort in order to work as an obfuscated bridge? If it is
> necessary, at least that port should be picked randomly to make it
> harder for censors to guess. If it's not needed, then that port should
> presumably be set to listen only on or similar.
> This isn't mentioned in any of the bridge-related documentation I've
> seen, though I haven't looked very hard.

You are quite probably right. The thing I posted was a sample "initial attempt" and not an end product. (Other protocols like snowflake and meek-client might also be OK since they also don't expose a public listen port.)


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the tor-dev mailing list