Nick Mathewson <[email protected]> writes: > 2) We should make it harder to probe for a Tor server. Right > now, you can just do a handshake with a server, > renegotiate, then see if it gives you a VERSIONS cell. > That's no good. >
Since a way to avoid Tor server probing was not mentioned in the proposal and the problem mentioned above is still present (although now the prober sends a VERSIONS cell and waits for reply), I think we need to define our probe-resistance. Do we need all Tor servers, including normal relays and exit servers, to be probe-resistant or just the bridges? Since the Tor network is public - as far as the relays and exits are concerned - making it probe-resistant would serve little purpose, except for providing flexibility in case the network scheme changes in the future [1]. On the other hand, probe-resistant bridges are essential - especially with the increasing role of Tor as a circumvention tool. The good thing with this is that bridge addresses are already provided out of band, which allows us to also provide non-public information to bridge users that will help anti-probing [2]. So do we care about a probe-resistant Tor network, or do we keep the probe resistance for the circumvention tool part of Tor? [1]: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldhidethelistofTorrelayssopeoplecantblocktheexits. [2]: For example, a silly scheme would be to provide the bridge user with another field called 'secret' - basically a per-bridge hash value - that comes with the bridge address and bridge fingerprint. The 'secret' field should be sent to the bridge on the beginning of the cell-based part of the V3 handshake and the handshake should proceed only if the 'secret' field matches the 'secret' of the bridge. Otherwise, the bridge should act accordingly as if it's getting probed.
