Re: [tor-dev] Should cloud-hosted relays be rejected?

[Sharif Olorin]

> I'm not talking about those providers hosting exit nodes. I'm talking about 
> general web sites and resources hosted by them and the traffic that goes 
> there.

I'm confused. You're worried about people hosting clearnet websites
with cloud hosting providers? Or non-exit relays?

Sharif

-- 
OpenPGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[tordev123]

From: nusenu <nus...@openmailbox.org>
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Tue, 1 Sep 2015 19:23:35 +0200

> > It has other benefits. Those big providers see a huge amount of exit
> > traffic and can potentially do correlation against that.
>
> I disagree on 'huge'.
> If you worry about i.e. Amazon hosting to much exit bandwidth you have
> to worry about many other* ASes first, and even then, banning them all
> completely (exit prob = 0) isn't probably a wise strategy.

I'm not talking about those providers hosting exit nodes. I'm talking about 
general web sites and resources hosted by them and the traffic that goes there.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[tordev123]

From: Sharif Olorin <s...@tesser.org>
To: tor-dev <tor-dev@lists.torproject.org>
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Wed, 02 Sep 2015 08:32:58 +

> > I'm not talking about those providers hosting exit nodes. I'm talking about 
> > general web sites and resources hosted by them and the traffic that goes 
> > there.
>
> I'm confused. You're worried about people hosting clearnet websites
> with cloud hosting providers? Or non-exit relays?

Correlation between all kinds of relay traffic and clearnet traffic. Entry 
traffic would be the worst, allowing end-to-end correlation.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[Michael McConville]

tordev...@safe-mail.net wrote:
> > > I'm not talking about those providers hosting exit nodes. I'm
> > > talking about general web sites and resources hosted by them and
> > > the traffic that goes there.
> >
> > I'm confused. You're worried about people hosting clearnet websites
> > with cloud hosting providers? Or non-exit relays?
> 
> Correlation between all kinds of relay traffic and clearnet traffic.
> Entry traffic would be the worst, allowing end-to-end correlation.

Also remember that the circuit data contains far more information than
packet timing, and that it may not be sufficiently secure when on a VM
or cloud platform.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[nusenu]

>> I don't think banning GCE, AWS and MS Azure is an efficient method
>> to
>>> significantly increase the cost of attacks because it is trivial
>>> for an attacker to quickly spin up "a large number of disposable
>>> machines" at other ISPs as well.
> It has other benefits. Those big providers see a huge amount of exit
> traffic and can potentially do correlation against that.

I disagree on 'huge'.
If you worry about i.e. Amazon hosting to much exit bandwidth you have
to worry about many other* ASes first, and even then, banning them all
completely (exit prob = 0) isn't probably a wise strategy.







*)
+---+-+
| exit_prob | AS_name |
+---+-+
| 9.261 | OVH SAS |
| 7.629 | Avira B.V.  |
| 6.239 | SOFTplus Entwicklungen GmbH |
| 5.306 | Hetzner Online AG   |
| 4.013 | UK2 - Ltd   |
| 3.563 | LeaseWeb B.V.   |
| 3.316 | Voxility S.R.L. |
| 3.171 | Init7 (Switzerland) Ltd.|
| 2.454 | NFOrce Entertainment BV |
| 2.232 | CYBERDYNE   |
| 2.174 | Association TETANEUTRAL.NET |
| 2.111 | ALISTAR SECURITY SRL|
| 2.018 | 31173 Services AB   |
| 1.852 | PlusServer AG   |
| 1.831 | root SA |
| 1.713 | ONLINE S.A.S.   |
| 1.703 | QuadraNet, Inc  |
| 1.475 | ISPpro Internet KG  |
| 1.441 | Foreningen for digitala fri- oc |
| 1.427 | BlazingFast LLC |
| 1.377 | rrbone UG (haftungsbeschraenkt) |
| 1.288 | IP-EEND BV  |
| 1.249 | WEDOS Internet, a.s.|
| 1.240 | Abovenet Communications, Inc|
| 1.181 | The Calyx Institute |
| 1.169 | myLoc managed IT AG |
| 1.024 | Digicube sas|
| 0.871 | Amazon.com, Inc.| << Amazon
| 0.817 | Hurricane Electric, Inc.|
| 0.799 | University of Michigan  |
+---+-+
onionoo data from 2015-09-01 07:00:00



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[tordev123]

From: nusenu <nus...@openmailbox.org>
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Tue, 1 Sep 2015 00:58:05 +0200

> I don't think banning GCE, AWS and MS Azure is an efficient method to
> significantly increase the cost of attacks because it is trivial for an
> attacker to quickly spin up "a large number of disposable machines" at
> other ISPs as well.

It has other benefits. Those big providers see a huge amount of exit traffic 
and can potentially do correlation against that.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[Michael McConville]

tordev...@safe-mail.net wrote:
> > I don't think banning GCE, AWS and MS Azure is an efficient method
> > to significantly increase the cost of attacks because it is trivial
> > for an attacker to quickly spin up "a large number of disposable
> > machines" at other ISPs as well.
> 
> It has other benefits. Those big providers see a huge amount of exit
> traffic and can potentially do correlation against that.

Agreed. We (people involved in documenting relay operation) should also
spend more time promoting dedicated servers. VMs have similar problems,
just at a smaller scale.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[Tim Wilson-Brown - teor]

> On 1 Sep 2015, at 07:45, Philipp Winter  wrote:
> 
> We sometimes see attacks from relays that are hosted on cloud platforms.
> I have been wondering if the benefit of having cloud-hosted relays
> outweighs the abuse we see from them.
> 
> To get an idea of the benefit, I analysed the bandwidth that is
> contributed by cloud-hosted relays.  I first obtained the network blocks
> owned by three cloud providers (Amazon AWS, Google Cloud, Microsoft
> Azure), and determined the percent of bandwidth they contributed in July
> 2015.  The results show that there were typically ~200 cloud-hosted
> relays online:
> 
> The spike shortly after hour 200 was caused by a lot of Amazon relays
> named "DenkoNet".  The spike at the very beginning was caused by a
> number of relays that might very well belong together, too, based on
> their uptime pattern.
> 
> What counts, however, is bandwidth.  Here's the total bandwidth fraction
> contributed by cloud-hosted relays over July 2015:
> 
> There were no Google Cloud relays to contribute any bandwidth.  Amazon
> AWS-powered relays contributed the majority of bandwidth, followed by
> Microsoft Azure-powered relays.  Here's a summary of the time series in
> percent:
> 
>  Min.  Mean  Median  Max.
>  0.2%  0.8%  0.79%   1.5%
> 
> In an average consensus in July 2015, cloud-hosted relays contributed
> only around 0.8% of bandwidth.  Note, however, that this is just a lower
> bound.  The netblocks I used for the analysis could have changed, and I
> didn't consider providers other than Google, Amazon, and Microsoft.
> 
> There are also cloud-hosted bridges.  Tor Cloud, however, has shut down,
> and the number of EC2 bridges is declining:
> 

Can we preserve cloud-hosted bridges independently of whatever we decide to do 
to cloud-hosted relays?

> The harm caused by cloud-hosted relays is more difficult to quantify.
> Getting rid of them also wouldn't mean getting rid of any attacks.  At
> best, attackers would have to jump through more hoops.
> 
> If we were to decide to permanently reject cloud-hosted relays, we would
> have to obtain the netblocks that are periodically published by all
> three (and perhaps more) cloud providers:
> 
> 
> 
> 
> Note that this should be done periodically because the netblocks are
> subject to change.

I wonder about the impact of this proposal on Tor research and on Tor 
developers.

Some may consider it a benefit if researchers have to take more steps to 
interact with the Tor network.

I wonder how many Tor developers develop using cloud machines, and whether it’s 
a benefit for them to be able to test changes on the live Tor network, or a 
drawback.
I test my changes on Linux using a cloud machine, and have used it at times to 
ensure that my changes don’t break when deployed on the live network. (I don’t 
do this at home, for both legal and connectivity reasons.)

Of course, I use chutney to test my changes on a test network, before I use 
them on the live network.
So that’s another option for both researchers and developers.
As an aside, we're working on making chutney easier to use, and we’re getting 
there incrementally.
Here is a very rough draft plan:
https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide 


Of course, if researchers or developers or others really need a machine, they 
can move to a smaller cloud provider. This has benefits for diversity, and 
reduces what Google, Amazon, and Microsoft can know about Tor.

Tim (teor)

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[nusenu]

> We sometimes see attacks from relays that are hosted on cloud platforms.
> I have been wondering if the benefit of having cloud-hosted relays
> outweighs the abuse we see from them.

I don't think banning GCE, AWS and MS Azure is an efficient method to
significantly increase the cost of attacks because it is trivial for an
attacker to quickly spin up "a large number of disposable machines" at
other ISPs as well.

Detecting new groups of relays in a single AS that all sign up in a
short timeframe is trivial (DocTor does and did that already [1][2],
OrNetRadar [3] does it as well).

Should you decide to continue generally blacklisting entire ISPs/ASes/IP
ranges:

Please add that info (including the banned ISPs/ASes/IP ranges) to the
documentation (i.e. relay setup guides [4])  so volunteers don't waste
their time and money to setup blacklisted relays [5].


[1]
https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005955.html
[2]
https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005974.html
[3] https://lists.riseup.net/www/info/ornetradar
http://news.gmane.org/gmane.network.onion-routing.ornetradar
[4] https://www.torproject.org/getinvolved/relays.html.en
[5]
https://lists.torproject.org/pipermail/tor-relays/2015-August/007655.html



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[Tim Wilson-Brown - teor]

>> On 1 Sep 2015, at 07:45, Philipp Winter > > wrote:
>> 
>> The harm caused by cloud-hosted relays is more difficult to quantify.
>> Getting rid of them also wouldn't mean getting rid of any attacks.  At
>> best, attackers would have to jump through more hoops.
>> 
>> If we were to decide to permanently reject cloud-hosted relays, we would
>> have to obtain the netblocks that are periodically published by all
>> three (and perhaps more) cloud providers:
>> > >
>> > >
>> > >
>> 
>> Note that this should be done periodically because the netblocks are
>> subject to change.

> On 1 Sep 2015, at 08:58, nusenu  wrote:
> 
> Should you decide to continue generally blacklisting entire ISPs/ASes/IP
> ranges:
> 
> Please add that info (including the banned ISPs/ASes/IP ranges) to the
> documentation (i.e. relay setup guides [4])  so volunteers don't waste
> their time and money to setup blacklisted relays [5].
> 
> [4] https://www.torproject.org/getinvolved/relays.html.en 
> 
> [5]
> https://lists.torproject.org/pipermail/tor-relays/2015-August/007655.html 
> 
If the blocked IP ranges are going to become numerous, and change frequently, 
why not create a tool that volunteer relay operators can use to check an IP 
address?

Tim (teor)


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[isis]

Tim Wilson-Brown - teor transcribed 11K bytes:
> 
> > On 1 Sep 2015, at 07:45, Philipp Winter  wrote:
> > 
> > There are also cloud-hosted bridges.  Tor Cloud, however, has shut down,
> > and the number of EC2 bridges is declining:
> > 
> 
> Can we preserve cloud-hosted bridges independently of whatever we decide to
> do to cloud-hosted relays?

Tor Cloud is deprecated for several reasons, [0] and it's possible that those
bridges haven't been getting software updates. [1] Those bridges should
probably die.  But yes, in theory, if we decided to block cloud relays, we
technically could preserve those bridges.  If anything, I'd be more in favour
of doing this the other way around: ban those EC2 bridges and keep the cloud
relays (but perhaps create more/better automated scans to detect misbehaviour).

> I wonder about the impact of this proposal on Tor research and on Tor 
> developers.
> 

The Tor Project does have an EC2 account that some Tor developers have access
to, but we don't ever run non-TestingTorNetwork relays/bridges on it.  Also,
in general, (paid) Tor developers aren't supposed to run relays, due to
concerns that doing so could possibly be legally interpreted as "The Tor
Project runs the Tor network".

However, I agree with your concerns that this change might make it more
difficult for other researchers to study tor (hopefully, ethically).

[0]: 
https://blog.torproject.org/blog/tor-cloud-service-ending-many-ways-remain-help-users-access-uncensored-internet
[1]: https://trac.torproject.org/projects/tor/ticket/11502

-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[isis]

Philipp Winter transcribed 2.6K bytes:
>
> The harm caused by cloud-hosted relays is more difficult to quantify.
> Getting rid of them also wouldn't mean getting rid of any attacks.  At
> best, attackers would have to jump through more hoops.
> 

Does anyone know which attacks were carried out via relays running on cloud
platforms?

The only one I remember was the "One cell is enough" [0] tagging attack in
2009, but IIRC, their malicious/colluding exit was run on PlanetLab (also, via
the nature of the attack, it probably wouldn't have caused any harm to real
users).  Were there any others?

[0]: https://blog.torproject.org/blog/one-cell-enough

-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[grarpamp]

My sense of tor-relays is that "end users" as relay operators
(which presumably operate most relays, with places like
torservers doing the rest) just go looking for VPS accounts.
ie: compute platforms aren't their thing.

Which leaves the only real users of compute to be attackers
and researchers. The former we don't want, the latter we do.

Blocking compute seems fine based on its tiny resource contribution.
Researchers could come to Tor to unblock and share their project
though that could be discouraging, and there's currently no mechanism
for that.
Attackers often need lots of IP's and programmability at good cost,
which may not readily exist with VPS. Govts excepted.

On Mon, Aug 31, 2015 at 6:58 PM, nusenu  wrote:
> Detecting new groups of relays in a single AS that all sign up in a

Blocking compute may limit the ability to openly survey the attack
space by forcing it to hide more.

> Please add that info (including the banned ISPs/ASes/IP ranges) to the
> documentation (i.e. relay setup guides [4])  so volunteers don't waste
> their time and money to setup blacklisted relays [5].

+1
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Should cloud-hosted relays be rejected?

[Sharif Olorin]

> Does anyone know which attacks were carried out via relays running on cloud
> platforms?

The Lizard Squad thing from last year was substantially Google Cloud
(GAE/GCE), if I recall correctly (there's a list from consensus-health
here[0]). Lots of research takes place on EC2, but it doesn't seem to
be a sybil-magnet - after all, there are cheaper providers who will
ask fewer questions (e.g., OVH, which has a much bigger consensus
fraction).

[0] 
https://lists.torproject.org/pipermail/tor-consensus-health/2014-December/005381.html

-- 
OpenPGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev