nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 12:23:32 +01:00
Code Issues Packages Projects Releases Wiki Activity

more on helper nodes

Browse Source 
svn:r3430
This commit is contained in:
Roger Dingledine 2005-01-26 11:09:57 +00:00
parent 985e26f017
commit 69a46ff522
1 changed files with 29 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/design-paper/challenges.tex
View File

@ -178,7 +178,12 @@ in practice tor's threat model is based entirely on the goal of dispersal
and diversity. george and steven describe an attack \cite{draft} that
lets them determine the nodes used in a circuit; yet they can't identify
alice or bob through this attack. so it's really just the endpoints that
remain secure. see \ref{subsec:routing-zones} for discussion of larger
remain secure. and the enclave model seems particularly threatened by
this, since this attack lets us identify endpoints when they're servers.
see \ref{subsec:helper-nodes} for discussion of some ways to address this
issue.
see \ref{subsec:routing-zones} for discussion of larger
adversaries and our dispersal goals.
\section{Crossroads: Policy issues}
@ -318,13 +323,25 @@ IDS.] Our server operators tell us that exit policies are one of
the main reasons they're willing to run Tor over previous attempts
at anonymizing networks. Adding an IDS to handle exit policies would
increase the security complexity of Tor, and would likely not work anyway,
as evidenced by the entire field of IDS and counter-IDS papers.
as evidenced by the entire field of IDS and counter-IDS papers. Many
potential abuse issues are resolved by the fact that Tor only transports
valid TCP streams (as opposed to arbitrary IP including malformed packets
and IP floods), so exit policies become even \emph{more} important as
we become able to transport IP packets. We also need a way to compactly
characterize the exit policies and let clients parse them to decide
which nodes will allow which packets to exit.
\item [The Tor-internal name spaces would need to be redesigned.] We
support hidden service \tt{.onion} addresses, and other special addresses
like \tt{.exit} (see Section \ref{subsec:}), by intercepting the addresses
when they are passed to the Tor client.
\end{enumerate}
This list is discouragingly long right now, but we recognize that it
would be good to investigate each of these items in further depth and to
understand which are actual roadblocks and which are easier to resolve
than we think. We certainly wouldn't mind if Tor one day is able to
transport a greater variety of protocols.
\subsection{Mid-latency}
Mid-latency. Can we do traffic shape to get any defense against George's
@ -382,6 +399,16 @@ that using Tor as a building block for Free Haven is going to be really
hard. Also, they're brittle in terms of intersection and observation
attacks. Would be nice to have hot-swap services, but hard to design.
Game theory for helper nodes: if Alice offers a hidden service on a
server (enclave model), and nobody ever uses helper nodes, then against
George+Steven's attack she's totally nailed. If only Alice uses a helper
node, then she's still identified as the source of the data. If everybody
uses a helper node (including Alice), then the attack identifies the
helper node and also Alice, and knows which one is which. If everybody
uses a helper node (but not Alice), then the attacker figures the real
source was a client that is using Alice as a helper node. [How's my
logic here?]
in practice, sites like bloggers without borders (www.b19s.org) are
running tor servers but more important are advertising a hidden-service
address on their front page. doing this can provide increased robustness