[tor-bugs] #2764 [Tor Bridge]: analyze security tradeoffs from using a socks proxy vs a bridge to reach the Tor network

[Tor Bug Tracker & Wiki]

#2764: analyze security tradeoffs from using a socks proxy vs a bridge to reach
the Tor network
------------------------+---------------------------------------------------
 Reporter:  arma        |          Owner:                     
     Type:  task        |         Status:  new                
 Priority:  normal      |      Milestone:  Deliverable-May2011
Component:  Tor Bridge  |        Version:                     
 Keywords:              |         Parent:                     
   Points:              |   Actualpoints:                     
------------------------+---------------------------------------------------
 At the beginning of the bridge design, we decided to use a building block
 we'd already written (a "relay") for the proxy step. This strategy gave us
 several practical advantages:
 - The code was already written, so we didn't have to write new proxy
 programs.
 - The packages already exist so we don't have any new portability worries.
 - People already have an incentive to install the Tor program, so we'd get
 more bridges.
 - It's easier to extend our code to collect and publish statistics like
 load, number of users, geoip lookups on the users, etc
 - We could reuse the directory authority design to run a bridge authority
 that does reachability checking, collects bridge descriptors, annotates
 which ones are Running/Stable/etc, exports them to bridgedb, and so on.

 But from a *security* perspective (for a broad definition of security), is
 there really any difference between a socks proxy and a bridge relay?

 One difference is that the socks handshake is in the clear, so if you're
 asking to connect to a public Tor relay, an observer can see its IP
 address and realize that you're using socks to reach the Tor network. We
 could imagine workarounds here where the socks proxy chooses its
 destination independent of the address you ask for, either by hard-coding
 a bridge address, hard-coding a public relay address, or round-robining
 you among several. Depending on which we choose, the Tor client would have
 to learn to not freak out when it gets the wrong guy on the other end.

 Another difference is that the traffic coming into the bridge is crypted
 differently than the traffic coming out of it (both via link encryption on
 each side and at a layer underneath that). Are there any adversaries that
 this traffic rewriting step stymies in any way?

 What other considerations am I missing?

 (I don't mean to throw away the bridge notion. But -- if it's safe -- I
 want to supplement it with an alternative, for people who don't want to
 run a whole Tor bridge, either due to resource constraints (Tor router) or
 complexity constraints (imagine a flash plugin that proxies incoming
 traffic to a "real" Tor relay).)

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