Opened 13 months ago

Last modified 13 months ago

#31998 new enhancement

Linked Tor Relays To Bypass Probing?

Reported by: Aphrodites1995 Owned by:
Priority: Medium Milestone:
Component: Circumvention/Censorship analysis Version:
Severity: Normal Keywords:
Cc: dcf Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


As tor bridges are obtainable, one idea would be for a tor bridge to "link" with another tor bridge. Here, the bridges are obtained in pairs. What linking does is that the client has to send the exact message with sync(using different keys of course) to both bridges, after the bridges receive the message, one server claims the connection and then sees whether the other receives the message as well. This way, there are a lot more combinations to check for the censor.

Child Tickets

Change History (1)

comment:1 Changed 13 months ago by dcf

Version: Tor: unspecified

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 NODEID, rather than just a semi-secret IP address and port.

Note: See TracTickets for help on using tickets.