Opened 8 years ago

Closed 20 months ago

#2764 closed task (wontfix)

analyze security tradeoffs from using a socks proxy vs a bridge to reach the Tor network

Reported by: arma Owned by: arma
Priority: High Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: ln5, StrangeCharm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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).)

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by arma

Sebastian points out that a proxy in the middle, like a bridge whose fingerprint you don't know, gets to control what points you can extend to. This could make worse the problem of your first hop refusing to extend to second hops that it can't control/observe.

comment:2 Changed 8 years ago by arma

Owner: set to arma
Priority: normalmajor
Status: newassigned

I have a blog post pending on a related topic ("how to get more bridge addresses"). It's pending because it mentions the flash applet proxy idea and I want Dan to vet it first so I don't ruin the publication chances of his students.

I should also write up a paragraph or something here just to be extra thorough that we've done it.

My current conclusions are "I don't see any huge roadblocks to having bridges that are just vanilla proxies. We should deploy them if we can make them usable, and maybe someday somebody will show us it was a bad idea."

comment:3 Changed 8 years ago by arma

Component: Tor BridgeAnalysis
Milestone: Deliverable-May2011

comment:4 Changed 7 years ago by arma

My conclusions remain "I don't see any huge roadblocks to having bridges that are just vanilla proxies. We should deploy them if we can make them usable, and maybe someday somebody will show us it was a bad idea." Similarly, for #3292, we should support "I don't care what fingerprint my bridge claims to have".

This discussion ties into Sebastian's blog post:
https://blog.torproject.org/blog/different-ways-use-bridge

If you're using a bridge for reachability rather than security, we should remove as many barriers to continuing to use the bridge as we can.

comment:5 Changed 7 years ago by ln5

Cc: ln5 added

comment:6 Changed 7 years ago by arma

Leaving this ticket open until we make new tickets for tasks like #3466.

comment:7 Changed 7 years ago by StrangeCharm

Cc: StrangeCharm added

comment:8 Changed 20 months ago by karsten

Resolution: wontfix
Status: assignedclosed

Closing tickets in Metrics/Analysis that have been created 5+ years ago and not seen progress recently, except for the ones that "nickm-cares" about.

Note: See TracTickets for help on using tickets.