[tor-bugs] #31998 [Circumvention/Censorship analysis]: Linked Tor Relays To Bypass Probing?

[Tor Bug Tracker & Wiki]

#31998: Linked Tor Relays To Bypass Probing?
-----------------------------------------------+------------------------
 Reporter:  Aphrodites1995                     |          Owner:  (none)
     Type:  enhancement                        |         Status:  new
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Censorship analysis  |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:                                     |  Actual Points:
Parent ID:                                     |         Points:
 Reviewer:                                     |        Sponsor:
-----------------------------------------------+------------------------
Changes (by dcf):

 * version:  Tor: unspecified =>


Comment:

 What makes active probing attacks against vanilla Tor bridges possible is
 the fact that there's no secret information required to access one, other
 than its IP address and port. If I understand you correctly, you are
 proposing to add a piece of secret information to each bridge: the IP
 address and port of a "buddy bridge." Legitimate clients who discover
 bridges through BridgeDB would know the address of the buddy bridge, but a
 censor who naively active-probes single TCP connections would not. A
 client uses a bridge by sending the same messages simultaneously to both
 the bridge and its buddy. The bridge and its buddy communicate in real
 time, sharing information about the connections they receive and only
 allowing a connection when they receive identical simultaneous messages.

 My first question about this idea is, does it still work after the censor
 knows about it? The censor can watch for clients that connect to two
 separate hosts within a timing threshold, and then active-probe both of
 those hosts in the same way that it now probes single hosts. The secret
 information you propose to add to the connection procedure is only an IP
 address and port—and the client reveals that secret information on the
 wire the first time it connects to a bridge. So the additional secret
 won't remain secret for long, if the censor knows what to look for. The
 censor doesn't have to do this in real time, either. It can make a big
 list of all suspected Tor bridge connections throughout a day, then every
 24 h process the list to find the ones that were initiated at about the
 same time by the same client.

 Connecting to two hosts simultaneously and sending them the exact same
 contents (even if encrypted) probably makes bridge connections more easily
 fingerprintable (by traffic characteristics).

 How does it work on the bridge side? I think it could enable some DoS
 attacks. When a bridge receives a connection, it now needs to start its
 own real-time communication with its buddy to learn whether the buddy also
 receives a connection. How long does it wait before deciding that the
 buddy did not? It will have to remember all incoming connections for that
 amount of time. And then what does it do after deciding that the client
 did not also connect to the buddy? Disconnecting after a fixed timeout,
 for example, would be its own kind of fingerprint that a censor could
 probe for, even without trying to learn buddy relationships.

 The biggest problem I see is that in order to send a message under
 encryption, the client and bridge already have to exchange a lot of
 fingerprintable traffic. They have already exchanged a TLS ClientHello and
 ServerHello, which will easily reveal that the connection is a Tor
 connection. At that point, the game is up, no matter what measures you try
 to take that happen later.

 This would be an incompatible change to the Tor protocol, requiring new
 code on both clients and servers. As long as you're making an incompatible
 change, you may as well use a proper bridge secret that does ''not'' get
 revealed on the wire, like obfs4's [https://gitweb.torproject.org
 /pluggable-
 transports/obfs4.git/tree/doc/obfs4-spec.txt?id=c0898c2d3b3b197ff93f9b1c1da2bbcec0fec341#n75
 NODEID], rather than just a semi-secret IP address and port.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31998#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online