27 August 2012. A sends links to related papers:
http://cryptome.org/2012/08/tor-exits-usg-funds-02.htm
24 July 2012. Add response titled "Electronic
surveillance on major tor exits."
23 July 2012
Tor to Offer USG Funds for Exit Relays
Lance Cottrell, Anonymizer.com:
"I personally would never use Tor for anonymity. You're putting a lot of
trust in the guy who is operating the system. [The data] is hopping from
one server to another, but whoever is running the end [exit] node can actually
do all sorts of crap to you. Scanners, interceptors, content modifiers ...
there's a lot things you can do at the last loop. Anyone can set up a Tor
node. It's all random,so you have no reason to trust the guy running the
nodes you're going through. There's reason to believe that intelligence agencies
from almost any country in the world are probably running Tor nodes, as well
as organized crime."
Excerpt of interview from: Hacking the Future: Privacy, Identity, and
Anonymity on the Web, Cole Stryker, October 2012, advance proof, p. 116.
Date: Mon, 23 Jul 2012 22:40:16 +0200
From: Eugen Leitl <eugen[at]leitl.org>
To: cypherpunks[at]al-qaeda.net, tt[at]postbiota.org
Subject: [tor-relays] Call for discussion: turning funding into more exit
relays
----- Forwarded message from Roger Dingledine <arma[at]mit.edu> -----
From: Roger Dingledine <arma[at]mit.edu>
Date: Mon, 23 Jul 2012 14:58:54 -0400
To: tor-relays[at]lists.torproject.org
Subject: [tor-relays] Call for discussion: turning funding into more exit
relays
For a few years now, funders have been asking if they can pay Tor to run
more relays. I kept telling them their money was better spent on code and
design improvements:
https://blog.torproject.org/blog/why-tor-is-slow
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/Performance
since a) network load would just grow to fill whatever new capacity we have,
especially if we don't deal with the tiny fraction of users who do bulk
downloads, and b) reducing diversity of relay operator control can harm
anonymity.
But lately the Tor network has become noticeably faster, and I think it has
a lot to do with the growing amount of excess relay capacity relative to
network load:
https://metrics.torproject.org/network.html?graph=bandwidth&start=2010-06-01&end=2012-07-21#bandwidth
At the same time, much of our performance improvement comes from better load
balancing -- that is, concentrating traffic on the relays that can handle
it better. The result though is a direct tradeoff with relay diversity: on
today's network, clients choose one of the fastest 5 exit relays around 25-30%
of the time, and 80% of their choices come from a pool of 40-50 relays.
https://trac.torproject.org/projects/tor/ticket/6443
Since extra capacity is clearly good for performance, and since we're not
doing particularly well at diversity with the current approach, we're going
to try an experiment: we'll connect funding to exit relay operators so they
can run bigger and/or better exit relays.
If we do it right (make more faster exit relays that aren't the current biggest
ones, so there are more to choose from), we will improve the network's diversity
as well as being able to handle more users.
We've lined up our first funder (BBG, aka
http://www.voanews.com/),
and they're excited to have us start as soon as we can. They want to sponsor
125+ fast exits.
----------------------------------------------------------------------
Open questions we need to decide about:
1) What exactly would we pay for?
I think the right way to do it is to offer to reimburse bandwidth/hosting
costs -- I don't want to get into the business of paying people to run relays,
and I don't want people to be trying to figure out how to "profit". That
leads to all sorts of horrible incentive structures.
More broadly, we should keep in mind that the primary cost of running an
exit relay is effort, not dollars: it takes dedication to find an ISP who
will host it, and to hold that ISP's hand when an abuse complaint arrives.
Or said another way, hosting costs are in many cases not the biggest barrier
to running an exit relay.
I think we should aim to constrain ourselves to talking about >=100mbit
exits, assuming that turns out to give us enough choices. That said, we don't
want to concentrate bandwidth too much in any given relay, so we should limit
the amount we'll reimburse per relay.
2) Should we fund existing relays or new ones?
The worst failure mode here would be that we screw up the current community
of relay operators. That's why it's extra important to keep them involved
at each step of this discussion.
I think the right answer is probably a balance of reimbursing costs from
current exits and encouraging new exits to appear. Before we can get more
precise though, we need to get a handle on how many current fast exits there
are, and what their constraints are (whether their hosting situation could
give them more bandwidth, whether they're paying now or getting a deal through
a friend/employer, etc).
Even then, there are interesting further questions like:
- Should we prefer big collectives like torservers, noisetor, CCC, dfri.se,
and riseup (which can get great bulk rates on bandwidth and are big enough
to have relationships with local lawyers and ISPs), or should we prefer
individuals since they maximize our operator diversity? I think "explore
both approaches" is a fine first plan.
- For existing relays who pay for hosting, should we prefer that our money
go to covering their existing costs (and then we encourage them to save their
money for use, say, after this experiment finishes), or should we aim to
add additional funding so the relay can use more bandwidth? I'd say it comes
down to the preferences of the relay operator. That said, if we have plenty
to choose from, we should pick the relays that will make the network grow
-- but we should take extra care to avoid situations where operators in the
first category say "well, fine" and shut down their relay.
More generally, we need to consider sustainability. Our current exit relay
funding is for a period of 12 months, and while there's reason to think we
will find continued support, the Tor network must not end up addicted to
external funding. So long as everybody is running an exit relay because they
want to save the world, I think we should be fine.
4) What exactly do we mean by diversity?
There's network diversity (AS / upstream network topology), organization
and operator diversity, jurisdictional (country) diversity, funding diversity,
data-center diversity, and more.
We've started to answer some of these questions at
https://trac.torproject.org/projects/tor/ticket/6232
https://blog.torproject.org/blog/research-problem-measuring-safety-tor-network
but this research topic will need ongoing attention. I'd love to get to the
point where our diversity metrics can recommend network locations that best
improve the various diversity scores.
5) How much "should" an exit relay cost?
Since we're aiming for diversity, we can't send all our volunteers to the
same cut-rate German VPS provider. After all, much of the work in setting
up an exit relay is finding a good provider that doesn't already host a bunch
of Tor relays.
But if we declare that we'll reimburse $50/month for 100mbit, we're going
to attract a different set of volunteers -- and a different set of network
locations -- than if we reimburse $100/month for 100mbit. We need to learn
about current bandwidth pricing: I know there are 10 cheap hosting places
that will tolerate exit relays, but are there 200? And do all of those 200
turn out to overlap diversity-wise? Initial guesses appreciated. I'm inclined
toward the $100 number to give our volunteers more flexibility.
If we want to reimburse on a monthly basis, how do we handle situations where
the ISP wants a longer-term contract? I think the answer will come down to
how many choices we have.
6) How exactly should we choose which exit relay operators to reimburse?
It might be premature to speculate until we better understand what choices
are available to us. But I think the answer must include doing it in a way
that encourages continued growth of the relay operator community.
People who are active in the Tor community, and well-known to many other
people, should be part of the answer. At the same time, we should be willing
to put some of the money into trying out new places and people, especially
if they're in good locations diversity-wise.
The broader answer is that we as a community need to figure out a good answer
here. I definitely don't want it to be "Roger picks people in an opaque way".
But I also don't want the answer to be "anybody on the Internet who offers
to take our money". Maybe we should put together a consortium of current
Tor activists who run fast exits?
7) How do we audit / track the sponsored relays?
How should we check that your 100mbit relay is really working? What do we
measure to confirm its capacity? To a first approximation I'm fine assuming
that nobody is going to try to cheat (say, by colluding with an ISP to write
legit-looking invoices but then just split the money).
But as the plan scales, we need good ways to track statistics on how many
relays are being sponsored and how much bandwidth they're providing (so funders
can see how effective their money is), and what fraction of the overall network
these sponsored relays are (to keep an eye on the diversity questions).
8) Legal questions?
Tor exit relays raise plenty of legal questions already, especially when
you consider jurisdiction variety. But reimbursing relays introduces even
more excitement, such as:
- Does such a relay operator end up in a different situation legally?
- Does the overall Tor network change legal categories in some country, e.g.
becoming a telecommunications service when it wasn't before?
- Does The Tor Project Inc incur new liabilities for offering this money?
Tor has a history of creating fascinating new challenges for legal scholars,
and this exit relay funding experiment will be no exception.
I believe if we position it correctly, we won't really change the legal context.
But I encourage people to investigate these questions for their jurisdiction.
----------------------------------------------------------------------
Next steps:
I'm going to do a short blog post pointing to this thread, since many interested
parties aren't on tor-relays yet.
Then I'll send individual emails to exit relay operators pointing them to
it and asking for their feedback (on the list or private, whichever they
prefer). I'll also try to get some sense of how much their hosting costs,
whether they'd want to participate in our experiment, whether they're in
a position to ramp up to a faster connection, etc.
Once we have some concrete facts about how many current exit relays want
to participate, how many new volunteers want to help, and how many ISPs could
handle more exit relays and at what prices, we'll be in a better position
to decide how to proceed.
--Roger
_______________________________________________
tor-relays mailing list
tor-relays[at]lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
----- End forwarded message -----
--
Eugen* Leitl <a
href="http://leitl.org">leitl</a>
http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820
http://www.ativel.com
http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Date: Tue, 24 Jul 2012 08:38:02 +0200
From: Eugen Leitl <eugen[at]leitl.org>
To: cypherpunks[at]al-qaeda.net, info[at]postbiota.org
Subject: Re: [tor-relays] Electronic surveillance on major tor exits
----- Forwarded message from Name Withheld <survivd[at]gmail.com> -----
From: Name Withheld <survivd[at]gmail.com>
Date: Mon, 23 Jul 2012 11:03:24 -1000
To: tor-relays[at]lists.torproject.org
Subject: Re: [tor-relays] Electronic surveillance on major tor exits
This is in response to something from Roger's email on funding exit relays,
but I didn't want to derail such an important conversation by responding
directly.
He mentioned:
"At the same time, much of our performance improvement comes from better
load balancing -- that is, concentrating traffic on the relays that can handle
it better. The result though is a direct tradeoff with relay diversity: on
today's network, clients choose one of the fastest 5 exit relays around 25-30%
of the time, and 80% of their choices come from a pool of 40-50 relays."
This has probably been discussed before, but the first thing that came to
my mind was, "how does this simplify surveillance of tor traffic flows?"
I know we badly need the performance improvement to continue moving Tor into
the mainstream, but when it comes at the cost of a huge amount of all tor
requests are exiting through a small subset of nodes, are we baking in a
serious vulnerability?
Most Tor users probably don't read the manual and follow best practices.
I'm sure we've all seen traffic where users are using google maps to find
directions from their home, or logging into their true-name mail accounts.
When you combine this "State of our Method" with a choke on the number [sentence
ends]
For monied countries that practice aggressive electronic surveillance (China,
Russia, and the larger western states), it becomes more and more tempting
to set up (or subvert) expensive, fast exits (with tshark and an SSL-stripper
on it) and be guaranteed significant amounts of traffic from people that
they view as having something to hide. And if the same routing calculus applies
to non-exit nodes, they can do the same thing on the non-exit layers, not
only improving their correlation attacks, but creating a plausible chance
of controlling some tunnels end-to-end. I don't think that's a good situation
for anybody other than the monitors.
I know that this is one of the reasons why "more nodes" is the largest everyday
push (I went from 1 to 3 in the last month), and "we're working on it," and
the node-funding push should help some of this, but I think it's important
to review what direction relay diversity is heading in the long-term when
the metrics start leaning in a certain way.
_______________________________________________
tor-relays mailing list
tor-relays[at]lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
----- End forwarded message -----
--
Eugen* Leitl <a
href="http://leitl.org">leitl</a>
http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820
http://www.ativel.com
http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
|