Proposal 176: Proposed version-3 link handshake for Tor

[George Kadianakis]

Nick Mathewson <nickm at freehaven.net> 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.