[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] A meta-package for Pluggable Transports?
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev