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

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


Dafwig:
> 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 127.0.0.1 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.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


More information about the tor-dev mailing list