Opened 13 years ago

Last modified 7 years ago

#303 closed enhancement (Implemented)

prevent single-hop proxy usage

Reported by: goodell Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: goodell Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Controllers that allow Tor clients to use Tor servers as single-hop
proxies present a danger to the Tor network. This use not only
reduces the anonymity attained by the client but also creates new
incentives for adversaries to run malicious Tor servers, compromise
existing Tor servers, or request logs from Tor servers.

Nevertheless, some users of the Tor network may have an incentive
to use Tor servers in this manner. Those users include (a) those
who are interested in anonymity from the server but not from the
network and (b) those who want to use Tor as a perspective access
network but do not care about anonymity.

Servers can defend against this particular attack by requiring
that for any given circuit extension request it receives, either
(a) the host from which the request was received OR (b) the
server to which the request will be extended is a valid Tor
server. This assures that each circuit involving this server
includes at least two Tor servers (though the first may actually
be a client).

To my knowledge, there is no way for servers to ensure that they
are only carrying circuits of length greater than two without
compromising some of the anonymity properties of the circuit.

This approach creates some new irregularities. For example, it
presumes that all servers have a (roughly) equivalent list of
all Tor servers. In particular, there will be a certain period
of time during which a new Tor server will not be accepted as
the second hop in a three-hop circuit while the other servers
learn about its existence.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (3)

comment:1 Changed 13 years ago by nickm

I agree it might be nice to do something here.

The described server-side solution is not something I think we should put in,
since our trend is *away* from requiring servers to know about all other servers.

If we're satisfied with only adding speedbumps (and making it clear that we do not
want people doing 1-hop circuits), we could add client-side code to keep you from
attaching streams to 1-hop circuits, and server-side code to keep you from exiting
from any circuit make with a CREATE_FAST cell.

Is this worth doing?

comment:2 Changed 13 years ago by nickm

flyspray2trac: bug closed.
Stop-gap speedbump solution implemented; not requiring servers to know all servers, since that will result in annoying unpredictable stream failures.

comment:3 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.