Re: [tor-dev] Remove NULL checks for *_free() calls

[Andreas Krey]

On Sun, 30 Aug 2015 23:24:07 +, Michael McConville wrote:
> Mansour Moufid wrote:
> > Michael McConville wrote:
...
> > >   error:
> > > -  if (x509) {
> > > -X509_free(x509);
> > > -x509 = NULL;
> > > -  }
...
> > But you did find some places they forgot to assign NULL after free.
> 
> For one reason or another, this isn't common practice.

It's not my practise, at least. I would definitely not use the
x509=NULL part when the end of the function is nigh (and doesn't
do anything with x509), and for me the =NULL is almost an indication
that x509 is used somehow lateron.

Also, if there were an x509=obj->x509 previously the correct thing
would be an obj->x509=NULL.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Where are the GetTor downloads (e.g. GitHub)?

[David Fifield]

On Mon, Aug 31, 2015 at 10:07:17PM -0300, ilv wrote:
> Hi David,
> 
> > 
> > My question is, is there a static URL on GitHub or similar that has the
> > latest downloads? That is, one that people can access even without
> > having used GetTor? Such a URL would be more useful than a typical
> > mirror for many users.
> > 
> 
> Yes, you can find the latest Tor Browser versions here:
> 
> https://github.com/gettorbrowser/dl
> 
> Although you will need to know which is the latest version in order to
> construct a direct download link. I might work on that by the end of my
> SoP if people find it useful.

Thanks, that's great!

> We are also trying to get an official account for it, but it's still on
> progress (https://trac.torproject.org/projects/tor/ticket/10692).

I think this is an important job, so I hope you get whatever support you
need to get official accounts.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Remove NULL checks for *_free() calls

[Zack Weinberg]

On Sun, Aug 30, 2015 at 10:37 PM, Mansour Moufid
 wrote:
> On Sun, Aug 30, 2015 at 8:13 PM, Michael McConville
>  wrote:
>
>> free() is specified to be NULL-safe, and I don't know of any
>> implementations that violate this.
>
> I think those NULL checks are meant to avoid double-free bugs.  If you
> assign NULL to a pointer after you free it and check all pointers
> before free, you avoid trying to free it again.

The thing you may not realize is that free(0) is specified to do
nothing.  This was in the 1989 C standard, so it should be safe to
rely on. I imagine running a Tor relay on SunOS 4.1.x would be a
terrible idea for reasons having nothing to do with the code (e.g.
predictable TCP sequence numbers).

As such, the check is always fully redundant; you get the effect
you're talking about by writing e.g.

X509_free(x509)
x509 = 0;

without the if.

> But you did find some places they forgot to assign NULL after free.

Unfortunately, setting pointers to 0 after free doesn't help avoid
double free bugs in practice.  Double frees happen when there are two
different pointers to the same memory block and both holders think
it's their responsibility to deallocate the object.  Clearing one
pointer does precisely nothing to the *other* pointer.

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

Re: [tor-dev] Remove NULL checks for *_free() calls

[tordev123]

 Original Message 
From: Zack Weinberg 
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Remove NULL checks for *_free() calls
Date: Mon, 31 Aug 2015 10:29:31 -0400

> > But you did find some places they forgot to assign NULL after free.
> 
> Unfortunately, setting pointers to 0 after free doesn't help avoid
> double free bugs in practice.  Double frees happen when there are two
> different pointers to the same memory block and both holders think
> it's their responsibility to deallocate the object.  Clearing one
> pointer does precisely nothing to the *other* pointer.

Double free is relatively harmless, you usually get a nice crash or noticable 
memory corruption.

What zeroing deleted pointers also gives you is protection against some 
dangling pointer bugs. Those can be very difficult to track down when the 
dangling pointer usage is only brief after the free and the bug only manifests 
itself every full moon.

Tor itself is small and fast enough to be run with a memory debugger. Someone 
is hopefully doing that and this is a moot point.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Where are the GetTor downloads (e.g. GitHub)?

[David Fifield]

Someone IRL asked me about mirrored downloads of Tor Browser on services
like GitHub. I know that such services are planned (or already
implemented?) for GetTor, and I know about these tickets:

Integrate cloud services that are not blocked in mainland China
https://bugs.torproject.org/14114

Automate upload of latest Tor Browser to cloud services
https://bugs.torproject.org/14744

Script to upload Tor Browser to Github
https://bugs.torproject.org/14835

My question is, is there a static URL on GitHub or similar that has the
latest downloads? That is, one that people can access even without
having used GetTor? Such a URL would be more useful than a typical
mirror for many users.

I was referred to Lantern's GitHub download page for comparison:
https://github.com/getlantern/lantern/releases/tag/latest
It has direct links to downloads under githubusercontent.com:
https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lantern-installer.exe
https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lantern-installer.dmg
https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lantern-installer-64.deb
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Onionoo users,

I just merged and deployed Onionoo protocol version 2.6 which adds two
new fields related to relay families and marks the current "family"
field as deprecated.

The idea of adding three fields for relay families is that we want to
support different use cases:

 - Atlas and Globe want to list all relays that a relay has configured
as its family ("effective_family" + "alleged_family").

 - Atlas and Globe may further want to mark ineffective family
relationships in red ("alleged_family") and effective family
relationships in blue ("effective_family").

 - Roster needs a family definition that includes family members that
are either in a direct family relationship with a relay
("effective_family") or that can be reached by following effective
family relationships ("indirect_family").

The current "family" field will stay available until Atlas and Globe
are updated.  If I should also wait for other clients to be updated,
please let me know.  We shouldn't wait too long, because all those
fingerprints increase the size of Onionoo results for everyone.

All the best,
Karsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJV5JJAAAoJEJD5dJfVqbCrlw0IAJ3NxbTE00M72EN/DLcJw2FD
/KMV2vpyQqi6tharTNGtZmZrm7HMZ/RTRhR5qlkmcKE18UDKxF0sX5ezT6+1R0QV
dNmUhYspP5cKcF6nqReMdd26dp4am6I5PSWqEmsMiC5vmxZbvp+B3st/9MNfYExE
qTQV8rkzsWIGTGSojxXLAjzjQwy9EBXdLrMrchH+jL0igbWmWLeshDSou/N0te1g
B6TBnA2LlRLKhLoAtwjjF1TREZN6Tkk9djQ8zHRjppZzu004I8bqPWiJ36qLDEqi
UVmuo5zrJUQxQEQ/n+AkRBoVNblVDY7/xeGh35ENhCzs+Ls75jCQzrkzx+7upPw=
=yTnY
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [Measurement Team] Next IRC meeting happens on Wednesday, Sep 2, 14:00 UTC in #tor-project

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello list,

This is an announcement/reminder that there will be an IRC meeting of
the Measurement Team on

  Wednesday, September 2, 2015, 14:00 UTC in #tor-project

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150902T14

Talk to you on Wednesday!

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJV5JhmAAoJEJD5dJfVqbCr69YH/3bpRZnJTfeavkfKKQDog8oq
J6uqlFyEKpSl4S2uSc6jT/gwDfUfUuEwWMpXrOUrRzrFSCSQQcMQF8Hiu6Mk5+SD
JN398wHGp2gTYp+y6xb6z8TzZfNmEEnJTcSAZtctQrB6kaj3jT29abMqIlsjQW9i
F91uCJLJVJWrBhYvqvvFhUbdDhn3S8HYCEx0u6B8Gdd8q1p/Swi5IuSvkpStBHZJ
diFGUsrj8HE73RKwOSl1gJcdLIGti3fayDhJZVVuTdV5weS4QF/I96XPJxnPwNqR
ek2azn2RteYSMX3vhglkp86z7jKFM9V4sgDXU72S8jp0wWaXXYmbgpY4+v3G7EY=
=9+9n
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

[nusenu]

> The current "family" field will stay available until Atlas and Globe
> are updated.  If I should also wait for other clients to be updated,
> please let me know.

Please do not forget about compass before removing the 'family' field,
thanks.



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] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

[nusenu]

> The current "family" field will stay available until Atlas and Globe
> are updated.  If I should also wait for other clients to be updated,
> please let me know.

If someone is actually going to adjust atlas/globe/compass it would be
great if that someone could also take this enhancement request [1] into
account - which might go hand in hand with the required change.

[1] https://trac.torproject.org/projects/tor/ticket/15417



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

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

[Philipp Winter]

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:


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.

Cheers,
Philipp
___
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] Where are the GetTor downloads (e.g. GitHub)?

[ilv]

Hi David,

> 
> My question is, is there a static URL on GitHub or similar that has the
> latest downloads? That is, one that people can access even without
> having used GetTor? Such a URL would be more useful than a typical
> mirror for many users.
> 

Yes, you can find the latest Tor Browser versions here:

https://github.com/gettorbrowser/dl

Although you will need to know which is the latest version in order to
construct a direct download link. I might work on that by the end of my
SoP if people find it useful.

We are also trying to get an official account for it, but it's still on
progress (https://trac.torproject.org/projects/tor/ticket/10692).

p.s.: GetTor is not sending links for the latest version (something is
broken with the fetch latest torbrowser script). I'm currently having
troubles with my internet connection, so I'll work on it once I have
access again.

Saludos.
--ilv



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?

[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