Re: [tor-relays] Exit node on Contabo

[Michael Gerstacker]

I had a very similar experience with them half a year ago.

Before i bought the service i asked them if exits are allowed and how they
act in case of abuses.
Their answer was that exits are allowed and they will find a solution
together with me in case of abuses.

Three months later the second abuse was from a very confused admin because
someone made posts with curse words in his forum and he said he always
receive emails when someone made a post and thats the way he found out
about it.
He did not even mentioned the affected IP address.

Contabo said i sent spam emails and blocked my server until i solved the
problem.
I told them that no one sent spam emails and that they misunderstood the
abuse report and that i will block the IP address if the admin will tell me
which one.

Contabo said my answer is insufficient (their words) and that they won't
unblock my server.

It got back and forth like that three or four times until they said that
they will only unblock the server if i remove Tor so i asked them for a
refund of the remaining 6 months because i asked them if exits are allowed
before i bought the server.

They said no and showed me their TOS.

I switched it to a non-exit and told them that Tor is removed and they
unblocked the server.

In March the service will finally expire and i can only recommend to stay
far far away from them.


Sincerely

Am Mi., 9. Dez. 2020 um 13:15 Uhr schrieb Amadeus Ramazotti <
cryptoquantumham...@gmail.com>:

> What a joke, their reply.
>
> You could argue that an occasional abuse complaint is a normal and to be
> expected feature of any web service.
>
> Furthermore you could attack this particular section: "...has knowledge
> of abuse or fraudulent or unlawful use."
>
> You could argue that this particular case hasn't been litigated yet,
> therefore it isn't acceptable to conclude now that a fraudulent or unlawful
> use has occurred at all.
> Maybe the person filing the abuse claim was a bit overzealous or even
> outright wrong. This needs to be investigated first.
>
> There is a perfect term in German for this.
> Their trying to shut you down "in vorauseilendem Gehorsam". You can throw
> that at them, it will hurt ;)
>
> If they're stubborn I'd go offensive here and threat them with expensive
> civil rights litigation.
>
> greets
>
>
>
>
> On 9 Dec 2020, at 11:57, Nuno Rego  wrote:
>
>
> Short experience at Contabo. After 10 days, and after the first abuse
> complaint of.
>
> "
> Dear Mr Rego,
>
> Thank you for your reply.
>
> Generally, it is not denied to use TOR nodes on our services. However, in
> case it cannot be ensured that those services will not be misused, we have
> to ask to remove the service from our network. We also included a rule in
> our terms of services, please see here:
>
> § 10 Limitation regarding content
>
> (5) The Provider reserves the right to immediately suspend of any server
> or webspace package on which any kind of proxy service, such as VPN or TOR,
> is operated, for which the Provider has knowledge of abuse or fraudulent or
> unlawful use.
>
> Please come back within given time frame (you still have 18 hours left)
> and confirm that you have removed the TOR node. After that we can close
> this abuse case.
>
> Thank you for your cooperation.
>
> If you have any questions or need help, please do not hesitate to contact
> us.
>
> --
> Best regards / Mit freundlichen Grüßen,
>
> Anneli Ulfig
> Kundenservice / Customer support
>
> Contabo GmbH
> Aschauer Straße 32a
> 81549 München
> https://contabo.com";
>
>
> Cumprimentos;
>
> --
> Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
> https://tutanota.com
> ___
> 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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Michael Gerstacker]

Am Do., 17. Sept. 2020 um 20:51 Uhr schrieb Toralf Förster <
toralf.foers...@gmx.de>:

> On 9/16/20 1:05 AM, Michael Gerstacker wrote:
> > the only relay i don't want to be a fallback anymore is a fallback now
>
> Maybe OT but I'm just curious about the reason to want a relay being not a
> fallback.
>

First reasons why i don't want that this one relay of mine is a fallback:

1. It is heavily used and can barely keep up with the traffic.
Even if fallback traffic is low i have plenty of other relays that are
bored right now.

2. I plan to switch it to an exit maybe and i don't think exits should be
fallbacks.
They draw attention, they are blacklisted, they are hated and depending in
which country they are maybe even watched by some higher authority.
So i think users connecting to fallbacks that are exits should be avoided.
Again i have plenty of other relays that are no exits and where i don't
plan to make them exits so i think these ones are better for being a
fallback.


Not related to that one relay but other reasons why i don't want that some
relays of mine are fallbacks:

3. I have relays in countries where the government doesn't really like Tor.
If my provider would be forced to shut them down (or just shut them down
because he doesn't like Tor) then if the relay is not a fallback soon after
it went down no users will try to connect to it anymore and after a week or
two it is gone from metrics.

If it is a fallback then for weeks, months maybe even years users with old
Tor versions will try to connect to these addresses because Tor expects a
fallback there.

Maybe having fallbacks in these countries is even more important but again
as long as i have relays that are really bored and as long as i can only
opt-in a limited amount of relays i prefer to choose ones that are not
located in these countries and maybe it even helps my provider with not
getting any future problems with their regime.

4. I didn't checked it but some provider have a crazy TOS and i would not
be surprised if some of them write there that it is not allowed to hardcode
the IP you get from them into anything to prevent them from reason 3 where
old versions of a software are abusing their IPs when it is already long
gone.
But exactly that is what you do with opting-in as a fallback.


Maybe there are more reasons but these are the ones i have in my head right
now.

It is not the end of the world that this one relay is a fallback now.
But it is surprising because that particular fingerprint never got opted-in
by me so i think something went wrong somewhere.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Michael Gerstacker]

Am Mo., 27. Juli 2020 um 02:31 Uhr schrieb Nick Mathewson <
ni...@torproject.org>:

> On Fri, Jul 24, 2020 at 1:36 PM David Goulet 
> wrote:
> >
> > On 24 Jul (13:30:31), David Goulet wrote:
> > >
> > > The new list has been generated and can be found here:
> >
> > Apology, clarification needs to be made:
> >
> > >
> > >
> https://gitlab.torproject.org/tpo/core/fallback-scripts/-/blob/master/fallback_offer_list
> > > Diff:
> https://gitlab.torproject.org/tpo/core/fallback-scripts/-/commit/0aa75bf9eaa39c55074ffaa32845b7399466798a
> >
> > The offered list ^ that is all the relays that offered to help since the
> > dawn of time.
> >
> > > In tor binary:
> > >
> https://gitlab.torproject.org/tpo/core/tor/-/blob/master/src/app/config/fallback_dirs.inc
> >
> > The generated list that ended up in the binary. Thus this list needs to
> be
> > reviewed for accuracy if you ended up in :).
> >
> > Sorry for the possible confusion!
> >
> > David
>
>
> Hi, everybody!  David is on vacation now, and will be back in
> mid-August. He'll be able to make any changes to the generated list
> then.  Between now and then, the recently generated list might appear
> in a couple of alphas, but not in any stable releases.
>
> Please let me know if there is a super-important change that needs to
> happen to the list before it goes in any alphas.  Otherwise, please
> don't worry if you don't get a reply until David is back.
>
> best wishes to all,
> --
> Nick
>
>
Great according to the Fallback flag in metrics the only relay i don't want
to be a fallback anymore is a fallback now and all my other relays that
were fallbacks previously are no fallbacks anymore and the list now appears
in a stable release.

The relay of the other operator who asked multiple times to get removed
from the fallback list is a fallback as well.

What now?
How far away do i need to throw the keys to not get it listed again?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

[Michael Gerstacker]

>
>
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>
>
So in other words when the destination website does not really care about
their users safety and the user sends unencrypted exit traffic through Tor
then an exit relay operator could do the same like your internet provider
(spying/changing your traffic).
Properly setting MyFamily does not help in this case.

That's nothing new.

The only news is that it is getting exploited big scale now.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Michael Gerstacker]

Am Fr., 24. Juli 2020 um 19:36 Uhr schrieb David Goulet <
dgou...@torproject.org>:

> > In tor binary:
> >
> https://gitlab.torproject.org/tpo/core/tor/-/blob/master/src/app/config/fallback_dirs.inc
>
> The generated list that ended up in the binary. Thus this list needs to be
> reviewed for accuracy if you ended up in :).
>

Something seems wrong with this list.

This fingerprint of one of my relays never got opted-in by me.
FF9FC6D130FA26AE3AE8B23688691DC419F0F22E

When i remember correctly then the old fingerprint of the relay on this IP
was a fallback but i did a clean install with Debian 10 and didnt kept the
keys because i dont wanted it to be a fallback anymore.

So why is it on the list now?

And is it normal that this list does not list any of my relays that are
currently fallbacks and none of the relays that i opted-in?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Michael Gerstacker]

Am Mi., 8. Juli 2020 um 19:37 Uhr schrieb gus :

>
> Will it have the same address and port for the next 2 years?
>
> Search [2] and [3] for your relay fingerprint or IP address and port.
>
> Keep the same IP address, keys, and ports.
>
> We need fast relays that will be on the same IP address and port for 2
> years.
>

Port or Ports?
If Port, which one?

I guess you are talking about the ORPort because i changed the DirPort of
one of my current fallbacks yesterday and it still has the Fallback flag.

I would like to opt-in:

F8AA8D8CCBA0C5F2836DE6315CDFA6E4A31A0890
B93503D458D9FE97DE5C12D211082871D08F1284
7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06
57C6DF5B93E54EB9C8DB90029D9E9ABD34D2


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

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Michael Gerstacker]

Am So., 5. Juli 2020 um 18:36 Uhr schrieb nusenu :

> Hi,
>
> I'm currently writing a follow-up blog post to [1] about a large scale
> malicious tor exit relay operator
> that did run more than 23% of the Tor network's exit capacity (May 2020)
> before (some) of it got reported to the bad-relays team and
> subsequently removed from the network by the Tor directory authorities.
> After the initial removal the malicious actor quickly restored its
> activities and
> was back at >20% of the Tor network's exit capacity within weeks (June
> 2020).
>
> [1]
> https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548
>
> To prevent this from happening over and over again
> I'm proposing two simple but to some extend effective relay requirements
> to make malicious relay operations more expensive, time consuming,
> less sustainable and more risky for such actors:
>
> a) require a verified email address for the exit or guard relay flag.
> (automated verification, many relays)
>
> b) require a verified physical address for large operators (>=0.5% exit or
> guard probability)
> (manual verification, low number of operators).
> It is not required that the address is public or stored after it got
> verified.
> For details see bellow [2].
>
> 0.5% exit probability is currently about 500-600 Mbit/s of advertised
> bandwidth.
>
>
> Q: How many operators would be affected by the physical address
> verification requirement if we use 0.5% as a threshold?
> A: About 30 operators.
>
> There are currently about 18 exit [3] and 12 guard operators that run
> >0.5% exit/guard capacity
> if we ignore the fresh exit groups from 2020.
> Most exit operators (14 out of these 18) are organizations with public
> addresses or have their address published in WHOIS
> anyway.
>
> At the end of the upcoming blog post I'd like to give people some idea as
> to how much support this proposal has.
>
> Please let me know if you find this idea to limit attackers useful,
> especially if you are a long term relay operator,
> one of the 30 operators running >=0.5% exit/guard capacity, a Tor
> directory authority operator or part of The Torproject.
>
>
> thanks for your support to fight malicious tor relays!
> nusenu
> --
> https://mastodon.social/@nusenu
>
>
> [2]
> Physical address verification procedure could look like this:
>
> The Torproject publishes a central registry of trusted entities that
> agreed to verify addresses of large scale operators.
>
> The registry is broken down by area so no central entity needs to see all
> addresses or is in the position to block all submissions.
> (even though the number of physical address verifications are expected be
> stay bellow 50 for the time being).
>
> Examples could be:
>
> Riseup.net:  US, ...
> Chaos Computer Club (CCC) :  DE, ...
> DFRI: SE, ...
>
> (these organizations host Tor directory authorities)
>
>
> - Relay operators that would like to run more than 0.5% guard/exit
> fraction select their respective area and contact the entity to
> initiate verification.
>
> - before sending an address verification request the operator verifies
> that they meet the following requirements:
>   - the oldest relay is not younger than two months (
> https://community.torproject.org/relay/community-resources/swag/ )
>   - all relays have a proper MyFamily configuration
>   - relays include the verified email address and PGP key fingerprint in
> the relay's ContactInfo
>   - at least one of their relays gained the exit or guard flag
>   - they have a sustained bandwidth usage of at least 100 Mbit/s
> (accumulated)
>   - intention to run the capacity for at least 4 months
>
> - upon receiving a request the above requirements are verified by the
> verification entity in addition to:
>   - relay(s) are currently running
>   - the address is in the entity's area
>
> - a random string is generated by the address verification entity and send
> with the welcome tshirt (if requested) to the operator
>
> - after sending the token the address is deleted
>
> - upon receiving the random string the operator sends it back via email to
> the verification entity
> while signing the email with the PGP key mentioned in the relays
> ContactInfo
>
> - the verification entity compares the received string with the generated
> and mailed string
>
> - if the string matches the entity sends the relay fingerprint to the
> directory authority list to unlock the cap for the operator
>
> After this one-time procedure the operator can add more relays as long as
> they are in the same family as the approved relay (no new verification
> needed).
>
>
I would not be very happy to be required to give away personal identifying
information even if it's a "trusted entity".

Even if Tor is focused on offering anonymity to its users and not
necessarily to its relay operators a move towards this by an organisation
that supports privacy wherever they can would seem like a strange idea to
me.

I remember that i sug

Re: [tor-relays] Authority Nodes

[Michael Gerstacker]

Am Mo., 22. Juni 2020 um 22:28 Uhr schrieb nusenu :

> I would assume that operators running relays in an end-to-end correlation
> position [1] due to incomplete MyFamily configuration are not considered
> eligible to run a directory authority.
>
> [1] https://nusenu.github.io/OrNetStats/endtoend-correlation-groups
>
>
I just would like to remember that your list is not as useful as you think
it is.

I have an exit for some time now which i intentionally don't list in my
family because for reasons no one needs to know i don't want to be
associated with it
(no i don't do traffic correlations attacks with it and i don't harm the
network or its users in any way).

I think this is a very good reason to not use the MyFamily option and
anyway some of the attacks teor pointed out can get mitigated when it's not
visible that the operator is the same one.

Technically your list should list it but it doesn't because just changing
the contact info and name is enough to not get recognized.


And when it's about trust i would rather trust someone who fails to include
the (partially) useless and painful implemented MyFamily option then
someone who builds a list which is easy to fool and not solving its purpose
but annoying honest operators.


Just saying.


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

Re: [tor-relays] Ubuntu Focal

[Michael Gerstacker]

I have a relay on Focal Fossa and it required some research for me too but
this is the repository you need to add.

deb https://deb.torproject.org/torproject.org focal main
deb-src https://deb.torproject.org/torproject.org focal main


Am Mo., 1. Juni 2020 um 10:36 Uhr schrieb Pac-Man :

> When will there be support for Ubuntu 20.04 LTS? There does not seem to be
> a repo setup where you can use focal. I have plenty of bandwidth and
> everything to run a really good relay, but getting any kind of help is not
> happening. I have reached out to the TOR Project community and have
> received no answer.  HOW do you expect new people to become a part of the
> TOR network when no one is there to answer any questions? Everything on
> youtube is old and outdated and no one seems to want to keep any software
> projects going. Maybe one day I will be good enough at this to help people
> in realtime, but until then unless there is anyone that is willing to help
> me I am going to probably mothball my relay. I am sad about it but life
> goes on. Other projects have needs as well.
>
> Rgds,
>
> Nicholas MillerPacman
>
> Sent with ProtonMail  Secure Email.
>
> ___
> 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] Got my first abuse

[Michael Gerstacker]

Am Fr., 17. Apr. 2020 um 10:20 Uhr schrieb NOC :

> I said most not 100%. My exits were in a Datacenter yet they showed up at
> my home. Actually it depends who it is. The local police here was very
> friendly and send me a invitation to visit them in cases with computer
> fraud that were made over the exits, the BKA just gave zero fucks and
> showed up at 06:00 at my home. And took anything looking like tech.
>
> The exits had this.is.a.tor.exit.node as reverse dns and displayed on port
> 80 what tor is, how it works and why i don't have any usefull data for
> them. So if they would have done any kind of more than asking the provider
> who pays for that IP they could have get a hint that they won't find
> anything useful for their case at my home or on the servers
>
Could you give us more info about it?

How long ago was it?
Was it your own hardware in the datacenter?
Which provider was it?

Was there anything in the news about it?


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

Re: [tor-relays] Why does my relay often appears offline in Metrics and should I be worry?

[Michael Gerstacker]

Am Do., 9. Apr. 2020 um 15:39 Uhr schrieb Clément Février <
clem...@forumanalogue.fr>:

> Hello,
>
> I often check my relay trough Metrics, but it often appears as offline
> after some time, from couple of hours to few days. I think it has this
> behavior since December 20. However, my relay seems to run normally. I
> have the usual number of connections when I check in Nyx. I don't see
> anything in the log.
> But, in Nyx, I don't see the flags that I see when it appears as online
> in Metrics.
> What I do is to restart the service, but I'm not sure if it's what I'm
> suppose to do.
>

I had the same problem some days ago but only once.
The relay was shown as offline on Metrics and all flags in nyx were gone.
I did not saw anything strange in the logfile and a reboot did not solved
the problem.

The next morning everything was back to normal.

I switched it from a non-exit to an exit the day before and was still
messing around with the Exit policy so i thought it was related to this.

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

Re: [tor-relays] Why MyFamily?

[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?

[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?

[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?

[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
h

Re: [tor-relays] Why MyFamily?

[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?

[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 declaration

[tor-relays] Why MyFamily?

[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

Re: [tor-relays] 100% CPU load on Windows Server 2019

[Michael Gerstacker]

Hi teor,


> > On 18 Feb 2020, at 06:10, Michael Gerstacker <
> michael.gerstac...@googlemail.com> wrote:
> >
> > Once the consensus diffs are processed the load drops to normal.
> > After some time without anything noticeable for me in the debug logs the
> CPU suddenly jumps to 100% again and stays there till another consensus
> diffs are arriving.
> >
> > Its not as worse as it was the first two days where i had 100% CPU load
> half of the time but i still have this about 10-15 times a day for a few
> seconds or minutes each.
> > For the next few minutes after the CPU dropped to normal the throughput
> is close to zero so this cant be good for clients.
> >
> > It would be nice to have a fix in 0.4.4 stable or earlier so that i can
> decide if i want to buy a Windows license key or rather shut it down.
>
> Does setting "DirCache 0" in your torrc resolve the issue?
>

Yes it look like thats working.
I lost the Guard flag (like expected) but in the last 24 hours i had no
problems anymore.

There's a suggested patch on the ticket:
> https://trac.torproject.org/projects/tor/ticket/24857#comment:39
>
> But we've had trouble getting people to help with Windows development
> and testing.
>
> Can you compile tor from source for Windows?
>

i've never done that before. If there is a step-by-step guide it might be
interesting to learn.

Or if we get a fix merged into tor, can you install the Windows
> "Tor Expert Bundle" ?
>

This should be no problem.

I think i will keep the Windows setup at least for some time so if i can
help that way feel free to send me or point me to anything Windows related
what needs some testing in real world.


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

Re: [tor-relays] 100% CPU load on Windows Server 2019

[Michael Gerstacker]

> what say the logfile ?
>

Once the consensus diffs are processed the load drops to normal.
After some time without anything noticeable for me in the debug logs the
CPU suddenly jumps to 100% again and stays there till another consensus
diffs are arriving.

Its not as worse as it was the first two days where i had 100% CPU load
half of the time but i still have this about 10-15 times a day for a few
seconds or minutes each.
For the next few minutes after the CPU dropped to normal the throughput is
close to zero so this cant be good for clients.

It would be nice to have a fix in 0.4.4 stable or earlier so that i can
decide if i want to buy a Windows license key or rather shut it down.


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

Re: [tor-relays] Would you place your secrets or in worst case make your life

[Michael Gerstacker]

>
> I hope more people do come on board of this discussion now!
>

I dont think that there should be a fixed percentage about how much one
person is allowed to add.

"We need more relays ... but not from you! We don't reject your
fingerprints because we don't think that you are malicious but we don't
want you to add more relays just because!"

This sounds not very useful to me.

This might be something to consider if there would be that many relays that
literally every circuit got its own relays but if that would be the case
then it would be much more difficult for one single person to add so much
bandwidth.

So far i think the best way is to reject fingerprints or a whole family
once they do something provable malicious and in my opinion just adding
more bandwidth than other people is not malicious.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 100% CPU load on Windows Server 2019

[Michael Gerstacker]

Hi,

for diversity purposes and curiosity i decided to choose Windows Server
2019 together with TheOnionPack for my first exit relay.
But before it even started to process any user traffic the CPU from time to
time gets maxed out for several minutes what makes it ugly to operate a
relay on Windows.

Looks like its this one:
https://trac.torproject.org/projects/tor/ticket/24857

Will there be a fix soon or should i rather switch to Linux?


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

[tor-relays] A relays primary entry guards

[Michael Gerstacker]

Hi,

from time to time i see that message in the logs of my guard relay:

21:09:06 [NOTICE] I learned some more directory information, but not enough
to build a circuit: We're missing descriptors for 1/2 of our primary entry
guards (total microdescriptors: 6270/6294). That's ok. We will try to fetch
missing descriptors soon.
21:09:06 [NOTICE] Our directory information is no longer up-to-date enough
to build circuits: We're missing descriptors for 1/2 of our primary entry
guards (total microdescriptors: 6270/6294). That's ok. We will try to fetch
missing descriptors soon.

The message itself is clear to me and i usually dont get any errors related
to that but i would like to know for what does a (guard) relay has primary
entry guards?
I thought only clients need guards so what is a relay doing with primary
entry guards?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] MyFamily line commented out but stays valid?

[Michael Gerstacker]

>
> Can you send us a link to your relay on Relay Search, and a copy of your
> torrc?
>
> It's hard to debug without detailed information.
>
>
I already filled a ticket and included my torrc there like requested from
nick:
https://trac.torproject.org/projects/tor/ticket/32541

Yesterday i checked the MyFamily line on all relays so that it now is
definitely the same on all relays which are part of my family because i
stopped caring about the MyFamily option weeks ago after it seemed to not
work like expected.
Then i sent a HUP on all relays and waited for metrics to show them like
expected so that all 23 relays are shown as "Effective Family Members" on
all relays and that no relay is listed as "Alleged Family Member" now.
About two hours later the changes were shown that way in metrics.

Then i commented out the MyFamily line on angeltest8
7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06

and sent a HUP on that relay again.

Four hours later still nothing changed in metrics so i stopped and started
the tor daemon to be sure that the commented out MyFamily line is
definitely recognized but today still no change in metrics and angeltest8
is handled like before.

But as far as i understand it angeltest8 should now in metrics show zero
"Effective Family Members" and zero "Alleged Family Members" and all other
22 relays should list his fingerprint as "Alleged Family Member".


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

Re: [tor-relays] MyFamily line commented out but stays valid?

[Michael Gerstacker]

Am Di., 22. Okt. 2019 um 19:04 Uhr schrieb :

> On 22.10.2019 18:53, Michael Gerstacker wrote:
>
> > when i comment out the MyFamily line with an # in the torrc on one
> > relay it
> > seems to be still handled like before.
> >
> > Hitting x in nyx or waiting a few days or rebooting does not make any
> > change.
>
> Nyx or arm must be called as root to save the config.
>
> Look at the torrc file with nano or vim.
>

I always edit the torrc with nano and use nyx only to reload the torrc so
this cant be the reason.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] MyFamily line commented out but stays valid?

[Michael Gerstacker]

Hi,

when i comment out the MyFamily line with an # in the torrc on one relay it
seems to be still handled like before.

Hitting x in nyx or waiting a few days or rebooting does not make any
change.

Is this expected?

I expected that relay to show as part of no family now and listed as
"Alleged Family Member" on all other relays which still list that
fingerprint in their torrc.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Questions about Fallbacks

[Michael Gerstacker]

Hi,

when i setted up my relays i choosed 443 as the ORPort.
My thought behind it was that 443 is most likely not blocked and less
likely observed because the ISP could expect to anyway only see encrypted
data so a Tor connection will more likely slip through it.

I let the DirPort on 9030 because i read that clients anyway only use the
ORPort and i thought if a authority will connect to me it makes no
difference because none of my ports is blocked.

Now some of my relays are Fallbacks.

Would it be a benefit for the network if i change the DirPort to 80 or is
the DirPort still not used by clients?

Is it necessary to opt-out the relay as a fallback if it was shut down by
the provider and already is long gone from metrics?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?

[Michael Gerstacker]

Hi

Am Do., 5. Sept. 2019 um 04:12 Uhr schrieb Mike Perry <
mikepe...@torproject.org>:

> How can we fix that for you, or at least, how can we make it easier to
> run the very latest stable series Tor on your relay?
>

When i started my first relay i had zero knowledge about Linux so i can
describe my whole experience from a noob position.

I wanted to start to learn about something new and someone told me a
Raspberry Pi is good to start with Linux. Then i had that Pi with Raspbian
and didnt knew what to do with it now.
I found an instruction on google how to install a Tor relay to contribute
to Tor.
It took me more than two weeks with many angry moments followed by many
facepalms but finally my first relay was working.
Now about one year later i operate 25 relays and i love it. I constantly
learn something new and i read everything i can about Tor because its
fascinating and awesome.

It took me months to realize that there is an instruction on your website
how to install a relay. At the beginning i always used some guides which i
found on google because they appear before the instruction site of the
Torproject appears.

If you could point out that the instructions for installing a relay on
Debian are the same like for Raspbian it had safed me many hours because i
thought it will not work if i use the Debian instructions and i thought its
more like a "tweak" to make a relay running on a Pi because on your website
i can find several OSs but nothing about Raspbian.

After i finally understood how to install packages on my Raspberry Pi i was
very happy that it worked and i was afraid to touch anything.
It took me some more months to even realize that the package in the
repositories is not the latest one.
I thought its working like Windows Update where you will automatically get
the latest stable one when you run apt-get upgrade.
After that realization it took me some more months to understand what an
additional repository is and how and why to add it.

I think there is not much you can do against that. Maybe just support the
versions "as short as necessary" because if someone really wants to
understand what is going on then he will take his time to make it working.
I dont know how big that fraction is but maybe there are several people
outside who just dont know that their relay is outdated.

I am subscribed on this mailing-list after i had half of my relays already
running so maybe there are some people who just dont realize that their
relays version is outdated because they still can see traffic on it.
So i think kicking out relays with outdated versions "as fast as useful" is
a good way to show the operator that he is not very helpful anymore.
When they dont see any traffic anymore they either will try to find out why
and upgrade or they will close the relay but i think if they decide to
close the relay they are anyway not very reliable.

To sum it up:
- Make it as easy as possible to find the setup instructions
- Point out that Raspbian is supported too
- Make it more obvious that an operator could be much more useful if he
would take a few minutes to upgrade

I remembered that someone here asked a few months ago how to set up a relay
on Windows.
Out of boredom a few days ago i grabbed a one-month-description VPS with
Windows Server 2012 R2 on it and tried to set up a relay there.
I felt familiar immediatelly even if i had never worked with Windows Server
before and the relay was running after 15 minutes.
F9C203B9FB710FC9C7C45F2CCDF8B626F2320253

There were only three small points where i struggled a little bit because
Tor crashed without telling me why but setting it up on Windows seems to be
as easy as on Linux.
If it helps i can describe the crashes i had or write a ticket about it.

An instruction about setting it up on Windows might be not worth the work
but pointing out that if someone is more familiar with Windows that he
should just try his luck because it will likely work could be helpful too.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Fast flag - wrong speed in dir-spec.txt?

[Michael Gerstacker]

Yep makes sense now.
Thanks for clearing this Roger:)

Am Fr., 30. Aug. 2019 um 10:31 Uhr schrieb Roger Dingledine <
a...@torproject.org>:

> On Fri, Aug 30, 2019 at 05:52:22PM +1000, teor wrote:
> > The default value for AuthDirFastGuarantee is still 100 KB.
> >[...]
> > 6/9 authorities use measured bandwidth, rather than reported bandwidth.
> > So your relay won't get Fast unless it is measured by the bandwidth
> authorities,
> > faster than 100 KB.
>
> Right, it's this last part that's critical here. Directory authorities
> that do their own "bandwidth authority" measurements use their bwauth
> numbers rather than the self-reported numbers in the relay descriptor,
> for deciding whether to assign flags.
>
> If you go to the very bottom of
> https://consensus-health.torproject.org/#relayinfo
> and put in this relay nickname or fingerprint, you'll see that 4
> directory authorities -- the ones not running bandwidth authorities --
> look at the self-reported number, and give the relay the Fast flag. But
> 5 of them, which are running bwauths, use their own numbers, which put
> the relay below the threshold. And since 5 is a majority of 9, their
> choice wins.
>
> Hope that makes sense,
> --Roger
>
> ___
> 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

[tor-relays] Fast flag - wrong speed in dir-spec.txt?

[Michael Gerstacker]

Hi Torproject,

as far as i can see my relay currently can advertise 560 KiB/s. That are
573,44 KB/s.
43C7BC2E17FB26B204EC0BD9AA784E4736979087

Following your dir-specs it should get the "Fast" flag if it can provide
more than 100KB/s.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595

At my other relay i already saw it providing 562 KiB/s and it got the
"Fast" flag.
A9DB853547A6459AB5190E62BF2F7B8F068FEB0A

It seems the limit is above 560 KiB/s?
If i remember it right then i already read somewhere that the requirements
are now higher than 100 KB/s so i guess your documentation is wrong?
Am i missing something why my relay with 560 KiB/s dont get the "Fast" flag?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] AvoidDiskWrites

[Michael Gerstacker]

Hi Torproject,

i think about enabling AvoidDiskWrites 1 on all my relays and not only on
my Pi because the prices for the VPS are anyway cheap as f*ck so i think
saving the provider a few disk writes is a nice deal.

In the manual it is described as:
*AvoidDiskWrites* *0*|*1* If non-zero, try to write to disk less frequently
than we would otherwise. This is useful when running on flash memory or
other media that support only a limited number of writes. (Default: 0)

... which is not a very informative description on how it changes the
behavior of Tor. I didnt found any more explanation about it.

I would like to understand what Tor is NOT writing to disk anymore if set
to 1 or what Tor IS writing to disk if set to 0 and if changing that have
any effect for Tor users.
As a relay operator i couldnt really see any difference enabled or not.

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

Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths

[Michael Gerstacker]

Hi!

Good to hear that you guys try to solve the problem of slow measured relays.
For example when i measure my relay

40108FDFA40EDB013F7291F3B4DA3D412ED3A5EF

with the speedtest from tele2 i get about 90 MiB download and about 50 MiB
upload but Tor measures it with about 15 MiB.
Some of my relays are measured very accurate but other ones are measured
with only about 1/5 of what my results are.

I read the sbws documentation about how the measuring process is working
and i am curious about how the experiment is measuring relays.

if possible please publish a little more info about the experiment or at
least the results somewhere.
Thanks

Am Fr., 26. Juli 2019 um 16:35 Uhr schrieb Roger Dingledine <
a...@torproject.org>:

> On Fri, Jul 26, 2019 at 10:18:24AM -0400, Rob Jansen wrote:
> > I am planning on performing an experiment on the Tor network to try to
> gauge the accuracy of the advertised bandwidths that relays report in their
> server descriptors. Briefly, the experiment involves running a speed test
> on every relay for a short time (about 20 seconds).
>
> Thanks Rob!
>
> For context, I asked Rob to do this experiment, because we know that
> the current bandwidth authority design is mis-measuring relays, but we
> don't know how wrong things are. Giving every relay a short burst of
> load should give us some insight into how much traffic that relay can
> handle, which will in turn tell us how much room for improvement there
> is in our bandwidth estimation.
>
> And as a bonus, for this one time, fast relays should actually be
> consistently seen as fast, and the Tor network should be better balanced
> and the user experience should be better. If we like how it works,
> our follow-up task will be to change things so we get this result all
> the time. :)
>
> Woo,
> --Roger
>
> ___
> 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] Call for setting up new obfs4 bridges

[Michael Gerstacker]

Hi,

i wanted to run my bridge on 443 too but i had the same problem on Raspbian
Buster with Tor 0.4.0.5
I asked Google but choosing a port above 1024 was the only thing that made
it working for me.

Am Fr., 19. Juli 2019 um 11:52 Uhr schrieb :

> > On July 19, 2019 at 6:36 AM Ben Riley  wrote:
> >
> >
> > Hi,
> >
> > Thanks for the reply. Yes, I ran that command way back at the start. I'm
> > assuming I don't have to run it every time the machine reboots or
> updates?
> > I ran it again this morning and it made no difference.
> >
> > Ah logs, you say that like I know where those are :P
> > When I run sudo tail /var/log/tor/log - I get nothing.
> > I found the Logs app and run that to get all the system logs - way too
> much
> > stuff and I couldn't move it to here, so I found this command (Google)
> cat
> > /var/log/syslog | grep tor -i and got the following (I think I've
> included
> > 2 set of attempts to boot up):
> >
> > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Starting with guard context
> > > "default"
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Signaled readiness to
> systemd
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bootstrapped 5% (conn):
> > > Connecting to a relay
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Server managed proxy
> > > encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind:
> > > permission denied)
>
> I ran (and keep running) into the same problem (but on Debian), even after
> the fix suggested below.
> Could you please try an unused port above 1024, like 8531? That resolved
> this issue for me.
>
> hope this helps and kind regards.
>
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Managed proxy at
> > > '/usr/bin/obfs4proxy' failed the configuration protocol and will be
> > > destroyed.
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: tor_assertion_failed_():
> Bug:
> > > ../src/feature/client/transports.c:1836: managed_proxy_stdout_callback:
> > > Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on
> Tor
> > > 0.4.0.5 )
> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bug: Assertion
> mp->conf_state
> > > == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at
> > > ../src/feature/client/transports.c:1836. Stack trace: (on Tor 0.4.0.5 )
>
> (removed rest of log)
>
> >
> >
> >
> > On Fri, Jul 19, 2019 at 1:12 AM Philipp Winter 
> wrote:
> >
> > > On Thu, Jul 18, 2019 at 12:50:34PM +1000, Ben Riley wrote:
> > > > Then I saw the above email about being a bridge and thought, fine,
> I'll
> > > > configure it to be a bridge and help out someone.
> > > > Tried to do it via the docker/script method, but soon realised that
> was
> > > > outside my skill level (hey stop laughing! :P)
> > >
> > > Did you run into any specific issues?  If you had troubles following
> the
> > > guide, I'm gonna blame the guide.
> > >
> > > > Setting ORPort to 443 as suggested.  I forwarded that port on the
> > > > router and then tested it, but it said it was closed. So I thought my
> > > > router was playing up.  I checked a few other ports using online
> tools
> > > > and a few of them were closed.  I forwarded a new another port to
> some
> > > > other software on another machine and that worked?!  So I realised
> the
> > > > ports are open on the router but closed on the ubuntu machine.  I've
> > > > played around with all the settings, changed by torrc file to a
> really
> > > > basic one of:
> > >
> > > To run obfs4 on port 443, you will have to run the following command,
> to
> > > allow obfs4proxy to bind to port 443:
> > >
> > >   sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
> > >
> > > If you did that already, it would be helpful to see your logs.
> > >
> > > Cheers,
> > > Philipp
> > > ___
> > > 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
> ___
> 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

[tor-relays] tor_bug_occured_(): This line should not have been reached

[Michael Gerstacker]

Hey guys,

my relay
79E683340B80676DCEB029E48FBD36BC66EBDA1E
told me:


Jul 06 15:22:34.000 [notice] DoS mitigation since startup: 0 circuits
killed with too many cells. 150515 circuits rejected, 16 marked addresses.
0 connections closed. 104 single hop clients refused.

Jul 06 16:23:25.000 [warn] tor_bug_occurred_(): Bug:
../src/core/or/channeltls.c:: channel_tls_handle_cell: This line should
not have been reached. (Future instances of this warning will be silenced.)
(on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: Line unexpectedly reached at
channel_tls_handle_cell at ../src/core/or/channeltls.c:. Stack trace:
(on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x46)
[0x562903c4faa6] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0)
[0x562903c4b1c0] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug:
/usr/bin/tor(channel_tls_handle_cell+0x49a) [0x562903ad571a] (on Tor
0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x9a16a) [0x562903af916a]
(on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug:
/usr/bin/tor(connection_handle_read+0x99d) [0x562903ac318d] (on Tor 0.3.5.8
)

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x69ebe) [0x562903ac8ebe]
(on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug:
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f469cdbf9ba] (on
Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug:
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)
[0x7f469cdc0537] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xb0)
[0x562903aca290] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10e5)
[0x562903ab80d5] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a)
[0x562903ab530a] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(main+0x19)
[0x562903ab4ec9] (on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug:
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f469c6a109b]
(on Tor 0.3.5.8 )

Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
[0x562903ab4f1a] (on Tor 0.3.5.8 )

Jul 06 21:22:34.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00 hours,
with 5113 circuits open. I've sent 2802.42 GB and received 2781.10 GB.

Jul 06 21:22:34.000 [notice] Circuit handshake stats since last time:
13801/13801 TAP, 169020/169020 NTor.


Its anyway a little bit strange because this is the only relay i have which
never deleted his logfiles since i set it up and where i can not change the
language of the operating system.
I think its related to the host system but i never really thought about
because it seems to work fine.

Something i should do now?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Fallback Directory Mirror

[Michael Gerstacker]

Hi,
i run 17 Entrys and one bridge at the moment.
I dont plan to change the IP adresses or the ports and most of them are
already paid for nearly two years and i dont see a reason to switch them
off after that time so if more fallback directory mirrors are needed then
feel free to add them:

D379A1CB8285748FFF64AE94296CA89878F25B22
9288B75B5FF8861EFF32A6BE8825CC38A4F9F8C2
EE4AF632058F0734C1426B1AD689F47445CA2056
B57A87009FA838471FB2227DDE68165AB2A2FCC4
465D17C6FC297E3857B5C6F152006A1E212944EA
7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06
39F91959416763AFD34DBEEC05474411B964B2DC
4DC4E6187F1193F2717A5E3DF5ACEBD6B162D5CC
57C6DF5B93E54EB9C8DB90029D9E9ABD34D2
3B07C500AC17E7B5A1EE616613E104A094AB87F3
8F6197E5508338B3E3A6BFF59F9EC8F21E1375FB
79E683340B80676DCEB029E48FBD36BC66EBDA1E
A86EC24F5B8B964F67AC7C27CE92842025983274
A9DB853547A6459AB5190E62BF2F7B8F068FEB0A

Some of them are still pretty new but i am sure they will get older:)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays