date:20170102

My bet is that the recorded IP address dates back to the days when your node
was an exit. Naturally the Russian hackers have used Tor, probably in tandem
with a VPN - it would have been stupid of them not to, and stupid they are
not. 
 
And you are right - now the US government will blame Tor exit operators for
the sheer stupidity of email operators in political shops such as DNC that
do not force their users to encrypt email end to end. PGP is too much
trouble for them.
 
If I am right there is nothing you can do now, you have already closed the
exit. If they pressure you, migrate your relay to another IP.
 
Rana
 
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of Dr Gerard Bulger
Sent: Monday, January 02, 2017 10:15 AM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Grizzly Steppe
 
I ran an exit node, but gave up after too many abuse reports that annoyed my
ISP.  So I turned al exit ports off, and reports stopped as a rely.After
months and many terabytes of data I get an abuse complaint that my tor IP
has been used for espionage. 
 
"NCSC have been made aware of a report and associated malicious indicators
released by the United States Government relating to malicious cyber
activity. A copy if the report and indicators can be found at the following
link:-
https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio
us-Cyber-Activity
Details within this report indicate network assets which may have been
compromised or associated with malicious activity. We have identified the
following IP address from this report as x.x.x.x   As a minimum, it is
recommended that you check systems and any available logs concerned with the
above addresses for indications of malicious activity"

There are no other details as to HOW my tor relay is being used.  The
espionage seems to relay on the stupidity of recipients on receiving emails
asking for passwords.  I am not sure HOW ISP or relay service can stop that.
Or is it that my relay was being used to transfer the data?
 
I assume my IP was found by way of a DNS leak which I need to look into.
There is nothing else I can do as a relay to stop this or is there?
 
Gerry
 
 
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

On 01/02/2017 12:53 AM, Rana wrote:
> @Mirimir
>>> This is not Blockchain where hundreds of thousands of greedy selfish 
>>> genes are working together for non-collusion.  A practically zero- 
>>> effort collusion of already fully cooperating FIVE EYE agencies (US, 
>>> UK, Canada, Australia, New Zealand) is needed to sprinkle several tens 
>>> of rogue relays every month all over the globe, hosted at unsuspected 
>>> hosters, looking perfectly bona fide. All they need is maintain some 
>>> bandwidth and stability (why not?) and wait 70 days and - hop! - they 
>>> are guards.
> 
>> That seems plausible. I don't know how the community of relay operators
>> works. But I suspect that, if you're right, many known and trusted relay
>> operators must be covert operatives. While that's not impossible, it
>> would represent a huge investment.
> 
> I've been through this already, and made a calculation of the completely
> negligible - in government terms - amount required to pay for hosting
> 4000 powerful nodes that are indiscernible from honest relays and are
> scattered all over the world. A huge investment is emphatically NOT
> required for this. As to operatives, I see no reason why a single
> employee could not control 500 rogue relays from a single $1000 PC.  
> Say, spending her day revisiting 25 relays daily, doing maintenance. 
> That's assuming zero automation. With some automation software (say, 
> flagging relays that need attention, most of them don't most of the 
> time), a single employee could control the entire 7000. Where's 
> the "huge investment"?

Yes, there's no huge investment in equipment or operator time. But it's
my impression that there's a community of relay operators. Who know each
other. And I doubt that an appreciable percentage of entry guards are
run by anonymous cowards, such as myself ;)

If that's the case -- and I'd appreciate knowledgeable comment -- many
known and trusted relay operators must be covert operatives. I expect
that running a long-term covert operation isn't cheap. But upon
reflection, it would arguably not cost more than a hundred million USD
per year. So maybe so.

> Tor model breaks down when facing a modest government adversary for the
> simple reason that having only 7000 relays total, with a minority of
> them carrying most of the traffic, invites cheap infiltration and
> takeover by state adversaries.

Yeah, that's a problem :(

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

Re: [tor-relays] Grizzly Steppe

2017-01-02 Thread rush23

By the way Jerry Gamblin checked the list against the tor exit nodes and found 
191 that have been used in this hacking...
There you can find his thread with the whole listing..

https://twitter.com/JGamblin/status/814627227656683521

Regards 
0x23

Am 2. Januar 2017 09:39:50 MEZ schrieb tor-relays-requ...@lists.torproject.org:
>Send tor-relays mailing list submissions to
>   tor-relays@lists.torproject.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>or, via email, send a message with subject or body 'help' to
>   tor-relays-requ...@lists.torproject.org
>
>You can reach the person managing the list at
>   tor-relays-ow...@lists.torproject.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of tor-relays digest..."
>
>
>Today's Topics:
>
>   1. Re: Grizzly Steppe (Rana)
>
>
>--
>
>Message: 1
>Date: Mon, 2 Jan 2017 10:39:40 +0200
>From: "Rana" 
>To: 
>Subject: Re: [tor-relays] Grizzly Steppe
>Message-ID: <03ed01d264d3$c4700b40$4d5021c0$@gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>My bet is that the recorded IP address dates back to the days when your
>node
>was an exit. Naturally the Russian hackers have used Tor, probably in
>tandem
>with a VPN - it would have been stupid of them not to, and stupid they
>are
>not. 
> 
>And you are right - now the US government will blame Tor exit operators
>for
>the sheer stupidity of email operators in political shops such as DNC
>that
>do not force their users to encrypt email end to end. PGP is too much
>trouble for them.
> 
>If I am right there is nothing you can do now, you have already closed
>the
>exit. If they pressure you, migrate your relay to another IP.
> 
>Rana
> 
>From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On
>Behalf
>Of Dr Gerard Bulger
>Sent: Monday, January 02, 2017 10:15 AM
>To: tor-relays@lists.torproject.org
>Subject: [tor-relays] Grizzly Steppe
> 
>I ran an exit node, but gave up after too many abuse reports that
>annoyed my
>ISP.  So I turned al exit ports off, and reports stopped as a rely.   
>After
>months and many terabytes of data I get an abuse complaint that my tor
>IP
>has been used for espionage. 
> 
>"NCSC have been made aware of a report and associated malicious
>indicators
>released by the United States Government relating to malicious cyber
>activity. A copy if the report and indicators can be found at the
>following
>link:-
>https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio
>us-Cyber-Activity
>Details within this report indicate network assets which may have been
>compromised or associated with malicious activity. We have identified
>the
>following IP address from this report as x.x.x.x   As a minimum, it is
>recommended that you check systems and any available logs concerned
>with the
>above addresses for indications of malicious activity"
>
>There are no other details as to HOW my tor relay is being used.  The
>espionage seems to relay on the stupidity of recipients on receiving
>emails
>asking for passwords.  I am not sure HOW ISP or relay service can stop
>that.
>Or is it that my relay was being used to transfer the data?
> 
>I assume my IP was found by way of a DNS leak which I need to look
>into.
>There is nothing else I can do as a relay to stop this or is there?
> 
>Gerry
> 
> 
> 
>-- next part --
>An HTML attachment was scrubbed...
>URL:
><http://lists.torproject.org/pipermail/tor-relays/attachments/20170102/5fcbf7d5/attachment.html>
>
>--
>
>Subject: Digest Footer
>
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>--
>
>End of tor-relays Digest, Vol 72, Issue 4
>*

-- 
Diese Nachricht wurde von unterwegs versendet.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Grizzly Steppe

2017-01-02 Thread Jim

Dr Gerard Bulger wrote:

I ran an exit node, but gave up after too many abuse reports that
annoyed my ISP. So I turned al exit ports off, and reports stopped as a
rely.After months and many terabytes of data I get an abuse
complaint that my tor IP has been used for espionage.

“NCSC have been made aware of a report and associated malicious
indicators released by the United States Government relating to
malicious cyber activity. A copy if the report and indicators can be
found at the following link:-
https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicious-Cyber-Activity

Details within this report indicate network assets which may have been
compromised or associated with malicious activity. We have identified
the following IP address from this report as x.x.x.x As a minimum, it
is recommended that you check systems and any available logs concerned
with the above addresses for indications of malicious activity”

There are no other details as to HOW my tor relay is being used. The
espionage seems to relay on the stupidity of recipients on receiving
emails asking for passwords. I am not sure HOW ISP or relay service can
stop that. Or is it that my relay was being used to transfer the data?

Like Rana, I also wondered if perhaps this traces back to when you ran
an exit node. I haven't taken the time (and probably don't have the
skill) to analyze what is in that report, but others have. You might
find Security Week's write-up helpful:

http://www.securityweek.com/us-attributes-election-hacks-russian-threat-groups

In particular:

While some industry experts applauded the GRIZZLY STEPPE
indicators provided by the U.S. Government, some experts urged
caution for those quickly integrating them into their cyber
defense measures.

"Be careful using the DHS/FBI GRIZZLY STEPPE indicators. Many
are VPS, TOR relays, proxies, etc. which will generate lots
of false positives," Robert M. Lee, founder and CEO of Dragos
Security and a former member of the intelligence community,
Tweeted.

I suspect you are among the "lots of false positives".

I assume my IP was found by way of a DNS leak which I need to look
into. There is nothing else I can do as a relay to stop this or is there?

If this happened when you ran an exit node then you don't need to look
for a DNS leak (I don't see how that would pertain to a relay, anyway)
and you wouldn't need to worry about stopping it (you already have by
not being an exit).

Of course, it is possible you node was actually compromised but I think
Occam's razor argues against that.

Jim

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

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Aeris

> > Tor model breaks down when facing a modest government adversary for the
> > simple reason that having only 7000 relays total, with a minority of
> > them carrying most of the traffic, invites cheap infiltration and
> > takeover by state adversaries.
> 
> Yeah, that's a problem :(

That’s a theorical problem.
Currently, most of the major guard operators are well known people and no 
doubt they’re not engaged with three-letter agencies.


https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Zwiebel

> Currently, most of the major guard operators are well known people
are you sure?

- Zwiebel, 33rd on that list
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

Sorry

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Aeris
Sent: Monday, January 02, 2017 3:56 PM

>Currently, most of the major guard operators are well known people and no 
>doubt they’re not engaged with three-letter agencies.
>https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt

I do not know how to interpret this table. How many guards are there at any 
given time?


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

Re: [tor-relays] How can we trust the guards?

Known to whom? Is there a Tor police that researches "unknown" guards? How do 
you measure "known"? How do they become "known"? Something akin to key signing 
parties? Secret meetings in Munich biergartens?

Conversely, if someone installs a high performance relay, during the first 70 
days is there a secret police investigation giving the operator a clean bill of 
health or conversely marking her as a rogue?

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Zwiebel
Sent: Monday, January 02, 2017 4:19 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] How can we trust the guards?

> Currently, most of the major guard operators are well known people
are you sure?

- Zwiebel, 33rd on that list
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Aeris

> I do not know how to interpret this table. How many guards are there at any
> given time?

Currently, we have 2442 guards.
This number is not fix but vary each days depending of community efforts to 
maintain stable nodes with enough bandwidth.

> Known to whom? Is there a Tor police that researches "unknown" guards? How
> do you measure "known"? How do they become "known"? Something akin to key
> signing parties? Secret meetings in Munich biergartens?

Major operators are not anonymous and closed to the Tor project or others 
privacy aware association.
On the top guard operator, I see Tor developers, EFF members, privacy aware 
email provider, privacy aware hosting provider, scientists, known hacktivists, 
people active on this list, VPN providers… Not at all related to three-letters 
agencies (or we must begin to fear about global conspiracy able to subponea 
all those kinds of people/association/companies on this planet during 
decades…).

> Conversely, if someone installs a high performance relay, during the first
> 70 days is there a secret police investigation giving the operator a clean
> bill of health or conversely marking her as a rogue?

All nodes are watched permanently by a bunch of tools :
https://trac.torproject.org/projects/tor/wiki/doc/
ReportingBadRelays#Doyouactivelylookforbadrelays

During the 70d, bad behaviour will be detected and associated nodes banned.
And if we don’t detect anything bad during this time, so even if those nodes 
are controled by bad guys, we don’t care because they help the network !
Tor node selection for circuits will address this trouble and avoid you to use 
more than 1 of their nodes in the same circuit, preventing any anonymity 
problem.
The best we can do in such case is to contact the operator to speak about 
diversity problem and to ask for shuting down some nodes if we consider he 
controls more consensus he should.

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Toralf Förster

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/02/2017 04:32 PM, Aeris wrote:
> Tor node selection for circuits will address this trouble and avoid you to 
> use 
> more than 1 of their nodes in the same circuit, preventing any anonymity 
> problem.
*any* sounds a little bit too optimistic IMO, but it reduces the risk of being 
deanonymized (always under the assumption of the threat model).

- -- 
Toralf
PGP: C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iHYEAREIAB4FAlhqdvMXHHRvcmFsZi5mb2Vyc3RlckBnbXguZGUACgkQxOrN3gB2
6U7jvQD/YXmvbeuG4bmj7xHSJsJsoUNcVxYhwU2s6O4oiVhyG1MA/RWDx4ail6j7
tw8X93LQvIsNiUJsQO1Rxt/0HGmOj4U0
=jfUR
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Aeris

> *any* sounds a little bit too optimistic IMO, but it reduces the risk of
> being deanonymized (always under the assumption of the threat model).

If family name is correctly defined, Tor ensure you will only use one of those 
nodes on your circuits.

If family name not correctly defined, Tor project will try to contact operator 
to define one :

https://lists.torproject.org/pipermail/tor-relays/2016-December/02.html

https://lists.torproject.org/pipermail/tor-relays/2016-December/011402.html

https://lists.torproject.org/pipermail/tor-relays/2016-December/011416.html
Without action, nodes may be blacklisted if suspicious. And even if not, /16 
restriction will apply, and never 2 nodes on the same /16 will be used.

If attacker nodes have no family name and not in few /16, we are typically in 
a sybil attack and Tor network tools might report the trouble.
https://gitweb.torproject.org/user/phw/sybilhunter.git/

https://lists.torproject.org/pipermail/tor-consensus-health/2014-November/
005252.html

Sure, all those protections are not perfect. Adding new relays few at a time 
to stay under the sybil attack detection level, without common pattern (IP, /
16, node name, AS…), during a lot of time to control most of the nodes may 
remain undetected.
But currently, seems not the case at least for guard and exit which are well 
known or documented most of the time or at least for the biggest part of the 
consensus.

More than money, such undetected attack requires global organisation to 
subvert and subponea enough people (network admin, sys admin, companies, 
hardware hosting…) to build it. It's more planetary conspiracy theory than 
anything else.

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Andreas Krey

On Mon, 02 Jan 2017 08:28:52 +, Rana wrote:
...
> That US agencies are actively working to destroy anonymity of (hopefully only 
> selected, but who knows?) Tor users is an undisputable fact. Your implicit 
> assumption that Russia is also attacking Tor is, however, unfounded.

Now, what is the reasoning behind that?

> There is, however, ZERO evidence that they are going head to head with 
> America doing that.

Is there any evidence that America is doing this?
(Outside the snowden leaks, o/c, because they don't cover russia.)

> I believe that what is needed is changing Tor to accommodate a lot of small 
> relays running by a very large number of volunteers, and to push real traffic 
> through them.

And where do you want to get these?

Andreas

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

Re: [tor-relays] How can we trust the guards?

2017-01-02 Thread Gumby TORZone

Just to play devils advocate here - when a single hacker can control tens of
thousands of devices in a botnet - just how easy would it be for a "state"
agency to control a few hundred tor nodes? We can always assume, possibly to our
own demise, that they utilize it to some degree themselves, and leave tor alone,
mostly.

However, if memory serves me correctly (debatable some days), a couple years
ago, didn't part of Anonymous work with some of the developers at Mozilla -
where when they hit certain Silk Road onion sites they were offered a
"necessary" pervert only TBB update that allowed their "true" IP to be found -
then doxxed each one and posted the list of child porn frequenters from that?
Based on a scenario such as that - who CAN we trust? Who is actually "in the
circle of trust" - and who ain't?

Gumby
"We're from the government, and we're here to help you!"

> On January 2, 2017 at 12:44 PM Andreas Krey  wrote:
> 
> On Mon, 02 Jan 2017 08:28:52 +, Rana wrote:
> ...
> > That US agencies are actively working to destroy anonymity of (hopefully
> > only selected, but who knows?) Tor users is an undisputable fact. Your
> > implicit assumption that Russia is also attacking Tor is, however,
> > unfounded.
> 
> Now, what is the reasoning behind that?
> 
> > There is, however, ZERO evidence that they are going head to head with
> > America doing that.
> 
> Is there any evidence that America is doing this?
> (Outside the snowden leaks, o/c, because they don't cover russia.)
> 
> > I believe that what is needed is changing Tor to accommodate a lot of small
> > relays running by a very large number of volunteers, and to push real
> > traffic through them.
> 
> And where do you want to get these?
> 
> Andreas
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

On 01/02/2017 06:56 AM, Aeris wrote:
>>> Tor model breaks down when facing a modest government adversary for the
>>> simple reason that having only 7000 relays total, with a minority of
>>> them carrying most of the traffic, invites cheap infiltration and
>>> takeover by state adversaries.
>>
>> Yeah, that's a problem :(
> 
> That’s a theorical problem.
> Currently, most of the major guard operators are well known people and no 
> doubt they’re not engaged with three-letter agencies.
> 
>   
> https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt

Good. That's what I had assumed. So a major infiltration would be hard
to hide. Those "well known people" would need to be covert operatives.
And deploying covert operatives long-term is nontrivial.

> Regards,
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] zwieb...@online.de relays: MyFamily update required (new relay added)

2017-01-02 Thread nusenu

Hi zwiebeln,

thanks for adding your 31. relay nicknamed 'hecker' !

Please do not forget to update your MyFamily on all relays.

Tipp:
If you are planing to grow beyond your 31 relays I recommend you
preemptively generate the keys for your upcoming relays so you don't
have to touch all other relays everytime you add a single relay (to the
MyFamily line).


++--+-++
| first_seen | nickname | IP  | eMyFamilyCount |
++--+-++
| 2016-04-11 | chisinau2onion   | 178.17.170.179  |30. |
| 2016-05-14 | rigaonion| 195.123.209.184 |30. |
| 2016-07-03 | chisinau2onion2  | 178.17.170.179  |30. |
| 2016-08-28 | budweisonion4| 37.157.193.161  |30. |
| 2016-09-10 | budweisonionb4   | 37.157.193.161  |30. |
| 2016-09-16 | budweisonion5| 89.221.209.100  |30. |
| 2016-09-18 | budweisonion | 37.157.196.97   |30. |
| 2016-09-27 | budweisonionb| 37.157.196.97   |30. |
| 2016-09-27 | budweisonion5b   | 89.221.209.100  |30. |
| 2016-11-12 | montrealonion| 144.217.60.211  |30. |
| 2016-11-12 | strasbourgonion  | 213.32.55.239   |30. |
| 2016-11-14 | alsaceonion  | 149.202.238.204 |30. |
| 2016-11-15 | milanoonion  | 158.58.170.150  |30. |
| 2016-11-15 | quebeconion  | 144.217.60.239  |30. |
| 2016-11-28 | goetheb  | 178.17.170.212  |30. |
| 2016-11-28 | schiller | 178.17.170.27   |30. |
| 2016-11-28 | goethe   | 178.17.170.212  |30. |
| 2016-11-28 | schillerb| 178.17.170.27   |30. |
| 2016-12-05 | heine| 51.15.53.83 |30. |
| 2016-12-05 | bsdonion | 46.182.18.214   |30. |
| 2016-12-05 | thueronionb  | 46.182.18.29|30. |
| 2016-12-05 | thueronion   | 46.182.18.29|30. |
| 2016-12-05 | heineb   | 51.15.53.83 |30. |
| 2016-12-16 | budapestonion| 88.151.99.224   |30. |
| 2016-12-18 | milanoonionb | 158.58.170.150  |30. |
| 2016-12-18 | humboldt | 185.14.29.129   |30. |
| 2016-12-18 | quebeconionb | 144.217.60.239  |30. |
| 2016-12-18 | strasbourgonionb | 213.32.55.239   |30. |
| 2016-12-18 | montrealonionb   | 144.217.60.211  |30. |
| 2016-12-18 | alsaceonionb | 149.202.238.204 |30. |
| 2017-01-02 | hecker   | 46.182.19.219   |   NULL |
++--+-++
31 rows



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

[tor-relays] _AceLewis tor relays: please specify 'MyFamily' in your torrc

2017-01-02 Thread nusenu

Hi Lewis,

thanks for adding your 6 tor relays to the network!

Please do not forget to set the MyFamily parameter in your torrc
configuration to tell clients your relays belong to a single operator.


If you need help with the MyFamily option let us know.


thanks,
nusenu





++---+-++
| first_seen | nickname  | IP  | eMyFamilyCount |
++---+-++
| 2016-12-27 | acelewis4 | 138.197.131.213 |   NULL |
| 2016-12-27 | acelewis  | 188.226.129.48  |   NULL |
| 2016-12-27 | acelewis3 | 207.154.205.226 |   NULL |
| 2016-12-27 | acelewis5 | 139.59.160.33   |   NULL |
| 2016-12-27 | acelewis6 | 139.59.42.48|   NULL |
| 2016-12-27 | acelewis2 | 139.59.252.170  |   NULL |
++---+-++





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

Re: [tor-relays] How can we trust the guards?

On 01/01/2017 11:28 PM, Rana wrote:

> I believe that what is needed is changing Tor to accommodate a
> lot of small relays running by a very large number of volunteers,
> and to push real traffic through them.

Alternately, you need lots of small relays, running (with plausible
deniability) on IoT devices. Mirai-style. Using covert channels (packet
timing etc). Tor Project would never do that, I know. But eventually, it
might come down to that.

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

Re: [tor-relays] How can we trust the guards?


> On 3 Jan 2017, at 11:46, Mirimir  wrote:
> 
>> I believe that what is needed is changing Tor to accommodate a
>> lot of small relays running by a very large number of volunteers,
>> and to push real traffic through them.
> 
> Alternately, you need lots of small relays, running (with plausible
> deniability) on IoT devices. Mirai-style. Using covert channels (packet
> timing etc). Tor Project would never do that, I know. But eventually, it
> might come down to that.

I think you are talking about a different network, which is not Tor as
currently designed, implemented, and deployed.

In particular, how do you get decent throughput, reliability, and low-
latency out of tens of thousands of devices?
This is an open research problem, which the Tor design does not solve.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?



On 01/02/2017 06:08 PM, teor wrote:
> 
>> On 3 Jan 2017, at 11:46, Mirimir  wrote:
>>
>>> I believe that what is needed is changing Tor to accommodate a
>>> lot of small relays running by a very large number of volunteers,
>>> and to push real traffic through them.
>>
>> Alternately, you need lots of small relays, running (with plausible
>> deniability) on IoT devices. Mirai-style. Using covert channels (packet
>> timing etc). Tor Project would never do that, I know. But eventually, it
>> might come down to that.
> 
> I think you are talking about a different network, which is not Tor as
> currently designed, implemented, and deployed.

Yes, very different. But perhaps using onion-routing. Or mixes. Or both.

> In particular, how do you get decent throughput, reliability, and low-
> latency out of tens of thousands of devices?

I imagine that it would be entirely peer-to-peer. And that it would use
something like multipath UDP. Using covert channels, bandwidth would at
best be ~1% of raw. But Internet bandwidth and latency are increasing,
and high-definition video is everywhere, so there's lots of traffic to
modulate. HD video devices would be good routers, I think.

> This is an open research problem, which the Tor design does not solve.
> 
> T

Indeed. A few designs have been published, but nothing better has been
implemented. As far as I know, anyway.









> --
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
> 
> 
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

> On 28 Dec 2016, at 02:50, Rana  wrote:
> 
> Speaking of guards, could someone come with a theory pf what happened here? 
> The IP is static, the relay exists for 18 days and has Stable flag since 
> maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the 
> bandwidth limit in torrc for 2 weeks now. What could explan the sudden 
> catastrophic drop in bandwidth after linear if not exponential growth? This 
> articledescribes exactly this pattern but the drop occurs when a Guard flag 
> is awarded. In this case, no guard fag. Any ideas?

When your relay reaches its bandwidth rate, it has no spare capacity.
Therefore, the bandwidth authority measurements (and consensus
weight) are lower.

Since the consensus weight is lower, clients use the relay less.
The relay has spare capacity, and the bandwidth authority measurements
(and consensus weight) are higher.

This feedback process continues until the relay utilisation and
consensus weight stabilise.

(Large page)
https://consensus-health.torproject.org/consensus-health-2017-01-03-02-00.html#707A9A3358E0D8653089AF32A097570A96400CC6

In this particular case, the changes are large.
This might be because:
* the bandwidth rate is low,
* the connection speed is high compared to the bandwidth rate,
* the IP address changes, or
* the relay restarts, or
* perhaps some other reason.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Disparity between download and upload traffic


> On 27 Dec 2016, at 03:47, Gage Parrott  wrote:
> 
> Morning, everyone,
> 
> I recently migrated my bridge relay over to a VM and everything seems to be 
> working fine except for one oddity.  I consistently see lines like this in 
> tor's log file on the new machine:
> 
> Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, 
> with 43 circuits open. I've sent 1.78 GB and received 28.37 GB.
> Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 
> unique clients.
> Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, 
> with 105 circuits open. I've sent 1.87 GB and received 29.24 GB.
> Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 
> unique clients.
> 
> Notice the amount of data sent and received.  Can anyone think of why there 
> would be such a large discrepancy between the amount of traffic downloaded 
> versus uploaded?  This behavior persists after reboots, as well.
> 
> I thought maybe it was downloading a ton of directory data, but is there 
> really a GB's worth of directory data to download every six hours??  Also, 
> the logs on my old machine (pre-migration, one line pasted below for 
> reference) indicated that nearly the same amount of data was being sent as 
> was being received.  Any ideas on why would this have changed?
> 
> Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, 
> with 78 circuits open. I've sent 33.71 GB and received 33.47 GB.
> 
> Any help is greatly appreciated.  Thanks a bunch and merry Christmas!

It looks like you have very few clients.
Perhaps those clients have switched to using interactive protocols?
Or, more precisely, perhaps those clients are sending almost-empty
cells, and then receiving back almost-full cells in response?
(This could be an amplification attack, or simply lots of downloads.)

On the other hand, your bridge could be repeatedly asking for directory
documents. If this is the case, we'd *really* like to know what is
causing the issue. Please send more logs, at info-level if possible.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

To recap, we are talking about
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C
C6

Thanks but your explanation does not seem to apply here. The measured BW is
equal to the limit and has been the same rock solid number (153.6 KB/s) for
weeks. As you see on the graph, the actual throughput is nowhere near the
limit. The IP is static and therefore never changed. The relay almost never
restarted and certainly did not restart for weeks before the drop occurred
(uptime is 24 days now). And as you see it never really recovered from the
drop and seems to have stabilized at about 7% of its (as measured and
reported in Atlas) capacity. 

What am I missing?

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of teor
Sent: Tuesday, January 03, 2017 5:31 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic
IP

> On 28 Dec 2016, at 02:50, Rana  wrote:
> 
> Speaking of guards, could someone come with a theory pf what happened
here? The IP is static, the relay exists for 18 days and has Stable flag
since maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the
bandwidth limit in torrc for 2 weeks now. What could explan the sudden
catastrophic drop in bandwidth after linear if not exponential growth? This
articledescribes exactly this pattern but the drop occurs when a Guard flag
is awarded. In this case, no guard fag. Any ideas?

When your relay reaches its bandwidth rate, it has no spare capacity.
Therefore, the bandwidth authority measurements (and consensus
weight) are lower.

Since the consensus weight is lower, clients use the relay less.
The relay has spare capacity, and the bandwidth authority measurements (and
consensus weight) are higher.

This feedback process continues until the relay utilisation and consensus
weight stabilise.

(Large page)
https://consensus-health.torproject.org/consensus-health-2017-01-03-02-00.ht
ml#707A9A3358E0D8653089AF32A097570A96400CC6

In this particular case, the changes are large.
This might be because:
* the bandwidth rate is low,
* the connection speed is high compared to the bandwidth rate,
* the IP address changes, or
* the relay restarts, or
* perhaps some other reason.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

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

Re: [tor-relays] What's a "useful" relay?

> On 24 Dec 2016, at 18:56, Rana  wrote:
> 
> ...
> 
> What is needed is a standardized feedback on WHY the relay has such a low 
> rating. This could cause at least part of the operators to take care of the 
> bottleneck (eg moving the relay to another location, or abandoning the home 
> relay and replacing it with a hosted one). And if the home relay is indeed as 
> harmful as some people here think, the recommendation should be issued to 
> shut it down, instead of leaving it hanging there doing nothing or even 
> harming Tor. Such feedback could significantly improve the quality and 
> effectiveness of Tor.
> 
> Based on the discussion here, the people who run Dirauths and bwauths know 
> very well (or at least can easily find out) the reasons for relays getting 
> low rating - why not automate the  communication of the reasons to relay 
> operators in clear, unequivocal and actionable terms?

You could try compiling a FAQ from the answers you and others have
received.

Or, someone could volunteer to create a relay performance analysis
tool. But it might not be as simple as you think. There are many
variables, and it's hard to work out what's actually happening to a
relay without access to the relay itself.

> I get the feeling that people are trying to be "politically correct" here and 
> it's a pity (although they DO respond fully and frankly when asked a direct 
> question).

Perhaps some of us struggle to answer similar questions in the same
level of detail all the time. I know I do. It takes a lot of time to
elicit the level of detail needed to provide good answers.

Also when we're not polite, the discussion escalates into long threads
with few interesting posts. So most of us learn to avoid that.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

@teor
>I think you are talking about a different network, which is not Tor as
currently designed, implemented, and deployed.
>In particular, how do you get decent throughput, reliability, and low-
latency out of tens of thousands of devices?
>This is an open research problem, which the Tor design does not solve.

Sorry for being thick-headed but 

1. I do not see the connection between the latency and the number of relays.
However many relays there are in the pool, there always will be  3 relays
(or so)  per circuit.

2. I also do not see the problem with throughput and latency. If the relay
is small, it should be used in accordance with its capacity, which is
reported in consensus. Many small relays should increase the probability of
finding one that has spare bandwidth (my residential relay is, for example,
idle 93% of the time despite having decent ultra-stable 153 KB/s bandwidth
and static IP);

3. I do not see the problem of reliability. Reliability is easily measured
and reported. The same relay is VERY reliable - totally stable for weeks,
yet still under-used only because it is small.

4. I do not see why the current design of Tor prevents using more relays. I
do not believe the current design is limited by design in the number of
relays it can support.

I am sure that I am missing some deeper insights. What am I missing?


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

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

> On 3 Jan 2017, at 17:21, Rana  wrote:
> 
> To recap, we are talking about
> https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C
> C6
> 
> Thanks but your explanation does not seem to apply here. The measured BW is
> equal to the limit and has been the same rock solid number (153.6 KB/s) for
> weeks.

Please stop calling it the measured bandwidth. It's confusing.
The heading is "Advertised Bandwidth".

The components of the Atlas advertised bandwidth are:
(View Source or Mouse Over the Advertised Bandwidth figure)
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6

Advertised Bandwidth: 153.6 KB/s
Bandwidth rate: 153.6 KB/s
Bandwidth burst: 179.2 KB/s
Observed bandwidth: 173.03 KB/s

Look in my previous emails for definitions of these figures, and how the
advertised bandwidth is calculated from them.

> As you see on the graph, the actual throughput is nowhere near the
> limit.

The reported bandwidth doesn't need to be near the limit to decrease the
measured bandwidth. Any client usage decreases the extra bandwidth
available for measurement, and therefore decreases the measurement.

> The IP is static and therefore never changed. The relay almost never
> restarted and certainly did not restart for weeks before the drop occurred
> (uptime is 24 days now). And as you see it never really recovered from the
> drop and seems to have stabilized at about 7% of its (as measured and
> reported in Atlas) capacity.

It seems your relay's sustained capacity might be much less than the
bandwidth rate. There are many factors that can limit relay capacity.
Look in previous emails on this list for some of the different factors.

> What am I missing?

Maybe the measurement system works, and your relay just can't sustain
high volumes of traffic (or large numbers of connections).

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What's a "useful" relay?

@teor
I hereby volunteer to maintain a FAQ for operators of small relays (or noob
operators). Which means I would be watching this list, generating the Q&A
and from time to time alerting this list to the appearance of new questions
and answers, to allow knowledgeable people to do quality control. And/or
inviting people to convert their answers on this list  to the FAQ answers.
This would relieve them from answering the same question over and over again
and reduce the influx of questions from noobs (like myself :)). I believe
this would also strengthen the community and reduce the frustration of small
relay operators  and - who knows? - even lead to advancements in Tor design
to make better use of them.

Caveat: I need someone (Tor project people) to create the Wiki on the site
and let me admin it. There is already a severely underused wiki with a
couple of answers that someone once referred me to, with a disastrously
difficult captcha that I could not pass (why have captcha on a Wiki in the
first place is beyond me)

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of teor
Sent: Tuesday, January 03, 2017 8:26 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] What's a "useful" relay?

> On 24 Dec 2016, at 18:56, Rana < 
ranaventu...@gmail.com> wrote:
> 
> ...
> 
> What is needed is a standardized feedback on WHY the relay has such a low
rating. This could cause at least part of the operators to take care of the
bottleneck (eg moving the relay to another location, or abandoning the home
relay and replacing it with a hosted one). And if the home relay is indeed
as harmful as some people here think, the recommendation should be issued to
shut it down, instead of leaving it hanging there doing nothing or even
harming Tor. Such feedback could significantly improve the quality and
effectiveness of Tor.
> 
> Based on the discussion here, the people who run Dirauths and bwauths know
very well (or at least can easily find out) the reasons for relays getting
low rating - why not automate the  communication of the reasons to relay
operators in clear, unequivocal and actionable terms?

You could try compiling a FAQ from the answers you and others have received.

Or, someone could volunteer to create a relay performance analysis tool. But
it might not be as simple as you think. There are many variables, and it's
hard to work out what's actually happening to a relay without access to the
relay itself.

> I get the feeling that people are trying to be "politically correct" here
and it's a pity (although they DO respond fully and frankly when asked a
direct question).

Perhaps some of us struggle to answer similar questions in the same level of
detail all the time. I know I do. It takes a lot of time to elicit the level
of detail needed to provide good answers.

Also when we're not polite, the discussion escalates into long threads with
few interesting posts. So most of us learn to avoid that.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

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

Re: [tor-relays] Speed up of reconnections after IP Address change