Re: [tor-relays] Why MyFamily?

2020-02-27 Thread lists

On 22.02.2020 08:42, teor wrote:


Tor also supports "%include (path)" lines in torrcs, which include the
contents of the file at that path.

(If you have logrotate installed, it should issue a HUP every day to
rotate tor's logs. So maybe you can skip that step.)

It's a bit of a pain, I know.



No, that's great! Thank you.
I didn't know include path in torrc yet. ;-)

--
╰_╯ Ciao Marco!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Why MyFamily?

2020-02-23 Thread Michael Gerstacker
I just found out that i can have more than one MyFamily line specified in
the torrc.

nusenu could you please check with your tool that everything is correct now?


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


Re: [tor-relays] Why MyFamily?

2020-02-23 Thread Michael Gerstacker
Am So., 23. Feb. 2020 um 11:51 Uhr schrieb Moritz Bartl <
mor...@torservers.net>:

> On 22.02.20 15:51, Michael Gerstacker wrote:
> > I am the operator of my relays so if i for whatever reason decide to not
> > publish that i run a bigger family then this should be my own decision.>
> > If the torproject needs these information urgently they need to force it
> > for example with a relay registration or should find a better soultion
> > which is not depending on a trust level.
>
> I am sorry, but this is an ignorant perspective. Even though the Tor
> network has no means to force it on to you, you really should configure
> your nodes correctly. This includes a correct MyFamily statement, even
> if it means more work. If you don't want to do that work, then you
> should ask yourself why you contribute relays in the first place. Do you
> really want to do it to weaken the network? Probably not. It is really
> not that much effort to synchronize the statement, even with a large
> number of relays and without willingness to work with "configuration
> management" tools. It took me only a few minutes to put together a bash
> script that logs in, grabs fingerprints, assembles them to a unified
> MyFamily statement, and pushes the updated line to all relays again. [1]
>

Not going with the stream is an ignorant perspective most of the time.
The reason why i run relays is because in my opinion tor is doing exactly
that.

You want my IP address? NO!
We rather build a big non-profit organization, find developers, search
donations, encourage people all over the world to run relays, resist
against all governmental censorship tries and do everything we can because
we believe our IP address is ours.

This is ignorance at its finest and thats one of the reasons why i run
relays.


> On a more general level, do you really want to argue than any rule or
> law that is not enforceable is completely pointless in society?
>

No, no that was not what i meant.

I just didnt understood why i should set MyFamily and brought up my
personal points against it so that hopefully someone can explain me why
other points are more important than mine.
teor explained me that with words i understood so for the future i will set
MyFamily correctly now.


> You seem to think MyFamily is not that relevant because its correct
> configuration relies on the same operator that you need to trust not to
> perform end-to-end correlation in the first place. This is only a minor
> aspect. As an operator, you and your infrastructure becomes a potential
> target. By not configuring MyFamily correctly, you invite attackers, and
> make their lives easier. I can pown you, steal your keys, exploit a
> weakness in your configuration, get a court to give me a wiretapping
> order for a single individual much easier than for many, etc etc, all
> much more interesting if I _know_ that you are a careless operator that
> does not configure their relays correctly. You should make your relays
> less interesting, also for others, not only for yourself.
>
> Cheers, and thanks for trying to run relays in a good fashion :)
>

If my words sounded ignorant or rude or egoistic that was not my intention.
I just wanted to understand why i should waste energy to do steps which i
dont understand.
Now i understand them and i will go with the stream and set MyFamily
correctly today.

Thank you all for that interesting conversation
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Why MyFamily?

2020-02-23 Thread Toralf Förster
On 2/23/20 11:51 AM, Moritz Bartl wrote:
> Cheers, and thanks for trying to run relays in a good fashion :)
> 
> Moritz
(y)

-- 
Toralf



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] Why MyFamily?

2020-02-23 Thread Moritz Bartl
On 22.02.20 15:51, Michael Gerstacker wrote:
> I am the operator of my relays so if i for whatever reason decide to not
> publish that i run a bigger family then this should be my own decision.>
> If the torproject needs these information urgently they need to force it
> for example with a relay registration or should find a better soultion
> which is not depending on a trust level.

I am sorry, but this is an ignorant perspective. Even though the Tor
network has no means to force it on to you, you really should configure
your nodes correctly. This includes a correct MyFamily statement, even
if it means more work. If you don't want to do that work, then you
should ask yourself why you contribute relays in the first place. Do you
really want to do it to weaken the network? Probably not. It is really
not that much effort to synchronize the statement, even with a large
number of relays and without willingness to work with "configuration
management" tools. It took me only a few minutes to put together a bash
script that logs in, grabs fingerprints, assembles them to a unified
MyFamily statement, and pushes the updated line to all relays again. [1]

On a more general level, do you really want to argue than any rule or
law that is not enforceable is completely pointless in society?

You seem to think MyFamily is not that relevant because its correct
configuration relies on the same operator that you need to trust not to
perform end-to-end correlation in the first place. This is only a minor
aspect. As an operator, you and your infrastructure becomes a potential
target. By not configuring MyFamily correctly, you invite attackers, and
make their lives easier. I can pown you, steal your keys, exploit a
weakness in your configuration, get a court to give me a wiretapping
order for a single individual much easier than for many, etc etc, all
much more interesting if I _know_ that you are a careless operator that
does not configure their relays correctly. You should make your relays
less interesting, also for others, not only for yourself.

Cheers, and thanks for trying to run relays in a good fashion :)

Moritz

[1] https://github.com/torservers/myfamilyupdater
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Why MyFamily?

2020-02-22 Thread Michael Gerstacker
Am So., 23. Feb. 2020 um 01:55 Uhr schrieb teor :

> Hi,
>
> I've gone a few emails back up the thread, because the risk
> analysis is missing some really important factors.
>
> And just some reminders:
>
> Some users depend on the tor network for their safety.
>
> Relay operators take some risks, but we do our best to
> reduce those risks.
>
> MyFamily is about user and operator safety. We pay more
> attention to arguments based on safety.
>
> On 22 Feb 2020, at 23:02, Michael Gerstacker <
> michael.gerstac...@googlemail.com> wrote:
>
> > So for what reason do i set the MyFamily option beside making a Hidden
>> > Service Guard discovery attack more easy?
>>
>> - risk reduction for tor users
>> MyFamily declarations allow the tor client software to automatically
>> detect relay families when creating circuits to
>> avoid using multiple relays from the same operator in a single circuit.
>>
>
> This should not matter if the operator is not malicious and like i already
> said an malicious operator will not use the same contact info or relay name.
>
> - reducing the risk for tor users that might become victims if some
>> operator gets compromized (with all its relays)
>>
>
> This is a reason i can understand.
> Not sure how much that would really help in practice but i can understand
> it.
>
>
> In practice, relay operators become targets for compromise
> when they don't set MyFamily. Because those relays can be
> used to attack a Tor users.
>
> If relay operators correctly set MyFamily, then an attacker
> needs to compromise multiple operators to see a single
> user's traffic.
>
> In this case, it doesn't matter if the operator is malicious.
>

Understood.
So for example if someone compromise multiple of my relays without me
noticing it and installs software on them (or the providers network) to do
a traffic correlations attack i am a less interesting target when i have
set MyFamily.
Another benefit of a proper MyFamily setting in this case would be that he
first would need to remove the MyFamily to see any interesting traffic
which i would most likely realize faster than without a proper MyFamily
setting.

This is indeed something what makes me very uncomfortable because it would
be my fault if someones privacy would get affected by this.


> - transparency
>> Every relay operator should declare their relay group to allow everybody
>> to measure their network fraction (Sybil detection).
>>
>
> Should...
> But i understand this one too.
> But as long as my family is still a small one with only one exit compared
> to others i am not a Sybil attack risk and even if i would would i get any
> special treatment then?
>
>
> It doesn't matter how small your relays are. Some clients
> will choose your relays as guards. You're putting those
> users in danger.
>

I understand this one as related to the first one.


> - risk reduction for relay operators
>> MyFamily also provides risk reduction for operators since they are less
>> valuable as an attack target
>> if they can not technically be used for e2e correlation attacks
>>
>
> I think this is similar to your first point but i think that should be the
> operators choice if he want to take steps against this case.
>
>
> There's also a network effect here. If almost all operators
> set MyFamily, then the Tor Network becomes a less
> valuable target for attacks. So attackers use other
> methods, like attacking Tor Browser, or offline attacks.
>
> But if a lot of operators don't set MyFamily, then attackers
> develop tools and techniques to attack the network. Then
> they can repeat these attacks easily whenever they get a
> new target. I guess you could call that a market effect.
>

Understood.


> So if you're not going to set MyFamily for yourself, do it for
> Tor users, and do it for Luther relay operators.
>

Will try to do it tomorrow.


> We prioritise the safety of users and relay operators here.
>
> T
> ___
> 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] Why MyFamily?

2020-02-22 Thread teor
Hi,

I've gone a few emails back up the thread, because the risk
analysis is missing some really important factors.

And just some reminders:

Some users depend on the tor network for their safety.

Relay operators take some risks, but we do our best to
reduce those risks.

MyFamily is about user and operator safety. We pay more
attention to arguments based on safety. 

>> On 22 Feb 2020, at 23:02, Michael Gerstacker 
>>  wrote:
>>> > So for what reason do i set the MyFamily option beside making a Hidden
>>> > Service Guard discovery attack more easy?
>>> 
>>> - risk reduction for tor users
>>> MyFamily declarations allow the tor client software to automatically detect 
>>> relay families when creating circuits to
>>> avoid using multiple relays from the same operator in a single circuit.
>> 
>> This should not matter if the operator is not malicious and like i already 
>> said an malicious operator will not use the same contact info or relay name.
>> 
>> - reducing the risk for tor users that might become victims if some operator 
>> gets compromized (with all its relays)
> 
> This is a reason i can understand.
> Not sure how much that would really help in practice but i can understand it.

In practice, relay operators become targets for compromise
when they don't set MyFamily. Because those relays can be
used to attack a Tor users.

If relay operators correctly set MyFamily, then an attacker
needs to compromise multiple operators to see a single
user's traffic.

In this case, it doesn't matter if the operator is malicious.

>> - transparency
>> Every relay operator should declare their relay group to allow everybody to 
>> measure their network fraction (Sybil detection).
> 
> Should...
> But i understand this one too.
> But as long as my family is still a small one with only one exit compared to 
> others i am not a Sybil attack risk and even if i would would i get any 
> special treatment then?

It doesn't matter how small your relays are. Some clients
will choose your relays as guards. You're putting those
users in danger.

>> - risk reduction for relay operators
>> MyFamily also provides risk reduction for operators since they are less 
>> valuable as an attack target
>> if they can not technically be used for e2e correlation attacks
> 
> I think this is similar to your first point but i think that should be the 
> operators choice if he want to take steps against this case.

There's also a network effect here. If almost all operators
set MyFamily, then the Tor Network becomes a less
valuable target for attacks. So attackers use other
methods, like attacking Tor Browser, or offline attacks.

But if a lot of operators don't set MyFamily, then attackers
develop tools and techniques to attack the network. Then
they can repeat these attacks easily whenever they get a
new target. I guess you could call that a market effect.

So if you're not going to set MyFamily for yourself, do it for
Tor users, and do it for Luther relay operators.

We prioritise the safety of users and relay operators here.

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


Re: [tor-relays] Why MyFamily?

2020-02-22 Thread Michael Gerstacker
Am Sa., 22. Feb. 2020 um 17:11 Uhr schrieb nusenu :

> Michael Gerstacker:
> >>> But as long as my family is still a small
> >> It is rather hard, time consuming and error prone
> >> to asses group sizes without proper MyFamily declarations.
> >>
> > I am the operator of my relays so if i for whatever reason decide to not
> > publish that i run a bigger family then this should be my own decision.
>
> There are two notions to this, depending on what you mean by 'publish'.
>
> 'publish' in the sense of linkability relays <-> operator identity:
> Correct there is no need for that.
>
> 'publish' in the sense of declaring a proper MyFamily set:
>
> from the tor manual page:
> "If you run more than one relay, the MyFamily option on each relay
> **must** list all other relays"
>

I will list them or shut them down. Just not right now.

I thought about why i do not want to list them right now and this reason
might sound stupid to others but for me including a new relay into MyFamily
is some sort of "celebration".
When i include a new relay i commit myself to care for it for the next time
period (no matter how long that means).
For me that means checking nyx and the logfile everyday and taking a quick
look into nmon.

So as an operator who paies the bills for my new children i expect the
torproject and all affected people to wait till i did my "celebration" or
take the necessary steps and reject them so that i understand this as a
message that the celebration took too long and that these relays are not
wanted anymore.

I think i do not want to automate this because it would destroy my
celebration.
I already automated upgrades because i see a purpose in this but from my
point of view i can not see any porpose to automate MyFamily.

I also thought about why i include them in MyFamily at all and i think the
reason is because i want that others have the possibility to exclude my
relays if they see a need to do so.



> > If the torproject needs these information urgently they need to force it
>
> The Torproject Inc does not run the Tor network, nor the majority of Tor
> directory authorities,
> but yes, some Torproject employees play a key role on what gets actually
> enforced on the network and what not
> and The Torproject produces the software that dir auths run so they have
> at least partial/indirect control over the imposed rules
> and the network.
> As far as I know there is no formal or informal written agreement between
> Tor directory authorities as to how they run the network.
> Past attempts by a Torproject employee an me, to establish something like
> that unfortunately failed [1].
>

I think i remember something where nick explained that he (or any other
torproject member listed on the torprojects peoples page) can not directly
tell the authorities operators what they should do.
This made me think about for the first time what the torproject actually is.

And i think that the way it is right now is actually a good thing. Maybe it
even must be like that to ensure free speech as good as possible and to not
make some people a big target.
Bu its funny to hear from one of the main designers of Tor that he can
actually not really decide what happens.

I think there is the difference between a normal company and Tor and thats
the reason why i am okay paying bills without getting something countable
back (beside the fact that i learned a lot in many ways since i started my
first relay).

I think it is impressive how good this project works and i think you would
put that at risk if you try to force standards too easily and telling
directory authorities operators how to run them is one of these examples.

Of course i only see what i can see and i see that you are more involved
than i am but i think as long as its not broken dont try to fix it.


>
> > Not proposing relays of honest operators for removal should be in the
> > interest of all to help protect tor users
>
> It is hard to tell honest operators from others if the relay has no
> ContactInfo
> or does not reply to emails. Even if they reply it can be non-trivial. So
> if there were actual technical rules
> they should apply to all relays equally and not just to dishonest operators
> because how do you define and measure "honest" operator?
> Should an operator who confirms to bad-relays@ that he setup modified
> relays to collect onion addresses
> be allowed on the network because he is at least honest about it?
>

(Just for the record i had contact info on all my relays and check that
email address weekly. Since my first exit even daily.)
Yes of course this is a problem and the only "solution" is to raise the bar
for all.
But this is not what MyFamily is doing. It is raising the bar for the
honest ones but not for the dishonest ones.

If this problem need to get fixed i propose using a contact email address
as a replacement of MyFamily and sending a validation email.
Maybe even send another validation email after some randomized timeframe
from time to time 

Re: [tor-relays] Why MyFamily?

2020-02-22 Thread nusenu
Michael Gerstacker:
>>> But as long as my family is still a small
>> It is rather hard, time consuming and error prone
>> to asses group sizes without proper MyFamily declarations.
>>
> I am the operator of my relays so if i for whatever reason decide to not
> publish that i run a bigger family then this should be my own decision.

There are two notions to this, depending on what you mean by 'publish'.

'publish' in the sense of linkability relays <-> operator identity:
Correct there is no need for that.

'publish' in the sense of declaring a proper MyFamily set:

from the tor manual page:
"If you run more than one relay, the MyFamily option on each relay **must** 
list all other relays"

> If the torproject needs these information urgently they need to force it

The Torproject Inc does not run the Tor network, nor the majority of Tor 
directory authorities,
but yes, some Torproject employees play a key role on what gets actually 
enforced on the network and what not
and The Torproject produces the software that dir auths run so they have at 
least partial/indirect control over the imposed rules
and the network.
As far as I know there is no formal or informal written agreement between Tor 
directory authorities as to how they run the network. 
Past attempts by a Torproject employee an me, to establish something like that 
unfortunately failed [1].


> Not proposing relays of honest operators for removal should be in the
> interest of all to help protect tor users

It is hard to tell honest operators from others if the relay has no ContactInfo 
or does not reply to emails. Even if they reply it can be non-trivial. So if 
there were actual technical rules
they should apply to all relays equally and not just to dishonest operators
because how do you define and measure "honest" operator?
Should an operator who confirms to bad-relays@ that he setup modified relays to 
collect onion addresses
be allowed on the network because he is at least honest about it? 


> but an opt-in solution for
> MyFamily which gets forced by random people on a public [tor-]bad-relays
> mailinglist 

bad-relays@ is not public in the sense that everyone can read it, but everyone 
can send to it,
which is its main purpose.




[1] 
https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548




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] Why MyFamily?

2020-02-22 Thread Michael Gerstacker
Am Sa., 22. Feb. 2020 um 15:17 Uhr schrieb nusenu :

> >> - risk reduction for tor users
> >> MyFamily declarations allow the tor client software to automatically
> >> detect relay families when creating circuits to
> >> avoid using multiple relays from the same operator in a single circuit.
> >>
> >
> > This should not matter if the operator is not malicious
>
> That is a big if and impossible to detect automatically.
> If we accept operators to run end-to-end correlation relay groups by
> receiving "you can trust me" emails
> you can guess what malicious actors will do next.
>

Of course would they do.


> The only way the tor client software can detect relay groups across
> multiple /16 blocks automatically and at scale
> is currently by MyFamily declaration.
> There is no "dude don't worry, you can trust me" flag.
>

And if there would be then this would be the worst possible solution.


> > and like i already
> > said an malicious operator will not use the same contact info or relay
> name.
>
> We've had that already.
>

I know. Thats why i point that out again because now i am somehow affected
too and can better understand what they mean with that sentence.


> > But as long as my family is still a small
>
> It is rather hard, time consuming and error prone
> to asses group sizes without proper MyFamily declarations.
>

I am the operator of my relays so if i for whatever reason decide to not
publish that i run a bigger family then this should be my own decision.

If the torproject needs these information urgently they need to force it
for example with a relay registration or should find a better soultion
which is not depending on a trust level.


>
> > I think MyFamily greatly fails in trying to solve a problem
>
> I agree, but it is currently the only option how operators can tell tor
> clients
> about their relay group in an automated way.
>
> To summarize:
>
> Multiple recommendations (with and without configuration management)
> have been pointed out to practically solve the hassle of MyFamily across
> multiple relays with a growing group of relays
> without requiring to mess with all torrc files manually whenever a new
> relay gets added to a group.
>

Understood.


> Using one of them should be in the interest of relay operators to help
> protect tor users
> (and indirectly help with malicious relay detection).
>

Not proposing relays of honest operators for removal should be in the
interest of all to help protect tor users but an opt-in solution for
MyFamily which gets forced by random people on a public tor-bad-relays
mailinglist is not the right way in my opinion because obviously at least
in my case these people might lack information.
I understand that this is only obvious for me but then these people should
think twice before they propose relays for removal.


> ___
> 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] Why MyFamily?

2020-02-22 Thread nusenu
>> - risk reduction for tor users
>> MyFamily declarations allow the tor client software to automatically
>> detect relay families when creating circuits to
>> avoid using multiple relays from the same operator in a single circuit.
>>
> 
> This should not matter if the operator is not malicious 

That is a big if and impossible to detect automatically.
If we accept operators to run end-to-end correlation relay groups by receiving 
"you can trust me" emails
you can guess what malicious actors will do next.

The only way the tor client software can detect relay groups across multiple 
/16 blocks automatically and at scale 
is currently by MyFamily declaration.
There is no "dude don't worry, you can trust me" flag.

> and like i already
> said an malicious operator will not use the same contact info or relay name.

We've had that already.

> But as long as my family is still a small 

It is rather hard, time consuming and error prone
to asses group sizes without proper MyFamily declarations.


> I think MyFamily greatly fails in trying to solve a problem 

I agree, but it is currently the only option how operators can tell tor clients
about their relay group in an automated way. 

To summarize:

Multiple recommendations (with and without configuration management) 
have been pointed out to practically solve the hassle of MyFamily across 
multiple relays with a growing group of relays
without requiring to mess with all torrc files manually whenever a new relay 
gets added to a group.

Using one of them should be in the interest of relay operators to help protect 
tor users
(and indirectly help with malicious relay detection).



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] Why MyFamily?

2020-02-22 Thread Michael Gerstacker

Hi nusenu

Am Fr., 21. Feb. 2020 um 22:24 Uhr schrieb nusenu :

> Hi Michael,
>
> > Last week i got an email with a warning that some of my relays are
> > missing the correct MyFamily setup and that i am a risk to do
> > end-to-end correlation attacks together with a list of all relays i
> > operate plus one relay which uses the same name than i use but is not
> > operated by me.
>
> the email Michael is referring to for the interested readers: [1]
>
> > I already knew that not all of my relays have a correct MyFamily setup
> > because as long as i am not sure if they will stay i usually dont
> > include them in MyFamily because it is a pain to edit every torrc
>
> Yes, manually managing MyFamily is a pain with that many relays.
> It is best to automate it so you don't have to worry about it
> no matter how long your relays might run.
>
> It is also relevant to note that we are not talking about fresh relays
> (born days or weeks ago) but >6 months.
>

I think the relay you are talking about is the relay in Yekaterinburg.
This relay is not listed as with no MyFamily in the first email but after
receiving the first email i decided that i am okay with the newer hoster
more than the older hoster so i included the newer one in MyFamily and
excluded the older one and will probably let it expire so the relays
mentioned with no MyFamily setup in the first and the ones in the second
email should be slightly different.

But thats not important anyway.

I usually wait at least one billing period. Some of my relays are paid for
three years in advance which means there might be cases where a relay will
be in a state of unknown for three years till i know if they will stay.


> > A few days later i got a message that some of my relays will soon get
> > rejected because i did not responded to the previous email.
>
> A more correct version is: some relays were proposed for removal on the
> bad-relays@ list
> should there not be any reaction by the operator [2].
>
> That is something different than informing an operator about an upcoming
> removal since
> everybody can propose removals and only dir auths can actually vote for
> the removal.
>

Understood.


> [2]
> For the readers on this list, this is the second mentioned email:
> > I'm proposing the removal of the first 5 entries in the following table
> (end-to-end correlation risk)
> > should there not be any reaction to this email from the operator.
> >
> > A previous email from 2020-02-15 did not result in a reply so far.
> >
> >
> +-++--+--+---+-+---+--+
> > | first_seen  | member | contact  | nickname
>  | tor_version   | IP  | as_name
>| fingerprint  |
> >
> +-++--+--+---+-+---+--+
> > | 2020-02-01 18:00:00 |  1 | NULL | angeltest33
> | 0.4.2.6   | 139.99.238.17   | OVH SAS
>| 4BF3D299BC500C350868F078749291C766C7AA6F |
> > | 2020-01-11 16:00:00 |  1 | NULL | angeltest5test
>  | 0.4.2.6   | 51.38.147.96| OVH SAS
>| 951307BA74E44A9C9C208B2F134CDA2409944075 |
> > | 2019-08-06 11:00:00 |  1 | NULL | angeltest27
> | 0.4.2.6   | 185.173.177.153 | GalaxyStar LLC
>   | 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE |
> > | 2019-08-31 09:00:00 |  1 | NULL | angeltest9
>  | 0.2.9.14  | 104.244.76.190  | FranTech Solutions
> | F1D5C0F5157D9B24014BE8C7A1D878AEA6843B42 |
> > | 2019-11-21 12:00:00 |  1 | NULL | angeltest26test
> | 0.4.2.6   | 91.243.50.239   | Petersburg Internet Network ltd.
>   | F51A927E34662D6005393F2327C870FB0D0D7FE0 |
>
>
>
> > - The bad-relays team expect an answer to their emails even if they do
> > not tell you that in the first email and rather send you a second
> > email that they will soon reject your relays if you dont answer them.
>
> I think you are confusing the "bad-relays team" with subscribers or people
> sending emails to the bad-relays@ list.
> If in doubt require the sender to have a @torproject.org address
> (unfortunately there is no actual sender address for the bad-relays team
> since it is just a mailing list)
>

The senders name was "tor-bad-rel...@riseup.net" which looked official to
me.
Then Georg Koppen "validated" the second email.

For the next time i know that i only need to respond to valid emails.


> > So for what reason do i set the MyFamily option beside making a Hidden
> > Service Guard discovery attack more easy?
>
>
> - risk reduction for tor users
> MyFamily 

Re: [tor-relays] Why MyFamily?

2020-02-22 Thread nusenu


Toralf Förster:
> On 2/22/20 10:55 AM, nusenu wrote:
>> You can preemptively generate as many relay keys as you want and 
>> use their fingerprints in MyFamily so you don't have to bother about 
>> changing old 
>> configs when you add new relays as long as you use these preemptively 
>> generated keys. 
>>
> And if you're already there then you can then deal with offline keys too ;-)

I believe that is a different matter. If you run >2 relays without configuration
management and don't want to update torrc file, you probably don't want to run
in OfflineMasterKey mode either.

So this is another reason to seriously consider configuration management if you 
run
> 1Gbit/s of tor bandwidth. If you want to consider a state of the art relay 
> setup.




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] Why MyFamily?

2020-02-22 Thread Toralf Förster
On 2/22/20 10:55 AM, nusenu wrote:
> You can preemptively generate as many relay keys as you want and 
> use their fingerprints in MyFamily so you don't have to bother about changing 
> old 
> configs when you add new relays as long as you use these preemptively 
> generated keys. 
> 
And if you're already there then you can then deal with offline keys too ;-)

-- 
Toralf



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] Why MyFamily?

2020-02-22 Thread nusenu
> Secondly, even though not recommended at all, MyFamily accepts nicknames;
> If there's no practical way for you to automate it (such as to set up a
> centralized system to manage torrcs and push them to hosts), you can make a
> MyFamily like this:
> 
> MyFamily MyNode1,MyNode2,MyNode3,...,MyNodeN

Don't use nicknames in MyFamily.
You can preemptively generate as many relay keys as you want and 
use their fingerprints in MyFamily so you don't have to bother about changing 
old 
configs when you add new relays as long as you use these preemptively generated 
keys. 


-- 
https://mastodon.social/@nusenu



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] Why MyFamily?

2020-02-21 Thread teor
Hi Michael,

> On 22 Feb 2020, at 11:30, Roman Mamedov  wrote:
> 
>>> I already knew that not all of my relays have a correct MyFamily setup
>>> because as long as i am not sure if they will stay i usually dont
>>> include them in MyFamily because it is a pain to edit every torrc
>> 
>> Yes, manually managing MyFamily is a pain with that many relays.
>> It is best to automate it so you don't have to worry about it 
>> no matter how long your relays might run.
> 
> What helps greatly is that the MyFamily string on each relay doesn't have to
> list all OTHER relays, it can list just ALL relays, including that one, i.e.
> simply be the same on all relays. This should vastly simplify any automation
> that you might think of.

Also, it's totally ok to list old relay keys in MyFamily, even if those
relays aren't running any more. Tor clients ignore down relays, so you
can clear out old fingerprints whenever you have time.

Tor also supports "%include (path)" lines in torrcs, which include the
contents of the file at that path.

So you can put all your relay fingerprints in a file, scp it to your relays,
and then issue a HUP (to reload the config).

(If you have logrotate installed, it should issue a HUP every day to
rotate tor's logs. So maybe you can skip that step.)

It's a bit of a pain, I know. I've done it with about 20 relays before.

We'd like to have a better system, maybe with a single shared key
for each family. But that's a long-term plan.

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


Re: [tor-relays] Why MyFamily?

2020-02-21 Thread Roman Mamedov
On Fri, 21 Feb 2020 21:23:00 +
nusenu  wrote:

> > I already knew that not all of my relays have a correct MyFamily setup
> > because as long as i am not sure if they will stay i usually dont
> > include them in MyFamily because it is a pain to edit every torrc
> 
> Yes, manually managing MyFamily is a pain with that many relays.
> It is best to automate it so you don't have to worry about it 
> no matter how long your relays might run.

What helps greatly is that the MyFamily string on each relay doesn't have to
list all OTHER relays, it can list just ALL relays, including that one, i.e.
simply be the same on all relays. This should vastly simplify any automation
that you might think of.

Secondly, even though not recommended at all, MyFamily accepts nicknames;
If there's no practical way for you to automate it (such as to set up a
centralized system to manage torrcs and push them to hosts), you can make a
MyFamily like this:

MyFamily MyNode1,MyNode2,MyNode3,...,MyNodeN

That way at any time you can spin up to N relays named "MyNode" 1 to N (or
other arbitrary prefix of your choosing), and they will automatically join
your family without any torrc updates anymore.

> - allow the identification of "false-friends" and actual malicious relays
> By setting MyFamily you make it easier to detect relays that claim to be you
> since MyFamily requires mutual configuration malicious entities can not add 
> their relays to your MyFamily.

...of course using Nicknames doesn't provide this, so in case using such a
system you should keep an eye on relay list for your prefix:

https://metrics.torproject.org/rs.html#search/MyNode

and stop doing so in case you see unfamiliar entries there.

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


Re: [tor-relays] Why MyFamily?

2020-02-21 Thread nusenu
Hi Michael,

> Last week i got an email with a warning that some of my relays are
> missing the correct MyFamily setup and that i am a risk to do
> end-to-end correlation attacks together with a list of all relays i
> operate plus one relay which uses the same name than i use but is not
> operated by me.

the email Michael is referring to for the interested readers: [1]

> I already knew that not all of my relays have a correct MyFamily setup
> because as long as i am not sure if they will stay i usually dont
> include them in MyFamily because it is a pain to edit every torrc

Yes, manually managing MyFamily is a pain with that many relays.
It is best to automate it so you don't have to worry about it 
no matter how long your relays might run.

It is also relevant to note that we are not talking about fresh relays (born 
days or weeks ago) but >6 months.

> A few days later i got a message that some of my relays will soon get
> rejected because i did not responded to the previous email.

A more correct version is: some relays were proposed for removal on the 
bad-relays@ list 
should there not be any reaction by the operator [2].

That is something different than informing an operator about an upcoming 
removal since
everybody can propose removals and only dir auths can actually vote for the 
removal.

[2] 
For the readers on this list, this is the second mentioned email:
> I'm proposing the removal of the first 5 entries in the following table 
> (end-to-end correlation risk)
> should there not be any reaction to this email from the operator.
> 
> A previous email from 2020-02-15 did not result in a reply so far.
> 
> +-++--+--+---+-+---+--+
> | first_seen  | member | contact  | nickname | 
> tor_version   | IP  | as_name 
>   | fingerprint  |
> +-++--+--+---+-+---+--+
> | 2020-02-01 18:00:00 |  1 | NULL | angeltest33  | 
> 0.4.2.6   | 139.99.238.17   | OVH SAS 
>   | 4BF3D299BC500C350868F078749291C766C7AA6F |
> | 2020-01-11 16:00:00 |  1 | NULL | angeltest5test   | 
> 0.4.2.6   | 51.38.147.96| OVH SAS 
>   | 951307BA74E44A9C9C208B2F134CDA2409944075 |
> | 2019-08-06 11:00:00 |  1 | NULL | angeltest27  | 
> 0.4.2.6   | 185.173.177.153 | GalaxyStar LLC  
>   | 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE |
> | 2019-08-31 09:00:00 |  1 | NULL | angeltest9   | 
> 0.2.9.14  | 104.244.76.190  | FranTech Solutions  
>   | F1D5C0F5157D9B24014BE8C7A1D878AEA6843B42 |
> | 2019-11-21 12:00:00 |  1 | NULL | angeltest26test  | 
> 0.4.2.6   | 91.243.50.239   | Petersburg Internet Network ltd.
>   | F51A927E34662D6005393F2327C870FB0D0D7FE0 |



> - The bad-relays team expect an answer to their emails even if they do
> not tell you that in the first email and rather send you a second
> email that they will soon reject your relays if you dont answer them.

I think you are confusing the "bad-relays team" with subscribers or people 
sending emails to the bad-relays@ list. 
If in doubt require the sender to have a @torproject.org address
(unfortunately there is no actual sender address for the bad-relays team since 
it is just a mailing list)

> So for what reason do i set the MyFamily option beside making a Hidden
> Service Guard discovery attack more easy?


- risk reduction for tor users
MyFamily declarations allow the tor client software to automatically detect 
relay families when creating circuits to
avoid using multiple relays from the same operator in a single circuit.

- reducing the risk for tor users that might become victims if some operator 
gets compromized (with all its relays)

- transparency
Every relay operator should declare their relay group to allow everybody to 
measure their network fraction (Sybil detection).

- risk reduction for relay operators
MyFamily also provides risk reduction for operators since they are less 
valuable as an attack target
if they can not technically be used for e2e correlation attacks

- allow the identification of "false-friends" and actual malicious relays
By setting MyFamily you make it easier to detect relays that claim to be you
since MyFamily requires mutual configuration malicious entities can not add 
their relays to your MyFamily.

This is what happened in your case (which was a mixture of 

[tor-relays] Why MyFamily?

2020-02-21 Thread Michael Gerstacker
Last week i got an email with a warning that some of my relays are
missing the correct MyFamily setup and that i am a risk to do
end-to-end correlation attacks together with a list of all relays i
operate plus one relay which uses the same name than i use but is not
operated by me.

I already knew that not all of my relays have a correct MyFamily setup
because as long as i am not sure if they will stay i usually dont
include them in MyFamily because it is a pain to edit every torrc if
they anyway will disappear again soon.
I did it that way with all relays before and when i am sure that the
hoster is okay with me and that i am okay with the hoster i always
included them in MyFamily.

In the received email nothing was written that someone might expect an
answer from me so i deleted that email and to not trigger that warning
again i deleted the contact info from these specific relays for now.

A few days later i got a message that some of my relays will soon get
rejected because i did not responded to the previous email.

I explained why i do not have a correct MyFamily setup and i explained
that one of these relays is not operated by me even if it has the same
name than one of my relays.

The answer of the bad-relays mailing list was that its important for
them to know that one of the relays tried to look like me and that i
can use a third-party tool for setting up the MyFamily and that
further discussion about the MyFamily is more suitable for the relays
mailinglist.


What i learned from that:

- The bad-relays team expect an answer to their emails even if they do
not tell you that in the first email and rather send you a second
email that they will soon reject your relays if you dont answer them.

- I could do an end-to-end correlation attack
(I knew that already and would not use the same name and contact info
on my relays if i would like to do that)

- It is possible for them to pin relays to specific operators without
relying on the contact info or MyFamily entrys
(I assume they guess that by looking at the relays names because
otherwise they hadn't put a relay which is not operated by me into my
warning message)

- If setting up the MyFamily option is too painful for you then you
can use a third party tool which is not part of the torproject

- Relays names are free to choose and double entrys are okay but if
someone operates an relay with a name you choosed before then you can
report that operator to the bad-relays list because that operator
might be malicious
(Thankfully my relays are not called "Unnamed")


So for what reason do i set the MyFamily option beside making a Hidden
Service Guard discovery attack more easy?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays