[tor-relays] Re: Update: Tor relays source IPs spoofed to mass-scan port 22

[Roger Dingledine]

On Thu, Nov 07, 2024 at 03:49:37PM -0300, gus wrote:
> I'm writing to share that the origin of the spoofed packets has been
> identified and successfully shut down today, thanks to the assistance
> from Andrew Morris at GreyNoise and anonymous contributors.

Yay. Thanks Gus, and especially thanks Andrew.

We should expect some more days of fallout, while mistaken abuse
complaints are still being processed by various hosters. That is, if
you get a complaint from your hoster tomorrow, be sure to check the
timestamp before worrying that there is some new variant of the attack.

That said, everybody please do keep watch for some future variation of
this attack. All the attack needs is a hosting provider that doesn't do
egress filtering, i.e. that lets its users pretend to be anybody anywhere
on the internet. Those hosting providers are supposed to be gone from
the world decages ago, but well, the world is flawed in many ways and
this isn't the worst of them. :) At least if it happens again soon,
many people understand the attack now and they will be ready to track
it down quickly again.

--Roger

___
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-le...@lists.torproject.org

Re: [tor-relays] Please check if your relay has fallen out of the consensus

[Roger Dingledine]

On Tue, Oct 29, 2024 at 04:35:35AM +, pasture_clubbed242--- via tor-relays 
wrote:
> "Eclipse attacks occur when a node is isolated from all honest peers but 
> remains connected to at least one malicious peer." 
> https://bitcoinops.org/en/topics/eclipse-attacks/
> 
> Could an ASN feasibly deny connections to all official directories besides a 
> malicious one to serve a malicious consensus? Perhaps to be used to then 
> provide malicious controlled circuits or other attacks. 

That style of attack is actually one of the reasons why Tor still has
the directory authority design. Some of the other 'distributed trust'
anonymity designs out there (no need to name names, that's not the point)
have less control over who the relays are, but much more importantly they
have less control over which pieces of the network clients learn about,
which can lead to all sorts of attacks and surprises.

> I understand that there seems to be a signing of the consensus by directory 
> authorities. Can an outdated, yet cryptographically valid, consesus be served 
> by malicous DA's when others are eclipsed? Perhaps this could serve an older 
> or more vulnurable consensus. 

No, those sorts of attacks should not be possible, and if you find some
way to break it, please let us know!

For a distant-past background paper on the topic of learning things
about the user if they only know about a subset of the network, check out
https://www.freehaven.net/anonbib/full/date.html#danezis2006rfa
and then for a slightly more recent analysis showing how hard it is
to protect against these attacks in "structured" scalable peer-to-peer
anonymity networks, see
https://www.freehaven.net/anonbib/#wpes09-dht-attack

All of this said, Tor's directory authority design is not perfect. It
might benefit from using some of the innovations from the consensus /
blockchain worlds over the past decade, in terms of fast robust agreement
among peers about the state of the network. For a concrete edge case where
we could do better, see this paper from this year's Oakland conference:
https://www.freehaven.net/anonbib/#directory-oakland2024

So, for sure the directory design isn't quite as good as we might like
it to be; but one of its big strengths, which has come in handy over
the years, is that it is really simple.

--Roger

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

Re: [tor-relays] Tor relays source IPs spoofed to mass-scan port 22?

[Roger Dingledine]

On Tue, Oct 29, 2024 at 04:33:33AM +0100, Pierre Bourdon wrote:
> Kind of like someone spoofing source IPs to send SYNs
> everywhere.

Sounds right. See
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85
where I walked through the analysis, for transparency and to help other
folks learn more about how the internet works.

It is a shame that whoever is sending this traffic clearly wants to
undermine safety on the internet. :(

--Roger

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

[tor-relays] Please check if your relay has fallen out of the consensus

[Roger Dingledine]

Hi folks!

We're hunting down a mystery where two of our big university relays are
having troubles reaching the Tor directory authorities:
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86

Can you check to see if your relay is in a similar situation?

In particular, the situation to look for is "Tor process is
still running fine from your perspective, but, relay-search
(https://atlas.torproject.org/) says you are no longer running."

If your relay is in this situation, the next step is to check your Tor
logs, try to rule out other issues like firewall rules on your side,
and then (if you're able) to start exploring traceroutes to the directory
authority IP addresses vs other addresses. If you need more direct help,
we can help you debug or answer other questions on #tor-relays on IRC.

Thanks,
--Roger

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

Re: [tor-relays] relays and CUPS vulnerabilities

[Roger Dingledine]

On Fri, Sep 27, 2024 at 09:41:29AM -0400, George via tor-relays wrote:
> There are some very significant recent CVEs out for CUPS, the unix
> printing system.
> 
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups
>[...]
> Needless to say, a CUPS server listening on 631/tcp or 631/udp while
> providing Tor access is a bad idea.

George and I took the opportunity to scan relays and bridges to see if
they have this vulnerable cups-browsed service running. We found 14 relay
IP addresses that did, and 4 bridge IP addresses. This is a pretty good
rate overall!

(I had been expecting to find more bridges, because they're more likely
to be at home and people might be running them from their stock Ubuntu
desktop install or the like. But we found very few, and maybe that is
because at many homes everything is NATed/firewalled by default.)

12 of the 18 had proper contactinfo and I emailed them. One bounced,
one replied and fixed it, and the others haven't replied yet.

There is a fine policy question here, which is "ok so what now? Do we
leave them in place or bump them out of the network?"

I figure I'll wait a week or so and scan these 18 again. But I fear that
the package "fix" will just correct a buffer overflow or something and it
will leave the "they listen to the whole internet and add any printers
that the internet sends them" behavior intact (because one is a bug,
the other is a feature), so my scan won't actually be able to tell if
they updated. Fortunately, which next step we choose doesn't matter much
here, because the numbers we're talking about are so small.

There is a larger conversation we could have, around whether we should
make vulnerability scanning of relays a more common or automated or scaled
thing. I like the idea in theory but in practice I don't think it should
be a high priority compared to our other network health priorities.

I'm tracking details and next steps about the cups issue on the gitlab
ticket,
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/83

--Roger

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

Re: [tor-relays] Relay disconnect & offline on IP change

[Roger Dingledine]

On Wed, Sep 25, 2024 at 05:53:35PM +0700, Tor Relay Net Ops via tor-relays 
wrote:
> I'm currently running a tor relay on a dynamic IP Address connection,
> usually my ISP gives me a new address every day or so-
> 
> Lately [for the past like week or so- /can't remember when it started
> happening/], I have to manually restart it when my WAN IP Address changes;
> to get the relay back online- (systemctl restart tor@default)
> 
> Is there a way to not manually restart tor (besides running a cron script to
> do so)
> 
> Tor 0.4.8.12 on Linux

Hm! It should work. Four thoughts:

(A) What do your logs say? It should be giving you lines like

log_notice(LD_CONFIG, "External address seen and suggested by a "
  "directory authority: %s", fmt_addr(addr));

(A') Actually, what exactly is going wrong? You say you have to restart,
but, is your relay recognizing a new IP address and publishing even though
it isn't reachable at that address yet, e.g. because of firewall rules? Or
is it not even recognizing that the address has changed? Does it recover
if you wait a while?

(B) We had some relay address detection bugs that got introduced in Tor
0.4.5 and never got resolved. So detection is definitely more fragile
than it was in the 0.4.4 days. I think it mainly affects people running
their relays inside containers or other weird situations. But also,
maybe people just quietly stopped trying and left, who knows.

The starting point for investigating those is
https://gitlab.torproject.org/tpo/core/tor/-/issues/40424

(C) The old-school way of handling this was to get a dyndns account and
then set your torrc Address to point to your dyndns hostname. That is,
you run a periodic tool that reaches out to the service and it makes
sure to update the hostname it gives you to match your current address.

Apparently dyndns has turned from the great free service that it used
to be into a mess of for-profit scamminess. But the nice people on irc
point me to https://freedns.afraid.org/ as one option that's also been
around forever and doesn't seem like it's gone scammy yet.

(D) If you investigate it more and you realize you have found a specific
bug ("it should do this but it does that instead"), please do open a
gitlab ticket, to help the next person:
https://gitlab.torproject.org/tpo/core/tor/-/issues/

Thanks!
--Roger

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

Re: [tor-relays] [Important] Update on an upcoming German broadcasting story about Tor/Onion Services

[Roger Dingledine]

On Mon, Sep 16, 2024 at 08:17:25PM +, pasture_clubbed242--- via tor-relays 
wrote:
> Something I always found confusing is what the difference is between the 
> Vanguards Github project, and the version of Vanguards that Tor has 
> implemented. I thought Vanguards was added into Tor no? Is the Vanguards 
> project still useful despite this?
> 
> I'm not sure if this spec is the exact implementation or a recommendation for 
> an external plugin. 
> https://spec.torproject.org/vanguards-spec/full-vanguards.html
> I have also seen other mentions of an implementation elsewhere. 

The "full" vanguards design includes other changes to how Tor handles
edge cases and unexpected circuit/stream behavior which might be able to
be used as a side channel, but the main tradeoff is that it slows down
your circuits. You have to run it alongside your Tor, as a controller,
which means it is not for "end" users. You can read about it on this
blog post:
https://blog.torproject.org/announcing-vanguards-add-onion-services/

Whereas the "lite" design is a subset of the full design, which we built
into C-Tor back in 2021-2022 when it became clear that some of these guard
discovery attacks we worried about might actually be more practical than
first thought. You can read about vanguards-lite in Proposal 333:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/333-vanguards-lite.md
and you can read one of the motivations for it in this research paper:
https://petsymposium.org/popets/2022/popets-2022-0026.pdf

And lastly, there is a great explanation of both variations of vanguards
in this blog post talking about adding them to Arti:
https://blog.torproject.org/announcing-vanguards-for-arti/

--Roger

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

Re: [tor-relays] Bridge node configurations and where to find them (semi quote)

[Roger Dingledine]

On Sun, Aug 25, 2024 at 12:40:02PM +, Alessandro Greco via tor-relays wrote:
> In the past, I set up a middle relay node, and today I am looking to 
> experiment with configuring a Bridge node to support the Tor project and its 
> community.

Great!

Be sure to run your bridge on a different IP address than you run your
public relay(s): there are censors out there that pull the list of public
relays and block them by IP address, so if you have a bridge on one of
these known addresses it could end up blocked this way.

> First, I will summarize the `torrc` configuration file (I have removed the 
> ports as they differ from the standard ones):
> 
> ```
> BridgeRelay 1
> ORPort 
> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
> ServerTransportListenAddr obfs4 0.0.0.0:
> ExtORPort auto
> ExitPolicy reject *:*
> ```

Looks good. You don't need the ExitPolicy line (you're just setting it
to the default), but it doesn't hurt to have it there.

And if this is on Debian and your Tor deb applies apparmor, you might
need to do the 'systemctl edit' steps listed on
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/
in order to let Tor launch obfs4proxy.

> I have set two limits on the connections:
> ```
> BandwidthRate 300 MBytes  # I want to determine how much bandwidth I can 
> allocate without impacting my network usage.
> IPv4Only
> ```

That's a huge bandwidthrate, so I expect your bridge will never get
anywhere close to reaching it. This is fine too. Also be sure to learn
about 'BandwidthBurst' in case its behavior is surprising to you.

The IPv4Only entry isn't a valid torrc line, so maybe you mean something
else there like writing that on your ORPort?


> As for the information settings, I have used the usual `ContactInfo` and 
> `Nickname`.

Sounds good.

> While reading the `torrc` documentation, I discovered the Sandbox feature, 
> which is still in development. In this regard, I would like to ask whether 
> using experimental features like this on Bridge nodes is advisable or not. 
> Personally, I would find a feature like this very useful.

Sure, feel free to turn on "Sandbox 1". If it works for you, great. If
it breaks for you in a way that you think is a bug, consider filing a
gitlab ticket.

> Should an anti DDoS system be configured?

I would say you don't need to mess with those options, especially for
a bridge, unless some sort of overload starts happening to you.

And for bridges you probably won't see any sort of overload -- most of the
time they get very little use, because either they remain mostly unknown
(so the load doesn't grow that high), or they become too known and then
the censors block them (so the load doesn't stay high).

If you are excited to use more bandwidth than your obfs4 bridge turns
out to use, consider running a headless snowflake proxy:
https://snowflake.torproject.org/#extension
and scroll down to "Run a standalone proxy" which leads to
https://community.torproject.org/relay/setup/snowflake/standalone/

> I wanted to ask how I can further contribute to the Tor Project's research, 
> as I have read that there are "Statistics" features that allow the collection 
> of useful information for the developer community. I have two main questions 
> about this:
> 
> 1. Is it advisable to use experimental features or those that collect 
> information on a Bridge node (assuming there is a difference between a 
> Bridge, a Guard/Middle relay, and an Exit Node)?
> 2. If the answer to the first question is yes, what are all the features that 
> I can include in the `torrc` file to passively support research within the 
> Tor Project?

Feel free to mess with your torrc options if you find it fun. Remember
that you shouldn't need to mess with them for normal operation though.

Search for the 'STATISTICS OPTIONS' section in 'man tor' to see the
options. Your Tor will write out its daily aggregated summaries in stats/
in your DataDirectory.

That said, looking at the code it seems we auto-disable some of these
statistics options when you are not a public relay:

  /* Only collect other relay-only statistics on relays. */
  if (!public_server_mode(options)) {
options->CellStatistics = 0;
options->EntryStatistics = 0;
options->ConnDirectionStatistics = 0;
options->ExitPortStatistics = 0;
  }

so don't be surprised if some of them have no effect.

> Finally, I would like to ask what information should be kept confidential 
> when managing a Bridge. For example, I know for sure that it is important to 
> keep the IP address confidential to avoid the risk of being blacklisted, but 
> are there any other pieces of information that need to be protected?

There are two categories of data you want to keep safe:

(1) IP address and relay identity fingerprint. The fingerprint is the hash
of the public key, and people can use the fingerprint to look up sensitive
details of the bridge like its address. (The hashed fingerprint, aka hash
of hash of public key, is s

Re: [tor-relays] Seeking Advice on Running Multiple Tor Relays or A Bridge

[Roger Dingledine]

On Sat, Jul 06, 2024 at 06:34:37PM +, Alessandro Greco via tor-relays wrote:
> I have some experience running a Tor relay, and I am now interested in 
> setting up another one. I plan to do this using my home internet connection, 
> which is an FTTH line with bandwidth up to 2 Gbps.

Thanks for running a relay!

> I have read that it is possible to run multiple relays on the same node, but 
> I am unsure how to configure this.

If you're using the tor deb (e.g. on Debian or Ubuntu), it comes with
a tool to set up multiple tors. "man tor-instance-create" to get started.

There is also the possibility of using the fancy automated
deployment tools that some of the bigger relay operators here
use, which probably only makes sense if you are already familiar
with these automation tools (a popular one based on ansible:
https://github.com/nusenu/ansible-relayor ).

In either case, make sure you have enough memory in your system to
handle each Tor relay: relays can use 1 or 2 gigabytes of memory each
during normal operation, but when the network is under load it can go
much higher than that.

> Additionally, I am curious about what would be most beneficial for the Tor 
> network today: a highly resilient bridge or multiple relays managed from the 
> same node?

If you have the bandwidth (which it sounds like you do), the multiple
fast relays will be much more useful to the network.

See also https://2019.www.torproject.org/docs/faq#RelayOrBridge

> Is it feasible to operate both at the same time? This is probably not the 
> best idea since the bridge's IP address would be public, right?

It is technically possible yes, but as you say, having a public relay
on the IP address will undermine the effectiveness of your bridge on
that IP address.

The same logic is also why we don't recommend running two different
kinds of bridges on a single IP address: if one of them gets discovered
and the censor blocks by IP address, then the other will stop working too.

> I am looking for guidance on the best course of action to support the Tor 
> community.
> Thank you in advance for your assistance,Aleff.

Thanks for wanting to help!

--Roger

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

Re: [tor-relays] Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort

[Roger Dingledine]

On Sun, Jun 23, 2024 at 09:28:23PM +0200, li...@for-privacy.net wrote:
> A few months ago there was a recommendation to not exposing OrPort for 
> bridges.
> This had the unpleasant effect that all bridges were 'red' on Tor Metrics, 
> even though they were running perfectly fine.
> I noticed yesterday after the meeting that everything is 'green' again.
> https://metrics.torproject.org/rs.html#search/ForPrivacyNET
> 
> Thank you, I believe these 6 people did that:
> https://gitlab.torproject.org/tpo/network-health/team/-/issues/318

Right -- I think we are still in the process of fixing that issue. The
current situation as I understand it is that bridgestrap measures whether
your obfs4 port is reachable, and it uploads these results to the metrics
sites, and the metrics sites use them if available instead of looking
at Running.

But currently the "uploads to metrics" step happens once a day, while
bridgestrap produces results way more frequently than that.

And in the past there were surprises where the metrics side would say
something like "I'll call you running if bridgestrap said you were
reachable within the past three hours" -- which is a great design if
you are getting the bridgestrap results rapidly, but not great if you
get them once a day.

So, I'm glad to see that your relay was green again for a bit, but I
fear a bit more work remains until we get there *consistently*. :)

--Roger

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

Re: [tor-relays] Why should we avoid adding bridges fingerprints in MyFamily?

[Roger Dingledine]

On Sun, Jun 23, 2024 at 07:30:00PM +, Edward Cage via tor-relays wrote:
> Quick question about the fingerprints of our bridges. It's clearly written
> in torrc that we should not include them in MyFamily.

Correct.

> I don't well understand why, especially because:
> - Every bridge, and their fingerprints, are publicly listed on Tor
> Metrics;

Actually it is the *hash* of the fingerprint (hash of hash of key)
that is publicly listed in Tor metrics. This way you can look up your
bridge if you know its fingerprint, but other people can't learn more
about your bridge just based on the relay-search page.

> - The contact email is disclosed for each of them, and it allows our
> bridges and relays to be easily linked to a same operator. (or should we use
> a different email address for each bridge?)

It is fine to use the same contactinfo on your bridges and relays --
because it won't help somebody discover your bridge address or bridge
fingerprint if they don't already know it.

Ultimately the right answer is to move to a better design for declaring
families. The current best idea is Proposal 321:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/HEAD/proposals/321-happy-families.md
with more details here:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40134
and a suggestion at the end of that ticket by trinity that seems like
it could be a good short-term fix.

I think all of the core devs who might work on Proposal 321 are instead
working on Arti though, so at this rate it will be a long while until
the topic sees progress.

--Roger

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

Re: [tor-relays] Relay migration

[Roger Dingledine]

On Tue, Jun 04, 2024 at 04:42:50PM +, Eldalië via tor-relays wrote:
> Hello everyone.
> I have to move somewhere else a a (middle) relay I have been running for a few
> years. It will be down for 2-4 weeks, then be back online in a different
> location, with different ISP, at better speed. But it will run on the same
> hardware and software. Should I keep the same keys, or start from scratch?

Thanks for running relays!

I would say that either choice is reasonable. So if there is one that
makes you feel happier about your contribution, go with that one. :)

Having a relay downtime of 2-4 weeks though could really increase the
time until you get flags like Guard back, due to some design flaws in
how the directory authorities track stability. (The simple version of the
issue is: we treat downtime as much more serious than not-existing-yet.)

So for that reason I would probably pick 'start from scratch' if I were
doing it. Making a new set of keys is easy and simple and doesn't really
hurt anything.

--Roger

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

Re: [tor-relays] Relay question

[Roger Dingledine]

On Fri, Dec 08, 2023 at 03:19:49AM +, Mulloch94 via tor-relays wrote:
> Greetings, I was directed to this relay subscription by the owner. I've 
> recently started my own relay and everything has went smooth for the first 
> few days. Then the relay mysteriously went offline for a period of 8-9 hours.

What do you mean by offline? The computer was offline? Or, the relay
process was not running? Or, the relay process was still running but it
was no longer reachable from the outside? Or something else?

I think there aren't enough hints so far for us to guess what happened,
i.e. there is still some mystery.

> Happened while I was sleeping I think, but any rate it came back on after I 
> restarted the tor daemon and rebooted the server. I'm starting to think my 
> firewall configurations might have been the culprit, even though I ran a very 
> rudimentary setup. Basically just:
> -A INPUT -p tcp --dport  -j ACCEPT
> -A INPUT -p tcp --dport 9050 -j ACCEPT
> -A INPUT -p tcp --dport 443 -j ACCEPT
> -A INPUT -p tcp --dport 80 -j ACCEPT
> -A INPUT -j DROP
> 
> Default ACCEPT on OUTPUT

I am no iptables expert, but (a) this sounds like it should work, and (b)
you probably don't want that 9050 line in there, since your Tor relay's
socksport is intended to be only listening on localhost. (Opening up
the firewall for 9050 shouldn't hurt any though, so long as Tor still
only listens on localhost.)

> My ORPort is on 443, so I don't see how this could be interfering. I noticed 
> my server reboot got rid of all my rules, so I'm thinking that could've been 
> the issue. If so, what other ports should I add? Do I even need a firewall 
> for the relay? I don't do anything else with that server, so If it doesn't 
> need a firewall to stay secure I won't use one.

Opinions differ on the importance of firewalls, but technically no,
you would be fine without any sort of rules like these, so long as you
keep track of what applications are running on the system and make sure
things aren't listening on the outside that you didn't intend. If you
aren't a confident and experienced sysadmin though, the firewall rules
are probably helpful because they simplify the question of how much
surface area might be exposed to the world.

> One more thing, I had a flag on my relay that said I needed to "update the 
> descriptor." It went away after rebooting my server as well, could that been 
> the issue?

That sounds normal-ish, and it implies that your relay stopped running
somehow, before that reboot. Next step would be to check the Tor logs,
check the system logs, otherwise try to better understand what is
going on on your computer.

--Roger

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

Re: [tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

On Thu, Aug 10, 2023 at 03:19:06AM -0400, Roger Dingledine wrote:
> EFF has launched their advocacy campaign for getting more Tor relays
> running at universities:
> 
> https://toruniversity.eff.org/

Cooper has posted an update on how the campaign is going:
https://www.eff.org/deeplinks/2023/11/tor-university-challenge-first-semester-report-card

Highlights include:

* we have made contact with more already-existing relays at universities,

* we now have some new relays running at universities,

* and we have made better contact with European NRENs (the national-level
university internet connectivity organizations), particularly the ones in
Switzerland, the Netherlands, and Greece.

> So: if you are at a university, or you know somebody who is and want to
> help them, please consider setting up relays there. It can be anything
> from an exit relay (the most useful to Tor users, but the most work in
> terms of local advocacy and relationship-building), to a non-exit relay
> (still very useful to Tor users, because we need more network diversity),
> to a non-NATed Snowflake bridge (currently used most by people in Iran
> to get around their censorship and reach the Tor network).

This part is still true! No time like the present to get involved. :)

--Roger

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

Re: [tor-relays] "Failed to find node for hop #1 of our path"

[Roger Dingledine]

On Thu, Nov 09, 2023 at 06:33:08PM -0500, William Denton wrote:
> Lately my relay hasn't been seeing much traffic, which I didn't notice for a
> while, but now I'm turning my attention to it.  I just updated to 0.4.8.9
> and see these notices (with some lines cut out):

Thanks for running a relay!

Do you know if you were seeing those messages on earlier Tor versions too?

> Nov 09 13:36:42.000 [notice] Tor has not observed any network activity for 
> the past 521 seconds. Disabling circuit build timeout recording.
> Nov 09 13:38:03.000 [notice] Failed to find node for hop #1 of our path. 
> Discarding this circuit.

These are client-side messages, that is, your Tor is acting as both a
relay (because you configured it that way) and a client (in case you
try to use it that way), and it is not finding itself to be stable as
a client.

These particular circuits are probably the exploratory testing circuits
that Tor clients make at first, to understand how fast their network is
in order to avoid using the bottom 20% ("long tail") of circuits that
take the longest to make.

> There are hundreds of those notices about failing to find a node for hop #1.
> (I don't know why it complains about the network being down to 2013 seconds
> (over half an hour), because I didn't notice anything, but there were scores
> of the same warnings before that.)
> 
> What would cause this, or what could I do to identify the problem?

Well, the first question is, are you sure your network connection is
stable and working this whole time? An easy explanation would be that you
had connectivity problems during that time, and from a relay perspective
Tor just sat there patiently not minding that nobody was arriving, but
from a client perspective it noticed that something was wrong and said so.

I am guessing that this is your relay:
https://metrics.torproject.org/rs.html#details/2A6E7ABF43F9796AD4A13DF2B2047F90E7291A5F

Another possibility, which I don't think applies in your case, is that
your relay is so overwhelmed with traffic, and/or is rate limiting all of
its traffic, that the client-side testing circuits are squeezed out. But
based on the bandwidth graphs I don't think that's happening here.

--Roger

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

Re: [tor-relays] Relay Bandwidth Limit

[Roger Dingledine]

On Mon, Oct 16, 2023 at 09:40:17AM -0400, John Broome wrote:
> My experience with the Snowflake container is that it will blow through the
> bandwidth limit for the month, and your VPS will cut you off until the next
> billing cycle.

Yes, this is correct, the standalone Snowflake does not have rate
limiting built-in currently.

But, running a Snowflake bridge in a container is a different topic
than running a Tor relay (or a Tor bridge).

--Roger

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

Re: [tor-relays] Relay Bandwidth Limit

[Roger Dingledine]

On Mon, Oct 16, 2023 at 01:18:01PM +, Dan wrote:
> Hi all,
> 
> I’ve been running my first relay for a few weeks now. The VPS provider I 
> chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 
> TB” and AccountingStart to
> “day 1 00:00”. It looks as though my relay is going to blow past that limit 
> based on the average data transferred per day and how many days are left in 
> the month. Will it simply stop transferring data when the monthly limit is 
> hit?

Yes, that's how it works.

The one catch to keep an eye out for is that different ISPs count
bandwidth differently, and by default when you set AccountingMax to 5
TBytes, it means up to 5 TBytes in each direction. If your ISP means
"2.5 TBytes in each direction" when it says 5TB of bandwidth per month
(i.e. it counts each byte twice), then you could be in for a surprise.

See the AccountingMax section in the man page for more details, and
see the AccountingRule option in the man page for how to tell Tor that
your ISP means something different than Tor expected.

--Roger

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

Re: [tor-relays] Tor Weather : Node-Flag [Guard] Alert

[Roger Dingledine]

On Tue, Sep 26, 2023 at 07:44:29PM -0400, denny.obre...@a-n-o-n-y-m-e.net wrote:
> I received the following message from Tor Weather. According to Tor Metrics, 
> this exit relay still has no Guard flag.
> 
> Another - slightly more recent - exit relay 
> (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP,
> and still has the Guard flag (although with 0% guard probability).
> 
> Should I do something with this info?
> 
[...]
> > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C 
> > associated
> > with your subscription has lost the Guard flag
> > for more than 1hr(s). This may impact the performance of your service.

Thanks for running relays!

The low-complexity answer: no, don't worry about it. The Guard flag
doesn't really matter for exit relays these days, because the bottleneck
in the Tor network is exit capacity, so clients won't be using exit
relays for their first hop anyway. And even if they weren't exit relays,
I would also say don't worry about it -- run your relays, enjoy feeling
good that you're contributing, and don't feel like you need to be gamified
into collecting all the flags like pokemon.

The medium-complexity answer: you can check out the
individual votes about your relay by going to the bottom of
https://consensus-health.torproject.org/#relayinfo and putting your
nickname or fingerprint there. As you say, the Ernest relay currently has
seven votes for Guard, so it gets the Guard flag, but the Alberta relay
only has 4 votes for Guard, and it needs a majority (5 out of 8) so it
doesn't get it. It's clearly right on the edge. I think the difference is
in measured bandwidth: moria1 and longclaw think it is above the median
bandwidth they see, while gabelmoo and maatuska and bastet think it is
below their median. I would not be surprised if it wavers back and forth,
getting and losing the Guard flag, for the next while.

(This medium-complexity answer is a bit more complex because the
consensus-health website can't reliably fetch each vote from each
directory authority each hour. For example, it's missing tor26's vote
this round. But those votes can still be found in the metrics data set,
e.g. https://collector.torproject.org/recent/relay-descriptors/ )

And the high-complexity answer is that you can see the individual
cut-offs published by each directory authority about your relay, in
their individual vote documents (some assembly required).

$ grep -A10 "^r Alberta" v3-status-votes|egrep "^(stats|w)"
w Bandwidth=4092 Measured=2700
stats wfu=0.997242 tk=845547 mtbf=128371243
w Bandwidth=4092
stats wfu=0.996686 tk=1534488 mtbf=709353
w Bandwidth=4092 Measured=2200
stats wfu=0.999081 tk=2596023 mtbf=2391699
w Bandwidth=4092 Measured=2000
stats wfu=0.999053 tk=2493149 mtbf=2234701
w Bandwidth=4092 Measured=1900
stats wfu=0.999090 tk=2558326 mtbf=2324742
w Bandwidth=4092 Measured=2000
stats wfu=0.999031 tk=2455223 mtbf=2224108
w Bandwidth=4092
stats wfu=0.998203 tk=1692074 mtbf=1269334
w Bandwidth=4092
stats wfu=0.987932 tk=2331276 mtbf=241054

and you can read about what these stats mean at
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2629

Hope this helps,
--Roger

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

Re: [tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

On Thu, Aug 10, 2023 at 11:18:46AM -0600, Gunnar Wolf wrote:
> Yes, I do!
> 
> Please add to the list:
> 
> Universidad Nacional Autónoma de México
> 
> We have been running two relays since 2017/2018, and enabled two additional
> relays (in the same VM / IP address) recently.

Awesome! I will pass your contact info to Cooper, who will add you to
the internal lists he is tracking.

I missed some relays-running-at-educational-institutions on the first
pass, because we don't have an easy way to look up "which relays are at
universities?" If anybody wants to help work on that, it's
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40022

We also have a handful of known great relay operators, such as the ones
run by ibiblio at UNC and a few in Germany, who didn't answer my mails
yet and I expect that eventually we will add them.

Cooper showed me the beautiful shiny challenge coins that he made to
send to university relay operators. They are a work of art. I believe his
plan is to send them to people once their relay has been up for a year,
i.e. some people qualify already but the people who newly start a relay
in response to this EFF campaign will have to keep it going for a while
to earn the shiny object. :)

--Roger

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

[tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

Hi folks!

EFF has launched their advocacy campaign for getting more Tor relays
running at universities:

https://toruniversity.eff.org/
https://www.eff.org/deeplinks/2023/08/announcing-tor-university-challenge
https://www.eff.org/press/releases/eff-launches-tor-university-challenge

We're focusing on universities in particular, not just to get more
capacity for the Tor network, but also to strengthen the connections
between the Tor network and academia. Universities are great locations for
Tor relays for education (Tor is part of every cybersecurity curriculum
these days), for community (growing connections between students and
research groups), and for research (helping the Tor network stay strong
so people can use it for research):

https://toruniversity.eff.org/administrators/
https://blog.torproject.org/tor-heart-pets-and-privacy-research-community/

Having more relays at universities is especially useful because it can
help others to see that running a relay is a normal and straightforward
thing to do.

So: if you are at a university, or you know somebody who is and want to
help them, please consider setting up relays there. It can be anything
from an exit relay (the most useful to Tor users, but the most work in
terms of local advocacy and relationship-building), to a non-exit relay
(still very useful to Tor users, because we need more network diversity),
to a non-NATed Snowflake bridge (currently used most by people in Iran
to get around their censorship and reach the Tor network).

We started the campaign with thirteen institutions that are already
running relays and/or other public infrastructure pieces:

Technical University Berlin (Germany)
Boston University (US)
University of Cambridge (England)
Carnegie Melon University (US)
University College London (England)
Georgetown University (US)
Johannes Kepler Universität Linz (Austria)
Karlstad University (Sweden)
KU Leuven (Belgium)
University of Michigan (US)
University of Minnesota (US)
Massachusetts Institute of Technology (US)
University of Waterloo (Canada)

Hopefully this list will make you impressed / excited / jealous and you
will want to get your university onto it. :)

Later steps in the campaign will be to understand which universities
have IT departments that understand and value Tor, and which ones try
to block you from using Tor on their network or block Tor users from
reaching their webservers. We are also imagining to do an OONI workshop
to help people do "how well does Tor work on this network" tests.

Here is the internal coordination/roadmap ticket if you want to follow
along in detail:
https://gitlab.torproject.org/tpo/community/relays/-/issues/67

Thanks!
--Roger

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

Re: [tor-relays] Middle relay IP blocking

[Roger Dingledine]

On Mon, Aug 07, 2023 at 11:28:32PM +0300, s7r wrote:
> While all the above is true, a thing to remember is to make sure we don't
> end up all renting too many VPS'es or dedicated servers in the same places /
> same AS numbers - we need network diversity, it is a very important factor,
> more AS numbers, more providers, more physical locations, etc. So, running
> at home is super good and recommended from this perspective, provides us
> with the diversity we need, however not being to login to online banking to
> pay an electricity bill because of a middle relay is also way too annoying..
> however who can afford the hassle should definitely run a middle relay or
> bridge at home

Yes, exactly this. If you are interested in running a non-exit relay at
home, and you can tolerate the hassles from occasionally finding that
some service doesn't want to hear from you, then you are definitely
helping the diversity of the Tor network.

Having the Tor traffic concentrated at a few cheapo providers like Hetzner
and OVH is not only scary in the sense that too much traffic goes through
too few cables, but it's also scary because it increases the appeal for
somebody to attack those few companies, either by breaking into their
infrastructure to watch traffic or through more traditional insider
threats like getting an employee there to help them monitor traffic.

The internet already has uncomfortably many bottlenecks -- too few
undersea cables, too few Content Distribution Networks (CDNs), too few
app stores, etc.

> (even Exit relay, I do run an Exit relay at my office place
> and I had one police visit in like 8 years or so).

Follow this advice only with great caution. :) Many people happily
run their exit relay from their home, but it only takes one fresh new
cybercrime detective (trying to make a name for himself by kicking down
a door at 7am, and with no idea what Tor is) to ruin your day.

--Roger

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

Re: [tor-relays] Security implications of disabling onion key rotation?

[Roger Dingledine]

On Wed, Jun 28, 2023 at 02:09:34AM -0600, David Fifield wrote:
> Thanks, that was a subtlety I had missed. Since we are writing about
> bridges, I mostly want to give the bridge perspective. We had formerly
> written this:
>   A relay's current onion keys appear in the Tor network
>   consensus; when clients make circuits through it, they expect it
>   to use certain onion keys.
> We've now changed it to:
>   Tor clients cache a bridge's onion public keys when they
>   connect; subsequent connections only work if the cached keys are
>   among the bridge's two most recently used sets of onion keys.

Makes sense.

> So it sounds like compromise of an onion key is no worse than compromise
> of an identity key, because with an identity key an attacker could cook
> up and sign a new onion key. The exception is that if an attacker
> somehow got an identity key but not current onion keys, and it's a
> bridge that's affected rather than a relay, then the attacker would not
> be able to fool clients that had previously connected and cached the
> past genuine onion keys.

Right. But that window where the cached version protects you is quite
narrow -- it looks like modern clients fetch a new bridge descriptor
every TestingBridgeDownloadInitialDelay (3 hours) (see where we set
next_attempt_at in learned_bridge_descriptor()), and not too long ago
we fetched a fresh bridge descriptor hourly.

The reasoning for the frequent fetches is that fetching the bridge's
descriptor over a one-hop circuit is a low cost operation, and it doubles
as a crude liveness check (since if it succeeds, the bridge should work
for real circuits too, and if it fails, we should mark the bridge as
not working currently).

When Tor starts up with a cached bridge descriptor with a timestamp we like,
I imagine it is not long until we attempt to fetch a fresh descriptor. I
haven't checked our current behavior though. But I would not rely on
this onion key caching for security.

Hope this helps!
--Roger

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

Re: [tor-relays] Security implications of disabling onion key rotation?

[Roger Dingledine]

Thanks Nick! I endorse Nick's response, with two additions:

On Thu, Jun 01, 2023 at 09:07:17AM -0400, Nick Mathewson wrote:
> Onion key rotation limits the time range in which this kind of attack
> is useful: it will only work for as long as the onion key is listed in
> a live directory.

For bridges it is a little bit different, because bridges don't have
an onion key listed in any public (consensus style) directory document
that clients get. Rather, the client connects to the bridge directly and
fetches a full timestamped descriptor from the bridge, which is signed
by the bridge's identity key, and which includes the onion key that the
client should use.

So if you have broken an old (rotated) onion key for a bridge, the
proper attack involves MITMing the connection to the bridge, breaking
or stealing the bridge's identity key too, and crafting a new descriptor
that lists the old onion key.

Whereas if the bridge never rotates the onion key, then you would be
able to successfully attack the CREATE cell that the client sends to
the bridge -- but only if you could see it, which would involve MITMing
the connection to the bridge and also being able to convince the client
that you are the bridge, which I think implies having or breaking the
identity key too. Doesn't seem so bad.

> (Now, any attacker who can steal your onion key can probably also
> steal your identity key too, if you don't keep that offline, and use
> it to impersonate you for even longer. The advantage of using a stolen
> onion key is that it's much harder to detect; all the attacks I can
> think of that use a stolen identity key involve, whereas the
> onion-key-theft attack occurs when you are already in a perfect
> position to be a MITM.)

"...involve publishing a new signed document which others could notice"
maybe?

Though for the bridge case, the attack could be more subtle, in that you
could provide a specially signed descriptor only to your victim user,
who would then learn the special onion key from that descriptor, use it,
and never know that other users received a different descriptor.

An attack like that isn't so bad though, because we still have the second
hop and third hop in the circuit, producing their own forward-secret
session keys with their own properly rotated onion keys, and having the
protections that Nick describes.

--Roger

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

Re: [tor-relays] Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC

[Roger Dingledine]

On Thu, Mar 30, 2023 at 11:04:25AM -0300, gus wrote:
> The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC.
> 
> We're still working on the agenda, feel free to add your topics and/or
> questions on the pad:
> https://pad.riseup.net/p/tor-relay-op-meetup-april-keep
> onionsite:
> http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-relay-op-meetup-april-keep
> 
> WHERE
> Room link: https://tor.meet.coop/gus-og0-x74-dzn
> 
> Registration
>  
> No need for a registration or anything else, just use the room-link
> above. We will open the room 10 minutes before so you can test your mic setup.
>  
> Please share with your friends, social media and other mailing lists!

Reminder! This event is in 21.5 hours, which depending on your
time zone might count as "tomorrow". :)

Looking forward to seeing you there,
--Roger

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

Re: [tor-relays] Police request regarding relay

[Roger Dingledine]

On Tue, Apr 11, 2023 at 12:09:15PM +, Finn wrote:
> Hello everyone,
> 
> We are hosting multiple relays under our AS 210558 and received an email from 
> a local police station in Germany requesting user data, nothing unusual.
> 
> The weird thing is, that the relay in question is only a relay and not an 
> exit node since its creation (185.241.208.179) 
> (https://nusenu.github.io/OrNetStats/w/relay/B67C7039B04487854129A66B16F5EE3CFFCBB491.html)
>  - anyone has an idea how this happens?

Thanks for running relays!

Do you know what kind of user data they wanted?

It looks like your relay has been a Guard relay (i.e. has had the Guard
flag) for most of the past year. One possibility is that they have
somehow decided that a user they are trying to track uses your relay
as one of their Guards. That is, in this scenario they decided that the
user connects to your relay consistently over time, so they are asking
you to help them learn more about that user.

Of course, your Tor relay in its default settings doesn't have any useful
data for them, and you should keep it configured that way.

It is unclear how much people might be trying to do "guard discovery"
attacks in practice, and also unclear how well they might work -- there
is a lot of research on this class of attacks in theory but not much is
known about whether it matters in practice.

And who knows, it could be something else: maybe they are just fishing
for general information, or maybe they are intentionally creating useless
work and stress for you and your hosting provider to discourage you from
wanting to help Tor users.

More reading on the 'guard discovery attack' topic:

* PETS paper, From "Onion Not Found" to Guard Discovery:
https://petsymposium.org/2022/files/papers/issue1/popets-2022-0026.pdf

* The Vanguards idea:
https://blog.torproject.org/announcing-vanguards-add-onion-services/

Part of the vanguards idea is implemented by default in Tor 0.4.7:
https://gitweb.torproject.org/torspec.git/tree/proposals/333-vanguards-lite.md
https://gitlab.torproject.org/tpo/core/tor/-/issues/40363

Hope this helps,
--Roger

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

Re: [tor-relays] publish current AuthDirMaxServersPerAddr limit?

[Roger Dingledine]

On Sun, Feb 12, 2023 at 01:08:56PM +0100, Sebastian Hahn wrote:
> > On 12. Feb 2023, at 11:46, nusenu  wrote:
> > would it be possible to publish
> > the currently enforced value of AuthDirMaxServersPerAddr
> > on some tpo website? Maybe consensus-health.tpo?
> 
> that's a bit hard to do automatically, as the value is currently not
> exported by the dirauths. We'd need a feature to include the value in
> the votes, then it could be displayed. Not sure if the network team
> would work on such a feature, I'd be in favor.

Good idea. I've implemented it in my ```ticket40753``` branch,
described here:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40753

moria1 is including its AuthDirMaxServersPerAddr value in the
consensus params section of its vote, which makes its way to this
webpage:
https://consensus-health.torproject.org/#consensusparams

I'm not sure if this is the best possible design (we're sort of
blurring the line between what is a ConsensusParam and what isn't),
but it should be an easy and safe change at least. :)

nusenu: note that once enough dir auths vote this param, they will
compute a 'consensus' value for it in put that value in the consensus,
but nothing actually looks at or uses that consensus value.

--Roger

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

Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[Roger Dingledine]

On Wed, Feb 08, 2023 at 12:07:22AM +0100, nusenu wrote:
> I recall a gitlab.tpo issue that discussed the details of whether
> tor clients should change guards when their picked guard lost/gained flags.
> Maybe someone else could paste a link to it.

This might be the one you want:
https://gitlab.torproject.org/tpo/core/torspec/-/issues/141

It has quite the complicated story, and I think our current behavior
("move to the next guard in the list if our current guard doesn't have
the Guard flag") is good for performance but bad for security, but it's
a complicated enough analysis that reasonable people can disagree.

--Roger

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

[tor-relays] upcoming directory authority changes

[Roger Dingledine]

Hello fellow relay operators,

Later today (Tuesday) we plan to do a synchronized shift where we
make two configuration changes on the directory authorities. The goal
will be to make these changes while maintaining the right threshold of
signatures so relays and users still get a safe network status consensus
that they trust.

For background, Tor uses a threshold consensus design, where as long as
a majority of directory authorities are behaving properly, all users get
the same accurate view of the Tor network. You can learn more about the
design in the bottom half of
https://support.torproject.org/about/key-management/.

Specifically, we plan to make these changes:

(1) Temporarily remove Faravahar from the set of directory authorities,
until Sina finds a new good home for it. We weren't all comfortable with
its previous hosting location inside Team Cymru's network (see the bottom
of https://blog.torproject.org/role-tor-project-board-conflicts-interest/
for more details), so to be extra safe we are making it no longer
participate in the consensus process until it is reborn in its future
home. You can read more about Sina and why we are excited to keep him
involved in the Tor community at
https://blog.torproject.org/volunteer-spotlight-sina-rabbani-helps-activists-avoid-government-censorship/.

(2) Rotate to fresh identity keys for moria1, the directory authority
that I run. In early November 2022 there was a remote break-in to the
computer running moria1. Based on the evidence and the type of attack,
I believe it was a standard automated attack -- that is, I think they
weren't targeting the directory authority and also they never realized it
*was* a directory authority. But to be extra safe, we decided to rotate
to a fresh set of keys. I was also in the middle of a planned move to
better hardware, so overall it was good timing for a fresh new start.

I should note that for both moria1 and Faravahar, we have no evidence
of any misuse of their keys. But more importantly, the threshold
consensus design keeps Tor users safe *even if* we are underestimating
what happened. Tor users and relays demand a consensus signed by a
majority of the directory authorities, and right now that's five out of
eight. Tor's security/privacy/anonymity properties remained safe before,
during, and after these changes.

Some closing thoughts and details:

* We actually already removed Faravahar in the Tor git repository and
in the Tor release 0.4.7.11 (which came out Nov 10 and has been in
Tor Browser since Nov 22), so modern clients and relays are already
demanding signatures from five authorities that aren't Faravahar. The
change we'll do today is to make the other directory authorities stop
incorporating its vote and signature into the consensus. Doing these
changes at different times opened the window for surprising but harmless
log warnings like https://bugs.torproject.org/tpo/core/tor/40725. We
could see similar issues with the new moria1 key, and if so they should
go away once there's a new release with the new key and you have upgraded.

* In my opinion there is a good argument for every directory authority
making fresh keys every few years anyway, especially in a world with
sophisticated attackers who might try to obtain keys and not leave any
traces. So for example when we bring Faravahar back I think it should
be with entirely new keys.

* Secure consensus designs have become much better in the past decade,
in large part from all the Bitcoin enthusiasm. Our current design was
always intended to be a placeholder until we got something better. And
our friends in the PETS research community have been exploring edge
cases where evil directory authorities can create mischief even when
they're slightly less than a full majority. So while we're triaging
the usual fires and priorities, we shouldn't forget about improving the
directory design.

* Directory authority keys already have a notion of an offline long-term
identity with shorter-lifetime online keys that expire periodically,
with the goal of limiting the future impact of a compromise. But it seems
like this role separation never quite matches up well to the security
issues that arise in practice, whereas it definitely adds complexity
both to the design and to operation. This piece of the design could use
some new ideas.

* Lastly, the directory authority operator community is a community too,
and the security of the Tor network relies on social trust and cooperation
between these fine people. We used to have directory authority operator
meetups in person at security conferences and at Tor dev meetings, to
maintain the social and community connections. Covid put a stop to that
along with so many other things, and we should work to bring it back. We
could start by encouraging directory authority operators to participate
in the monthly virtual relay operator meetups.

Thanks for reading all the way to the end / hope this level of detail helps,
--Roger

_

Re: [tor-relays] Difficulties testing my bridge

[Roger Dingledine]

On Fri, Nov 11, 2022 at 09:45:32PM +0100, binarynoise wrote:
> Went to settings, checked the bridge settings: yes, I had entered by
> bridge-line. Odd.
> 
> Continued to the tor logs: oh, bridge-line didn't parse. Interesting.
> (I put in the server's identity key ed25519 fingerprint instead of the
> not-ed25519 one and put my bridges name somewhere there too).
> 
> Ok, but why doesn't it tell me?
> Why is there no big "Couldn't connect to your configured bridges"-
> warning after hitting the connect-to-tor-button?

This is a Tor Browser bug:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40551
and yes it is a big deal because users expect that once they've entered
a bridge address, and Tor Browser didn't complain, then they will be
successfully using it.

This bug bit us recently because the new default Snowflake bridge line
was too long, causing Tor to log and not use it, so when you selected
"I want a built-in bridge, how about Snowflake" you thought you were
using snowflake when actually you weren't:
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40665

One small question though: you say above that "checked the bridge
settings: yes, I had entered by bridge-line" -- but I believe that one
of the symptoms of the bug is that the bridge line silently vanishes,
i.e. you set it but then it never gets set and the settings page says
you're not using bridges. So please go back and check if you really had
the behavior you describe, since it would be a new and not-yet-known
issue.

> Anyway, does some tool exist, where you enter your bridge's information
> or run it on the server, that tells you if the recommended versions of
> tor + dependencies are installed and actually used?
> That would make the task of keeping the bridge healthy easier.

We have some tools here, but I agree that we could do more on the
usability side:

(1) The bridgestrap tool tells you whether our remote server was able
to handshake with your obfs4 bridge. Your obfs4 bridge should log a
personalized bridgestrap url on successful startup:
Nov 12 13:59:54.694 [notice] You can check the status of your bridge relay at 
https://bridges.torproject.org/status?id=3E2CEE334E23FC346FF4E5797F906B9A1C18EFC4

See https://bugs.torproject.org/tpo/core/tor/30477 for more history.

(2) The relay-search page for your bridge has a bunch of info about it:
https://metrics.torproject.org/rs.html#details/3E2CEE334E23FC346FF4E5797F906B9A1C18EFC4
and relay-search ought to, but I think does not yet, fetch the bridge
status entry and display it too.

(3) dcf wrote a script to remotely assess whether your obfs4 bridge
is running an old obfs4 version or a new enough obfs4 version. It is
currently a confidential ticket, because it includes details about the
distinguisher that a censor might use to gain a small advantage. But
least I checked it is scheduled to go public on Nov 15 i.e. in a few
days. When it does, you'll be able to read it and find the script at
https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/91

In summary: we have some good building blocks here, but the 'last mile'
of relay operator usability definitely needs some work. The bridgestrap
tool should probably integrate dcf's testing script, so it learns and
reports not just "can I handshake with the obfs4 port" but also "is
it running the old buggy version or not". And then relay-search should
import that info and display it too.

I think there are not enough anti-censorship devs, and many many
anti-censorship tools, so this might be good timing for the community
to step in and help.

Thanks!
--Roger

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

Re: [tor-relays] actively maintaining 'recommended versions' list (was: Tor 0.4.6.x is unsupported, please upgrade)

[Roger Dingledine]

On Sat, Oct 08, 2022 at 02:54:41PM +0200, nusenu wrote:
> dir auths still recommend running tor 0.4.6.x versions today, so relay 
> operators never got any indicator
> on RS or in their logs - this is a missed opportunity.

Good catch -- I've just started the process of getting the directory
authorities to un-recommend the 0.4.6 versions.

And you're right that it is a missed opportunity for those fingerprints
that started the process of getting bumped out a few days ago.

But (a) new relays that show up on 0.4.6, i.e. that don't have
fingerprints that are in the reject list, will see the warning about
versions,

and (b) I'm going to hold off on applying the big set of 0.4.6 reject
lines on moria1, so now moria1 should be issuing a warning about versions,
rather than a warning about a rejected fingerprint, to affected relays.

So at least in the case where the operator reads their logs well, they
should have some better idea what is up.

Thanks!
--Roger

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

Re: [tor-relays] We're trying out guard-n-primary-guards-to-use=2

[Roger Dingledine]

On Mon, Jun 27, 2022 at 10:58:42PM -0400, Roger Dingledine wrote:
> So: I am giving you all here some early warning, in case you see anything
> odd on the network when we make this change. Let us know if you do. :)

So far so good. Performance looks like it improved.

The "intro2 cell" overload also stopped over the weekend (yay):
https://metrics.torproject.org/hidserv-rend-relayed-cells.html

But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the majority of the new connections.

If your relay is bumping up against its file descriptor limits,
or otherwise suffering (e.g. more memory usage than desired), one
reasonable option for you might be to set some iptables-level connection
limiting. More details in this ticket:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2818529

Some of the dir auths are suffering from this connection overload too --
longclaw and bastet in particular but I think all of us are feeling it.

As I mention in that ticket, ultimately it seems to me that we'll need
to come up with a guide of recommended iptables rules for big relay
operators to run alongside their Tor. It wouldn't be mandatory (Tor has
some adequate-ish defenses here at the application layer) but it seems
clear that it would do the job better at scale.

--Roger

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

Re: [tor-relays] We're trying out guard-n-primary-guards-to-use=2

[Roger Dingledine]

On Mon, Jun 27, 2022 at 10:58:42PM -0400, Roger Dingledine wrote:
>  this change
> means that clients will now choose between two guard relays by default
> (rather than just one) when building circuits.

One of the people on the forum asked if this change applies to bridge
users (including pluggable transport users) too, and I believe the
answer is yes-it-does.

So if you have two or more bridges configured, with this change your
Tor will now pick two of them to use for your circuits.

More details here:
https://forum.torproject.net/t/tor-is-much-slower-latterly-than-it-used-to-be/3567/33

--Roger

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

[tor-relays] We're trying out guard-n-primary-guards-to-use=2

[Roger Dingledine]

Hi folks,

As part of the hackweek projects
( https://gitlab.torproject.org/tpo/community/hackweek/ ),
some of us are thinking about simple tweaks we can do to tune the network
to better handle this month's traffic overload.

The long term answer is to try out proposal 327:
https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro.txt
because we think a lot of the overload has to do with people sending
way too many intro cells to some onion services, and giving the onion
services ways to defend themselves is the only real answer.

But while we're thinking about implementing that proposal, one of our
earlier steps is to set the guard-n-primary-guards-to-use consensus
parameter from 1 to 2.

Now that it's taken effect (you can watch the votes at
https://consensus-health.torproject.org/#consensusparams ), this change
means that clients will now choose between two guard relays by default
(rather than just one) when building circuits.

This is potentially a big deal, since it puts us into a different point
in the performance vs safety tradeoff space.

Here is some reading for why we originally moved down to 1 guard by default:
https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters/
https://www-users.cse.umn.edu/~hoppernj/single_guard.pdf

But on the theory that some guards are way overloaded right now and
some aren't, giving clients two bites at the apple might make a dramatic
improvement in terms of reliable and consistent performance.

There is also some argument in favor of using two guards anyway. One
reason (explained more in proposal 291) is that there are already
some edge cases where clients use their second guard. And also, in the
glorious future, we will want to be using multiple guards because we
have switched to the multi-path Conflux design (proposal 329) -- though
we're not there yet.

So: I am giving you all here some early warning, in case you see anything
odd on the network when we make this change. Let us know if you do. :)

--Roger

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

Re: [tor-relays] Sanity check on NumCPUs

[Roger Dingledine]

On Wed, May 25, 2022 at 07:31:41PM -0500, Thoughts wrote:
> For a non-exit relay, is "NumCPUs 2" still the recommended maximum?  
> Running on a quad core and recently saw a message indicating I had
> insufficient CPU power to support the desired number of connections...

I would suggest leaving NumCPUs alone, and let Tor use as many cores as
you have. Setting it to 2, when you have more cores than that, will
limit how much Tor can scale.

And that message you saw, which I assume was "Your computer is too slow
to handle this many circuit creation requests!", is exactly about the
number of cores that are allocated to handling incoming create cells.

There are three main pieces to Tor's crypto, and two of them (TLS and AES)
are bottlenecked on the main thread, but one of them (circuit handshakes)
*does* parallelize pretty well.

So if your Tor is complaining about not being able to keep up with
circuit creation requests... consider removing the artificial limitation
of setting NumCPUs lower than it wants to be. :)

--Roger

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

Re: [tor-relays] Weird spike in written bytes per second

[Roger Dingledine]

On Mon, May 23, 2022 at 12:18:41PM +0200, Marco Predicatori wrote:
> the graph shows a marked difference between written bytes per second and
> read bytes per second om 2022-05-19 and 2022-05-20. In any other day the
> bytes are roughly the same. What might my node have "written" on those two
> days?
> 
> https://metrics.torproject.org/rs.html#details/A4E74410D83705EEFF24BC265DE2B2FF39BDA56E

A common answer here is that your relay is serving more directory
information than usual -- directory answers count as "written" bytes
but they don't have corresponding "read" bytes.

Indeed, that seems to be the case for you this time. Taking a look at
your extrainfo descriptor from that time period (attached to this mail for
posterity, but also you can find it on https://collector.torproject.org/
or via a query on your DirPort if you had one open):

published 2022-05-20 23:28:07
write-history 2022-05-20 13:47:42 (86400 s) 
52641878016,29257544704,29532297216,34634562560,121750598656
read-history 2022-05-20 13:47:42 (86400 s) 
52190178304,28933199872,29611094016,31570991104,33742606336
dirreq-write-history 2022-05-20 13:47:42 (86400 s) 
258335744,326073344,385689600,3712866304,87401081856
dirreq-read-history 2022-05-20 13:47:42 (86400 s) 
18748416,468201472,756950016,882057216,1235405824

So yes, it is just that one day, where you pushed 121GBytes but only
received 33GBytes. And the dirreq lines explain why -- they show on that
last day that your relay served 87 gigs of directory info, while only
fetching about 1 gig of it.

More details on those extrainfo lines here:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1191

Now, this leads you to a new question, which is "ok but why was I
serving so much directory information on that day?" -- and I don't know
the answer. We've had a series of mysteries over the past years where
a whole lot of Tor clients appear and each bootstrap. Your mystery is a
pretty small one in scale compared to these others. I guess the summary is
"some users, for some definition of users, did that."

--Roger

extra-info torototela A4E74410D83705EEFF24BC265DE2B2FF39BDA56E
identity-ed25519
-BEGIN ED25519 CERT-
AQQABwNkAYD1Yg2VlRjBGK4bFOTGfqriRvkja8Rx1w/uqTgMlUoEAQAgBACuWp4X
h6E17IAsn/CXO8M+VYMXov1JR1H1/qJPAqUeZK5INA19s4T1xqQETznM2jMR8o1E
oEoe+B9Shs9xfVUwKohcR2BHwxeW+K1CJj9jCCOn+Na71OQAdN5Z3Z0YMA4=
-END ED25519 CERT-
published 2022-05-20 23:28:07
write-history 2022-05-20 13:47:42 (86400 s) 
52641878016,29257544704,29532297216,34634562560,121750598656
read-history 2022-05-20 13:47:42 (86400 s) 
52190178304,28933199872,29611094016,31570991104,33742606336
dirreq-write-history 2022-05-20 13:47:42 (86400 s) 
258335744,326073344,385689600,3712866304,87401081856
dirreq-read-history 2022-05-20 13:47:42 (86400 s) 
18748416,468201472,756950016,882057216,1235405824
geoip-db-digest C4F1B5ECF1B07BBECBE06B93926E4D1E62882782
geoip6-db-digest 0E43B5C62033BFE47F32742D8C9F5B5F83180AA4
router-sig-ed25519 
rVmmvDdFx01brpCeJJAUPnv9XPriigWEagJTaDmYR5YvvblbOs5wGsHQ/UdRC3RxbvTO1yX9vLIsGNChshC0CQ
router-signature
-BEGIN SIGNATURE-
yvnCkMR6MoNrorOhteUvtXcb4rg1yvbY+SY246SV3CE3Cj5Fm+mtUhaaQqmnubA2
hl3BkmBbIsT1HFGob/7wXa6R+U9VarxPsCw5Jy02EUZ1A+kSFE3sO7Wvcc3GfOam
cc7CUcs1m17i6FZWEsklCzqLkf46jx2oyLP02tasRkU=
-END SIGNATURE-
extra-info AmorousLibrarian D1DF0AE44E69E0614A77305B3A12D1A1C7715C0C
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DirPort

[Roger Dingledine]

On Tue, Mar 08, 2022 at 11:25:00AM -0600, Thoughts wrote:
> Coming up on day 3 of my tor relay, "SpinnerDolphin1".  Per the metrics page
> is showing "Dir Address none", but I have a DirPort defined (as nyx
> reports), and opened.

Modern Tor relays don't advertise their DirPort anymore, because nothing
uses it.

More details here:
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40013

That is, you can set your DirPort to 0, or leave it as it is.

Thanks for running a relay!
--Roger

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

Re: [tor-relays] New non-exit relay - DirPort question

[Roger Dingledine]

On Sat, Jan 15, 2022 at 01:40:27PM +0100, Richard Menedetter wrote:
> I installed a non-exit relay 5 days ago.
> Works actually quit nicely.
> I was awarded the stable flag.
> (Also had briefly the HSDir flag, but lost it after a restart. Too early for 
> the Guard flag.)
> So I think everything looks good.
> 
> I have DirPort 9030 in my config.
> It is shown in nyx and the tor process listens there.
> But the relay search page says:
> Dir Addressnone

Yep! This is fine and normal, but I agree it is a surprise.

I just opened a ticket in the relay-search component to help future
relay operators understand why it ends up as a 0:
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40013

Thanks for running a relay!
--Roger

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

Re: [tor-relays] How to reduce tor CPU load on a single bridge?

[Roger Dingledine]

[I'm about to go off-line for some days, so I am sending my current
suboptimally-organized reply, which I hope is better than waiting another
week to respond :)]

On Thu, Dec 30, 2021 at 10:42:51PM -0700, David Fifield wrote:
> Let's make a distinction between the "frontend" snowflake-server
> pluggable transport process, and the "backend" tor process. These don't
> necessarily have to be 1:1; either one could be run in multiple
> instances. Currently, the "backend" tor is the limiting factor, because
> it uses only 1 CPU core. The "frontend" snowflake-server can scale to
> multiple cores in a single process and is comparatively unrestrained.

Excellent point, and yes this simplifies. Great.

> I believe that the "pinning" of a client session to particular tor
> instance will work automatically by the fact that snowflake-server keeps
> an outgoing connection alive (i.e., through the load balancer) as long
> as a KCP session exists.
>[...]
> But before starting the second instance the first time, copy keys from
> the first instance:

Hm. It looks promising! But we might still have a Tor-side problem
remaining. I think it boils down to how long the KCP sessions last.

The details on how exactly these bridge instances will diverge over time:

The keys directory will start out the same, but after four weeks
(DEFAULT_ONION_KEY_LIFETIME_DAYS, used to be one week but in Tor
0.3.1.1-alpha, proposal 274, we bumped it up to four weeks) each
bridge will rotate its onion key (the one clients use for circuit-level
crypto). That is, each instance will generate its own fresh onion key.

The two bridge instances actually haven't diverged completely at that
point, since Tor remembers the previous onion key (i.e. the onion key
from the previous period) and is willing to receive create cells that
use it for one further week (DEFAULT_ONION_KEY_GRACE_PERIOD_DAYS). So it
is after 5 weeks that the original (shared) onion key will no longer work.

Where this matters is (after this 5 weeks have passed) if the client
connects to the bridge, fetches and caches the bridge descriptor of
instance A, and then later it connects to the bridge again and gets
passed to instance B. In this case, the create cell that the client
generates will use the onion key for instance A, and instance B won't
know how to decrypt it so it will send a destroy cell back.

If this is an issue, we can definitely work around it, by e.g. disabling
the onion key rotation on the bridges, or setting up a periodic rsync+hup
between the bridges, or teaching clients to use createfast cells in this
situation (this type of circuit crypto doesn't use the onion key at all,
and just relies on TLS for security -- which can only be done for the
first hop of the circuit but that's the one we're talking about here).

But before we think about workarounds, maybe we don't need one: how long
does "the KCP session" last?

Tor clients try to fetch a fresh bridge descriptor every three-ish
hours, and once they fetch a bridge descriptor from their "current"
bridge instance, they should know the onion key that it wants to use. So
it is that up-to-three-hour window where I think things could go wrong.
And that timeframe sounds promising.

(I also want to double-check that clients don't try to use the onion
key from the current cached descriptor while fetching the updated
descriptor. That could become an ugly bug in the wrong circumstances,
and would be something we want to fix if it's happening.)

Here's how you can simulate a pair of bridge instances that have diverged
after five weeks, so you can test how things would work with them:

Copy the keys directory as before, but "rm secret_onion_key*" in the
keys directory on n-1 of the instances, before starting them.)

Thanks!
--Roger

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

Re: [tor-relays] Relay operators meetup @ rC3

[Roger Dingledine]

On Mon, Dec 27, 2021 at 04:29:10AM +0100, Stefan Leibfarth wrote:
> the annual Tor relay operators meetup will be tomorrow (28th) at 2200 UTC+1.
> No rC3 ticket required


We just finished the meet-up. Thanks Leibi for organizing it, and thanks
everybody for participating. I've attached the notes that we used for
organizing the topics / discussion.

Next meet-up is planned to be around FOSDEM in early February. Stay tuned!

--Roger

Agenda
==

Meetup url: https://jitsi.rc3.world/tor-relay-meetup

network health team ramp-up in 2021 / 2022
  - https://gitlab.torproject.org/tpo/network-health/team
  - bringing metrics team into network-health
  - bumping out end-of-life (EOL) relays

- Community building:
  - relay operator expectations 
https://gitlab.torproject.org/tpo/community/relays/-/issues/18
  - Tor relay operator survey https://survey.torproject.org/index.php/459487

relay operator non-profits https://torservers.net/partners.html
  - our periodic online meetups (original plans of in-person meetups!)
  - What should be the role of a torservers.net central coordination / advocacy 
org?
  - Torservers.net still gets press inquiries, even though it has been dormant 
for a while.
  - notes from November 2021 meetup: 
https://lists.torproject.org/pipermail/tor-project/2021-November/003230.html

Hear from relay operators here (especially exit relay ops)
  - I'd like to hear successful experiences of running exit relays from people 
here. One of my friends hosts one in their home (not a good idea). I think 
evolution VPS sounds like a good deal for an exit relay, but I'm not sure.
  - What are the potential legal consequences of running an exit relay, if 
someone uses it to post illegal material?
- In DE, the Providerprivileg should insulate you somewhat against legal 
consequences (Disclaimer: IANAL), but depending on your local police, you might 
come in contact with them. (Hasn't happened to us so far, though.)
- In EU, it's legal: 
https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0031:En:HTML 
but you might still have the cops "knocking" at your door at 6am and confiscate 
all your hardware, until their sort things out.
- In .fr, as Nos Oignons, we ~regularly get letters from the cops, and some 
convocations to the police station.

Trust:
  - recent big attackers
  - trust in relays, how to quantify, how to label
  - what about nusenu's proposal ( 
https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ ) ?
  - What can we learn from (/ how do we feel about) Apple Private Relay & 
trusting companies?
- 
https://www.apple.com/privacy/docs/iCloud_Private_Relay_Overview_Dec2021.PDF
- https://blog.apnic.net/2021/11/26/impact-of-private-relay-netops-isps/

Relay operator support venues / options:
  - New Tor forum (https://forum.torproject.net/), useful for individual relay 
operator support (alternative to private helpdesk), not intending to replace 
tor-relays@ list
  - tor-relays@ list
  - #tor-relays irc channel
  - relaunch of TorBSDv2 coming

network performance:
- relay overload indicators
- sbws progress
- new congestion control designs should help with geographic diversity

network blocking:
- The Russia story
- 'Run a bridge' campaign
- (un?)fortunately, most people here are running relays, so can't run 
bridge on the same machines
- what types are important -> obfs4
- what internet connection type is best -> static IP
- Belarus, previous blocking stories

ipv6:
- How to run a Relay with a dynamic IPv6 only address?
- ipv6-only relays, soon?
- no :'(
- chicken & egg problem - as long as most relays are ipv4 → tor will stay 
ipv4
- ipv6-only bridges?
- (did setup one today … not yet listed at 
https://metrics.torproject.org/rs.html#search or 
https://bridges.torproject.org/status?id=[…] )
- There's no reason in principle why ipv6-only bridges shouldn't work. 
People should try them, identify what goes wrong, and help us fix!
- Is anyone seeing *any* ipv6 traffic to obfsproxy4? (No not handed out 
yet.)

Offline Master Keys:
  - How do you deal with renew of OMKs?, Best practices?
  - use https://github.com/nusenu/ansible-relayor to automate it, now with 
prometheus/MetricsPort support :)  -> perfect!

General Q&A, answer any questions relay operators have

Bridges still need to have reachable ORPort, even if it's never used and 
dangerous?
  - Yes, alas.
  - There's a ticket: https://gitlab.torproject.org/tpo/core/tor/-/issues/7349
  - The issue is that bridges do self-reachability tests, and won't publish if 
their ORPort is unreachable. Also, Serge won't give it the Running flag, so 
bridgedb won't give it out. It's all just engineering fixes, and we should do 
them.

Next meetup:
- @ FOSDEM (5 & 6 February '22)
- The exact date and time will be posted @ tor-relay list

- KAX17 and what to about it? - discussed, thanks
- How to support more diversity in the network, maybe add a flag for relays 

Re: [tor-relays] How to reduce tor CPU load on a single bridge?

[Roger Dingledine]

On Mon, Dec 27, 2021 at 12:05:26PM -0700, David Fifield wrote:
> I have the impression that tor cannot use more than one CPU core???is that
> correct? If so, what can be done to permit a bridge to scale beyond
> 1×100% CPU? We can fairly easily scale the Snowflake-specific components
> around the tor process, but ultimately, a tor client process expects to
> connect to a bridge having a certain fingerprint, and that is the part I
> don't know how to easily scale.
> 
> * Surely it's not possible to run multiple instances of tor with the
>   same fingerprint? Or is it? Does the answer change if all instances
>   are on the same IP address? If the OR ports are never used?

Good timing -- Cecylia pointed out the higher load on Flakey a few days
ago, and I've been meaning to post a suggestion somewhere. You actually
*can* run more than one bridge with the same fingerprint. Just set it
up in two places, with the same identity key, and then whichever one the
client connects to, the client will be satisfied that it's reaching the
right bridge.

There are two catches to the idea:

(A) Even though the bridges will have the same identity key, they won't
have the same circuit-level onion key, so it will be smart to "pin"
each client to a single bridge instance -- so when they fetch the bridge
descriptor, which specifies the onion key, they will continue to use
that bridge instance with that onion key. Snowflake in particular might
also want to pin clients to specific bridges because of the KCP state.

(Another option, instead of pinning clients to specific instances,
would be to try to share state among all the bridges on the backend,
e.g. so they use the same onion key, can resume the same KCP sessions,
etc. This option seems hard.)

(B) It's been a long time since anybody tried this, so there might be
surprises. :) But it *should* work, so if there are surprises, we should
try to fix them.

This overall idea is similar to the "router twins" idea from the distant
distant past:
https://lists.torproject.org/pipermail/tor-dev/2002-July/001122.html
https://lists.torproject.org/pipermail/tor-commits/2003-October/024388.html
https://lists.torproject.org/pipermail/tor-dev/2003-August/000236.html

> * Removing the fingerprint from the snowflake Bridge line in Tor Browser
>   would permit the Snowflake proxies to round-robin clients over several
>   bridges, but then the first hop would be unauthenticated (at the Tor
>   layer). It would be nice if it were possible to specify a small set of
>   permitted bridge fingerprints.

This approach would also require clients to pin to a particular bridge,
right? Because of the different state that each bridge will have?

--Roger

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

Re: [tor-relays] Tor not starting but log inconclusive

[Roger Dingledine]

On Tue, Dec 14, 2021 at 09:26:21PM +0100, yl wrote:
> The standard Debian tor@default.service has "After=network.target
> nss-lookup.target" in it, so one would think network should be fully
> functional when the services starts, but it was not in my case.
> At the time when tor started the eno0 did not yet have a IPv6, so it
> complained that it could not bind to some port in the config, because the IP
> supplied with the port was not ready yet.

Great find.

If it's easy for you to do, can you install a Tor 0.4.5 deb and see if it
has the same behavior? If yes, then this is a problem with your particular
situation, or a problem with IPv6 that has been there all along. But if
the 0.4.5 deb works and the 0.4.6 deb doesn't, then it is a regression,
perhaps related to the ipv6 changes we did in 0.4.6, and we should try
to track it down.

Thanks,
--Roger

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

Re: [tor-relays] Introduction from lokodlare

[Roger Dingledine]

On Sun, Dec 12, 2021 at 03:42:12PM +, Gary C. New via tor-relays wrote:
> I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always 
> interested in knowledge sharing related to Tor Loadbalancing.
> What are your thoughts on the Pros & Cons of dedicating resources to a 
> Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor 
> Operator? Perhaps, a Hybrid approach?

Hi Gary,

One of the big downsides to trying to create one "meta" relay out of
many independent relays is that each independent relay will make and
maintain its own TLS connections with other relays.

So while running a fast Tor relay the normal way might end up with
roughly one connection to each other relay in the network (which could
already be many thousands of connections), doing it the way you describe
could result in many times that number of open connections. And even
if your local router and systems can handle that many open connections,
you're increasing the load on every other relay by forcing them to handle
more connections.

There will also be more bandwidth use, since each separate TLS connection
will use its own keepalive packets to try to stay connected in the
face of firewall and NAT timeouts, and also to try to foil rudimentary
netflow-based traffic analysis attacks. And because circuits are spread
out over many TLS connections, they won't get the privacy protections
from being all bundled on a single TLS connection, i.e. a network observer
will have an easier time distinguishing which circuit a given cell is for.

Which relays are you running in this way? How do you aggregate all of
the statistics/etc into a central Tor that publishes a unified relay
descriptor? I would expect your meta-relay to have some kind of bizarre
breakage, so we should check it out and see if that's true in practice.

Thanks,
--Roger

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

Re: [tor-relays] bridge distribution mechanism

[Roger Dingledine]

On Sun, Dec 12, 2021 at 10:52:42AM +0100, trinity pointard wrote:
> There are multiple bridges distributions mechanism. One is chosen at random
> when your bridge first come to life, each being perfectly fine :
> - moat: distributed automatically to Tor Browser users
> - https: distributed on bridge-db website after solving a captcha
> https://bridges.torproject.org/
> - email: distributed when sending an email to brid...@torproject.org)
> - reserved: distributed manually, mostly in-person I imagine
> 
> The only distribution mechanism you might want to worry about is "none", it
> either mean your bridge is really young and bridge-db is not distributing
> it yet (it should only be in that state for about a few hours), or you
> decided to distribute this bridge yourself (no bridge-db involved, by
> setting  `BridgeDistribution none` in your torrc), or your bridge is down.

Right, exactly.

Two more documentation resources that could be helpful:

* The relay-search page makes each "Bridge distribution mechanism"
into a link to its entry on
https://bridges.torproject.org/info

* You can read about the original design idea here:
https://svn-archive.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4

And for those who enjoy reading even more, check out these blog posts
which detail the open research areas:
* https://blog.torproject.org/strategies-getting-more-bridge-addresses
* https://blog.torproject.org/research-problems-ten-ways-discover-tor-bridges
* 
https://blog.torproject.org/research-problem-five-ways-test-bridge-reachability

--Roger

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

Re: [tor-relays] Tor not starting but log inconclusive

[Roger Dingledine]

On Tue, Dec 14, 2021 at 11:39:50AM +0100, yl wrote:
> Hello all,
> I have a problem with a Tor Exit.
> 
> Tor will not start correctly, but there is nothing in the logs. Here is the
> info I got.

Is this the debian package? What OS?

> You can see the start was at 04:28:59 but it only started when I did
> "systemctl restart tor" at 10:12:01.103.

My first thought is that somehow during boot Tor fails to start. For
example, if at that point in the boot process there is no network,
maybe Tor aborts even before it gets to the point of writing anything
in its logs. We've definitely had bugs like that over the years.

> Any idea how to troubleshoot this and what to look for?

Tor will write to stdout before it switches over to writing to the
logs. So whatever init process is starting Tor can see that output. How
exactly to get at it... sounds like an adventure diving into how systemd
works. :)

--Roger

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

Re: [tor-relays] Mystery with Exitnode 4273E6D162ED2717A1CF4207A254004CD3F5307B (176.10.99.200)

[Roger Dingledine]

On Tue, Nov 23, 2021 at 03:37:24PM +, Tschador wrote:
> in the last few days I noticed a curiosity with the Exitnode
> 4273E6D162ED2717A1CF4207A254004CD3F5307B:
> 
> Every time I call 'https://www.startpage.com', the URL in the Browser
> changes to 'http://localhost/'.
> 
> Other browser: same effect.
> Other sites - no problem.
> Other Exitnodes - no problem with 'https://www.startpage.com' and other
> sites.

It happens to me too, from that exit relay:

"""
$ torify curl -i https://www.startpage.com/
HTTP/1.1 307 Temporary Redirect
Server: nginx
Date: Tue, 23 Nov 2021 15:58:56 GMT
Content-Type: text/html
Content-Length: 180
Connection: keep-alive
Location: http://localhost/
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload


307 Temporary Redirect

307 Temporary Redirect
nginx


"""

I believe we are making a successful request to
https://www.startpage.com/, and that is the reply that the webserver is
sending us.

That is, everything in the Tor side is working as expected, and startpage
is sending a response that isn't what we wanted. Maybe it is a bug
on their side, or maybe it is some sort of anti-abuse mechanism on
their side.

--Roger

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

Re: [tor-relays] Move or Recreate

[Roger Dingledine]

On Sat, Aug 14, 2021 at 09:04:31PM -0700, Eddie wrote:
> I'm thinking of switching a couple of the VPS servers I have, where I'm
> running both relays and bridges.  (On separate VPSs, obviously).
> 
> I know how to maintain the keys for both relays and bridges for the
> replacements, but was wondering exactly what does that buy me, as both will
> now be running at different IPv4/6 addresses.
> 
> As opposed to just blowing away the current ones and starting fresh copies.

One of the advantages to blowing away the current keys and starting
fresh is that you reduce the surface area of who might have seen the
original keys over time. That is, if you keep copying your keys around
and moving, then each time you move you grow the set of people who might
somehow have gotten a view of the longterm identity keys.

One of the advantages of keeping the same keys is that you maintain
the same state for that key at the directory authorities -- i.e. you
maintain progress toward the Guard flag, you maintain your "time known"
progress, etc.

So I would say that there is no real harm in starting fresh, and if
that's your inclination, go for it.

For bridges in particular, starting fresh makes a lot of sense since
little of the "state" at the bridge authority really matters. (In the
original bridge design, there was an idea that if you have n bridges
configured and 1 of them is still reachable but n-1 of them moved to
a new IP address, you could use that remaining 1 to look up the new
locations of the others, and in that original design, keeping the same
key would definitely help -- but we never finished building that design,
and with newer approaches like Snowflake, we might never do so.)

If you're moving a relay from one location to another location that
you know is similar in terms of bandwidth and connectivity, that's the
situation where migrating the key makes the most sense: it will save
your relay some of the time before it sees traffic again.

Hope this helps!
--Roger

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

Re: [tor-relays] My Family

[Roger Dingledine]

On Tue, Jul 27, 2021 at 01:56:09PM +, torix wrote:
> Okay, then I have another question about MyFamily.  Is the only correct format
> MyFamily fingerprint1,fingerprint2,fingerprint3
> or can I put in:
> MyFamily
> #relay 1
> fingerprint1
> #relay 2
> fingerprint2
> #relay 3
> fingerprint3
> 
> I end up with a file in the second format so I know which fingerprint is 
> which, but then creating the comma separated one line format to put in the 
> relays.

According to the MyFamily entry in 'man torrc', you can do it either all
on one line, or each on its own line. But in the 'each on its own line'
case you still need to set MyFamily at the beginning of each line.

   MyFamily fingerprint,fingerprint,...
   Declare that this Tor relay is controlled or administered by a
   group or organization identical or similar to that of the other
   relays, defined by their (possibly $-prefixed) identity
   fingerprints. This option can be repeated many times, for
   convenience in defining large families: all fingerprints in all
   MyFamily lines are merged into one list. When two relays both
   declare that they are in the same 'family', Tor clients will not
   use them in the same circuit. (Each relay only needs to list the
   other servers in its family; it doesn't need to list itself, but it
   won't hurt if it does.) Do not list any bridge relay as it would
   compromise its concealment.

   If you run more than one relay, the MyFamily option on each relay
   must list all other relays, as described above.

   Note: do not use MyFamily when configuring your Tor instance as a
   bridge.

There is even a third option, where you end each line with a backslash,
which tells Tor that these multiple lines are actually just one long line:

   To split one configuration entry into multiple lines, use a
   single backslash character (\) before the end of the line. Comments can
   be used in such multiline entries, but they must start at the beginning
   of a line.

I.e. you could use your above approach with one fingerprint per line,
without saying MyFamily on each one of them, if you added a backslash
at the end of each fingerprint.

--Roger

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

Re: [tor-relays] Relay Bandwidth/Burst Change

[Roger Dingledine]

On Tue, Jul 27, 2021 at 09:41:30PM -0500, Kathi wrote:
> I set torrc bandwidth/Burst to 5 MBs/6MBs respectively

How do you set them? By changing your /etc/tor/torrc file? Or some other
way like using nyx?

> Then I get @7pm Local:
> 
>  Received reload signal (hup). Reloading config and resetting internal
> state.
>  Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
>  Read configuration file "/etc/tor/torrc".

Sounds like you are using the tor deb, or some other package which does
logrotation and thus automatically hups your Tor each day.

>  After the above happens I'm back to Kb second.
> 
>  If I understand correctly, torrc is the 'go to' default and
>  those settings [*should be*] used.

Yes.

>  So why is the bandwidth/Burst being changed? Which
>  is REALLY annoying. There must be another setting
>  somewhere in Tor that I am missing?

It really comes down to how you are doing the config changes. Some
approaches, like doing changes via "setconf" on the control port, are
transient and are replaced by what's in the torrc files after a hup.

--Roger

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

Re: [tor-relays] My Family

[Roger Dingledine]

On Sun, Jul 25, 2021 at 08:36:20AM -0500, Kathi wrote:
>   I'm running three relays. Is it necessary to list all three relays in
>   my family on each relay?

Yes, please do list them all.

The first reason is that it helps clients make safe routing decisions:
by signaling to the clients that these relays are all controlled by you,
Tor clients can make sure not to use more than one of your relays in any
of the paths they build.

The second reason is actually for *your* safety: if you are signaling to
clients to avoid using more than one of your relays in their paths, then
the temptation is lower for somebody to come hassle you into revealing
data and/or watch your network connection.

And the third reason is to help everybody know which relays are really
yours. We've had some problems over the past year with jerks trying to
run harmful relays, and one of their tricks to stay hard to notice has
been to find groups of relays that look like a family but that haven't
set up their MyFamily lines properly, and try to blend in with those. So
if you run three relays but don't set your MyFamily properly, we can't
tell the difference between that and "you run two relays and some jerk
is trying to blend their relay into your two".

Thanks for running relays!

(Oh. As Roman says in the other reply, technically there's no need to
list yourself in your MyFamily line. That is, every relay is implicitly
already in its own family. But for logistical reasons, it's probably
easier to just use the same MyFamily line for all three relays.)

--Roger

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

Re: [tor-relays] G-Core Labs and their humanoid robots

[Roger Dingledine]

On Tue, Jun 08, 2021 at 01:56:33PM +0200, Tor Relays wrote:
> Support agent 1:
> It was blocked because automatic monitoring system find your activity
> suspicious.
> Now, trust level of your traffic for IP has been increased however the
> traffic is still automatically monitored. If the system of automatization
> identifies your traffic as illegitimate or if we receive an infringement
> report, we'll have to disable ports once again.

Right, this is the key part of the explanation.

Typically the way these blocklists work is that they run "honey services"
somewhere secret on the internet, often on ports like 80 that are
different from the ones they will apply the blocklist to. And if anybody
connects to their secret honey IP address on port 80, they call them a
likely spammer and refuse to allow emails/etc to their other services
from that address.

And Tor exits are particularly susceptible to getting put on these kind
of blocklists, because all it takes is one person trying to connect to the
honey address, and bam the exit relay's IP address gets on the blocklist.

And the "cross-protocol" nature of the blocking, where they see you do
one protocol and then block you from doing a different protocol, also
does not match well with Tor's notion of exit policies.

I guess that the scale of jerks on the internet is huge compared to what
they imagine is the scale of non-jerks on Tor, and so they have little
incentive to change the design of their honeypot systems. :(

--Roger

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

Re: [tor-relays] ECONNREFUSED

[Roger Dingledine]

On Tue, Mar 16, 2021 at 09:35:45PM +0100, Toralf Förster wrote:
> > However, the status page keeps saying I'm dysfunctional with a ECONNREFUSED:
> > https://bridges.torproject.org/status?id=E120A0492F789F5367EAD84C64F92EE279018F98
> > 
> > 
> 
> Wasn't aware of that status page - my bridge is listed as
>   * obfs4: dysfunctional
> 
> OTOH I can connect to it with obfs4 fine from my desktop and verified
> that obfs4 is working - so maybe the bridge check is wrong ?

Yes, it looks like something has gone wrong with the bridgestrap
service. Thanks for pointing it out, both of you!

I've opened
https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/16
so hopefully somebody will be able to look into it.

--Roger

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

Re: [tor-relays] Question

[Roger Dingledine]

On Sun, Mar 21, 2021 at 03:10:41PM +,  ?? wrote:
> What does it mean "Tor's file descriptor usage is at 90%. If you run
> out Tor will be unable to continue functioning."?

That sounds like a message from nyx:
https://nyx.torproject.org/

It means that your "ulimit -n" is too low.

Typically the Tor package includes an init script that raises
ulimit -n for you. For example:
https://gitweb.torproject.org/debian/tor.git/tree/debian/tor.init#n40

So if you are not using a Tor package like the deb, now is the time
to start.

--Roger

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

Re: [tor-relays] Circuit Creation Madness: Anyone else still experiencing (extremely) excessive clients / (possibly) modified relays creating millions upon millions of circuits?

[Roger Dingledine]

On Mon, Mar 22, 2021 at 07:54:43PM +, William Kane wrote:
> Sorry for being quite noisy recently but I really need to know how
> many people are suffering from the same madness I am encountering
> right now.
> 
> Quick excerpt from the log:
> 
> Mar 22 09:48:10  tor[pid_redacted]: Mar 22
> 09:48:10.000 [warn] Your computer is too slow to handle this many
> circuit creation requests! Please consider using the
> MaxAdvertisedBandwidth config option or choosing a more restricted
> exit policy. [12420 similar message(s) suppressed in last 120 seconds]

Yes, it could help to hear if many people are experiencing these log
messages or just a few.

There are several known situations where the log messages could happen to
a small subset of the relays at any given time. For example, if somebody
is trying to flood a particular onion service, then the six or eight
HSDirs for that onion address for that day could see a lot of overload
(which would last for as much as that day), and also the introduction
points listed in the descriptors could see a lot of overload (which
would last a lot less than a day probably).

> Might be smart to add some code which, if this scenario is triggered,
> lists offenders by hashes of their signing keys (if relay), or IP
> addresses (if client).

For the variants of the overloads that we've seen so far, they are
done via Tor, i.e. your relay doesn't actually know who is starting
the circuits, so those logs would be at best useless. (We built an
anonymity system, and now it keeps people anonymous. We can't be *too*
unhappy here. :)

I think the long term answer for these attacks are the options outlined
by George in this blog post:
https://blog.torproject.org/stop-the-onion-denial

I'm especially interested in the proof-of-work variant, which doesn't
need an interface where the human does stuff, doesn't need to be hooked
together with a global ecash system that everybody wants a piece of, etc:
https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro.txt

But as they say, more work remains.

--Roger

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

Re: [tor-relays] Questing regarding Team Cymru Tor Relays and Bridges

[Roger Dingledine]

On Mon, Mar 22, 2021 at 09:21:24PM +, Lisa Winter wrote:
> I decided to do some own research, and it seems like the Tor Project
> has a long-standing relationship with Team Cymru (at least since 2012,
> and maybe even earlier):
> 
> https://blog.torproject.org/knock-knock-knockin-bridges-doors
> 
> Still, I'm slightly paranoid when organizations like these start
> spinning up many different relays, effectively getting to see a
> substantial portion of the network's traffic.

Yes, we've been interacting with Team Cymru folks for more than a
decade now.

I even went to one of the conferences they organized a few years ago
hosted by the Council of Europe, where they had an audience full of
government and law enforcement people that I could teach about "what Tor
actually is" and "how the internet actually works" from my perspective,
because otherwise they'd just hear the "Tor is bad and the internet is
full of bad people" myths and FUD from their colleagues. You can read
more about that kind of outreach here:
https://blog.torproject.org/trip-report-october-fbi-conference
(different conference but same idea)

Also, their CEO is on Tor Project Inc's board currently, and I regard
that as a great step because he can help with (among other things)
oversight that we're running the business side of Tor properly:
https://www.torproject.org/about/reports/

I think most of the infrastructure that Team Cymru has set up for Tor,
we've asked them to do it. So that right there should help you look at
it differently.

Another answer might be that I'm a lot more worried about the groups
that *haven't* come forward to identify themselves, yet are trying to
watch the internet or build datasets about internet users etc.

And a third answer could be that the goal of the Tor design is to
distribute trust over multiple relays in your path, so the risk of any
one of those relays trying to attack you isn't so bad. (This angle is
a bit tricky of course, because even though that's true, having a lower
probability of being attacked is still better.)

In summary, yes it makes sense to wonder about the various organizations
that want to get involved in Tor, and understand their motives. But we
need to design our systems so that they don't fall apart if a small piece
of the network is trying to attack it. And at the same time we need to
strengthen our *communities* so that they are robust and represent many
different skills and interests and perspectives, because that's how you
grow mainstream acceptance. So, it is a balance, and there are many ways
in which we need to be doing that balance better, and I'd put this one
pretty far down the list.

Hope that helps!
--Roger

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

Re: [tor-relays] Is my relay broken? No stable, hsdir or guard flags

[Roger Dingledine]

On Sat, Feb 13, 2021 at 08:51:06AM -0600, Scott Bennett wrote:
>  The following popped up almost an hour and a half ago in my relay's
> log file.
> 
> Feb 13 07:27:54.947 [notice] The current consensus has no exit nodes. Tor can 
> only build internal paths, such as paths to onion services.
> 
> Is it telling the truth?  Was there really an hour when the consensus
> contained no Exit flags in the entire file?

I spent a while hunting and I think no, there was no hour when the
consensus contained no Exit flags. But some parts of the mystery
still remain:

https://gitlab.torproject.org/tpo/core/tor/-/issues/40292

--Roger

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

Re: [tor-relays] key server error

[Roger Dingledine]

On Sun, Feb 07, 2021 at 10:44:53AM -0500, tor wrote:
> When I do the following command:
> 
> :~ $ sudo  gpg --keyserver keys.gnupg.net --recv
> A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
> 
> I get:
> 
> gpg: packet(13) too large
> gpg: read_block: read error: Invalid packet
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
> 
> thoughts?

You are experiencing the disaster that is the public keyservers in the
past few years. Jerks add garbage to keys until the keys are too big to
download or use. The era where keyservers worked reliably is over.

If you want that key now, your best bet is to fetch it from some source
that will you give you a clean version of the key. For example, the url
referenced in
https://support.torproject.org/apt/tor-deb-repo/

Similarly, to get the Tor Browser signing key, you'll want to use the
modern wkd feature of gpg:
https://support.torproject.org/tbb/how-to-verify-signature/
or if your gpg isn't new enough to have wkd, there's a direct download
link at the very bottom of that page.

--Roger

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

Re: [tor-relays] Tor on Rpi

[Roger Dingledine]

On Sat, Feb 06, 2021 at 12:31:29PM -, relay.jack...@simplelogin.fr wrote:
> im running a tor relay on rpi 2 with version 0.4.2.7., on the  Tor relay 
> search i see my relay is outdated and flaged as not recomended, however on 
> rpi i have tried update and upgrade many times and always get notification 
> from apt that tor i already de newest version, also tried apt dist-upgrade 
> but no luck.
> 
> Any way to get the last version and get ride of not recomended flag from my 
> relay?

I would suggest adding buster-backports to your sources list, and then
you'll be using a more recent Tor. See this earlier post for hints:
https://archives.seul.org/tor/relays/Feb-2021/msg3.html

(You might notice that somehow that post did not make it to the official
tor-relays archives. I blame some bug in mailman, but also I will leave
that bug alone and try to move on with my life. :)

If you had said something other than rpi, I would have pointed you to
https://support.torproject.org/apt/tor-deb-repo/
but we stopped providing 32-bit arm packages on deb.torproject.org:
https://lists.torproject.org/pipermail/tor-talk/2020-May/045582.html
since we don't have any builders for them.

Hope that helps!
--Roger

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

Re: [tor-relays] Can't connect to bridge after rebuilding server

[Roger Dingledine]

On Mon, Feb 08, 2021 at 06:58:55PM -0800, Eddie wrote:
> Following the rebuild, the bridges
> appear to start correctly, according to both the logs and
> https://metrics.torproject.org/rs.html#search/OhNoAnotherBridge. However
> attempting to connect via the tor browser from my home system just hangs.
> 
> The ports on the VPS are open.  I can see an ESTABLISHED connection from
> home, but the browser just hangs throwing out this:  [WARN] Proxy Client:
> unable to connect to aaa.bbb.ccc.ddd:443 ("general SOCKS server failure")
> 
> Not sure what to check next.

It looks like the "vanilla ORPort" part of your bridge works (I just
bootstrapped my Tor through it to confirm), but your obfs4 port is
busted somehow:
https://bridges.torproject.org/status?id=8BBAB62EA65E47CDF204E3D795DAD12E5046EB72
https://lists.torproject.org/pipermail/tor-relays/2021-January/019221.html

I wonder if, when you restored things, you also restored the obfs4
keys?

It looks like OhNoAnotherBridge80 is doing better?
https://bridges.torproject.org/status?id=B080140DC1BAB5B86D1CE5A4CA2EF64F20282440

--Roger

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

Re: [tor-relays] Exit relay operators please help test #2667 branch

[Roger Dingledine]

On Thu, Feb 04, 2021 at 01:20:58AM +0200, s7r wrote:
> Indeed the defense is triggered more often than I expected. Very nice.

Btw, a better version of the #2667 patch is now included in all of the
current Tor releases: 0.3.5.13, 0.4.3.8, 0.4.4.7, 0.4.5.5-rc.

So if you are still trying out my experiment patch, thank you, but now
please stop doing that and move to one of the actual releases. :)

> This defense is only implemented at the Exit relay, and it blocks all the
> relay:ORPort / DirPort combinations that exit knows about according to its
> version of the consensus?

The design that we decided on was "block relay:ORPort, dirauth:ORPort,
and dirauth:DirPort". That is, it doesn't try to block relay:DirPort
connections.

We chose that balance because if we'd blocked all relay dirports too,
we would have broken relay dirport reachability tests, because the
way those tests work is by building an exit circuit and then "exiting"
back to the relay's dirport to see if it works.

Ultimately I expect we're going to phase out the concept of a dirport
on non-dir-auth relays, since they mostly go unused so it's just yet
another thing to maintain that isn't worth it. But now we can do that
phase-out completely separate from this topic.

> What happens if the abuser has a different valid consensus (newer/older)
> that has some relays which are not known by the Exit?

If there are edge cases where different sides have different knowledge,
then those edge cases will 'get through'. But hopefully they'll be rare,
or even if they're not rare, hopefully they will be low-impact.

> Or if the abuser uses
> for re-entry a relay configured with `PublishServerDescriptor 0`? How does
> it treat bridges?

They are all allowed.

In fact, one of the Tor use cases we're going to break here is people
who torify all their traffic (at the network or host level) and then
run Tor Browser also. The suggested workaround for them is that if they
really need to do this, they should configure their Tor Browser to use
a bridge. There will be a bunch of confused users who don't know they're
doing this, and don't know why it broke, though.

I've been working on
https://gitlab.torproject.org/tpo/core/tor/-/issues/40271
to do a little bit toward that explanation side.

> And most important, does this means that an Exit will no longer try to
> connect to other middle relay? At this moment can't an exit relay (of course
> with a small probability) be used as a middle or entry? Won't this become a
> mess if we have 80% of relays Exits and thus used more as 1st or 2nd hops,
> or in a perfect future where 100% or relays are all exits?

No, exiting is different from extending. Exit relays can still extend
to other relays -- this is a part of the Tor protocol that lets a relay
make a TLS connection with another relay. The difference is in who the
"ends" of that TLS connection are: in the extend case, the ends are the
two relays. In the 'exit and reenter' case, one end is the client and
the other is the destination relay.

--Roger

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

Re: [tor-relays] Sig ver error

[Roger Dingledine]

On Wed, Feb 03, 2021 at 12:17:11PM -0500, tor wrote:
> I'm getting a signature verification error:
> 
> $ sudo apt-get update
> 
> Hit:1 http://mirrordirector.raspbian.org/raspbian stretch InRelease
> 
> Hit:2 http://archive.raspberrypi.org/debian jessie InRelease
> 
> Get:3 https://deb.torproject.org/torproject.org stretch InRelease [3528 B]
> 
> Err:3 https://deb.torproject.org/torproject.org stretch InRelease
> 
>   The following signatures were invalid: EXPKEYSIG 74A941BA219EC810
> deb.torproject.org archive signing key

Hi Matt,

There are two problems here:

First is that you need to re-import the deb.torproject.org signing key,
because you have an old version of the key which has an expiry date in
the past. You can do that by following the instructions on
https://support.torproject.org/apt/tor-deb-repo/

But second is that you have distro names like jessie and stretch in
your apt sources lines. Those distros are super super old:
https://www.debian.org/releases/jessie/
https://www.debian.org/releases/stretch/
So you should make some plans to move to a newer distro like buster.

Hope this helps,
--Roger

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

Re: [tor-relays] Is my relay broken? No stable, hsdir or guard flags

[Roger Dingledine]

On Fri, Jan 29, 2021 at 11:32:44AM +0100, raltul...@posteo.org wrote:
> - At the beginning of January the relay seems to have lost the guard flag
> - A week ago I checked and noticed that the relay had also lost the stable
> flag despite having an uptime of >2 months at that point
> - A week ago I rebooted the server but the situations hasn't changed - flags
> are still gone

Some of the directory authorities have restarted many times in the past
week, and each restart impacts their view of whether other relays are
stable. In theory it should impact all the views equally (it's like
there was a blip in the matrix but it was an equal blip for everybody),
but in practice, maybe the math doesn't make it actually equal.

> - metrics.torproject graphs show that the server has been transmitting data
> the entire time - so it doesn't seem like I missed some downtime

The graphs on relay-search are visualizing data that is self-reported by
the relay. So from the relay's perspective there was no downtime, but
that doesn't give us much hint about whether the directory authorities
found the relay consistently reachable.

Another hint I find useful is to look at the individual votes from
the directory authorities. One way to do that is to go to the bottom of
https://consensus-health.torproject.org/#relayinfo and put in your
nickname.

> - Serverlogs show no problems
> - Relay has been running continuously for almost 4 years and only gets
> rebooted for kernel/tor upgrades -> so uptime and MTBF should not be a
> problem
> 
> Is there a problem on my side?
> Is there anything I can do or check?

One part that I would look into more is the IPv6 connectivity. Maybe
that address is intermittent? If it is, then the relay would mostly
continue to work as normal (because clients mostly use IPv4), but the
subset of the dir auths that checks IPv6 reachability would consider
that instability to be a short downtime.

> It is a fallback relay - is it still useful as such?

It is still useful yes.

Thanks,
--Roger

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

Re: [tor-relays] Exit relay operators please help test #2667 branch

[Roger Dingledine]

On Fri, Jan 29, 2021 at 12:34:28AM +0100, nusenu wrote:
> If dir auths (some or all) are willing to share (privately or publicly) the 
> distribution of
> attack load (frequency, bandwidth, ...) by exit source IP in total or 
> relative values
> I can correlate this data to strengthen a hypothesis that malicious/suspicious
> exits are involved to a greater extend than well-known long term exits.

I'll send you out-of-band a little snapshot of requests from relay
IP addresses -- 160k requests over a 24 minute period from yesterday
early evening.

At one point later in the evening I was getting several tens of millions
of requests per hour. That's when I started to realize that exit relay
operators were probably seeing this increased load too.

> That could mean that they are not (exclusively) attacking via but _from_ 
> servers that also happen to
> run tor exits. 

Well, there are definitely other addresses -- the overload from last
week was non-relay addresses, and that's still going.

It's possible that there are exits that are generating more than their
"fair" share of requests. I didn't see that pattern obviously happening,
and confirming it would be complicated by the fact that some relays
probably have less or more congestion, which would cause the attacks to
be more efficient or less efficient through them.

We had a long debugging session in #tor-dev on irc last night, and there
will be more of those as we proceed. We've found a bunch of short-term
fragile distinguishers, which we could use to block the "bad" traffic
right now, but which wouldn't hold up if the bad traffic adapts a bit.

More broadly, we're trying to walk the fine line between doing our
analysis and patches in public (yay transparency), vs being aware
that whoever is doing this is probably reading these threads too. The
destination we want is that we have defenses that are robust to the
attacker knowing about them, but things will be a bit bumpy as we get
to that destination.

I'm also trying to make sure everybody continues to think about the
privacy side -- the directory authorities or fallbackdirs don't know
what paths clients build, or what destinations they reach with them,
but they can know at what timestamps some IP addresses seemed to be using
Tor. And like most things, that information is better private by default.

> From another angle this is an interesting precedence
> because the tor project uses it's access to protect dir auths
> from exit relays. Why is that interesting? Because no one else
> that gets attacked via exit relays has that "luxury" to "filter"
> it at the "source" (exits).

Actually, the #2667 patch protects all relays from exit relays. That is,
exit relays will decline to exit to known ORPorts or DirPorts of any
relay. There are two benefits here: (a) people can't do circuit-level
amplification attacks (happy to elaborate on these once the defense is
more in place), and (b) people can't create directory requests which
blend with the directory requests that the relay itself does.

These two issues are Tor-specific, and the second one is an especially
good argument I think, because the relay is reserving for itself the
ability to make its dir connections in a way that the destination can
know that the relay is the one making the connection. (Another option
would be to add more authentication to the connection, but most ways of
doing that are heavier-weight, not lighter-weight.)

--Roger

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

Re: [tor-relays] Metrics Error: staledesc

[Roger Dingledine]

On Thu, Jan 28, 2021 at 07:00:45PM +0100, li...@for-privacy.net wrote:
> Metrics showed my relay offline. But my Tor daemon is running normally.
> Then I saw _many_ relays suddenly have flag: staledesc
> ?
> 
> https://metrics.torproject.org/rs.html#search/flag:staledesc

Yep. The reason that happens is that the directory authorities are
receiving too many dirport connections from exit relays, but the exit
relays use a dirport connection to post their own descriptor.

So if we don't handle all of the dirport attempts, then we end up not
receiving some of the descriptor publish attempts.

I'm thinking that this part will still work out though, for two reasons.

One is that if *any* of the dir auths receive the descriptor, then they
will mention it in their next vote, and the other dir auths will learn
about it from that vote and ask for a copy.

And two is that relays watch to see if they are still listed in the
consensus, and if they're not then they try more often to upload a
new descriptor.

So yes, we are making an effort to make sure there is at least one dir
auth that will be good at receiving descriptor publishes.

Some small fraction of relays are expected to get the StaleDesc flag in
normal network operation, because there is an unfortunate interaction
between how relays publish a new descriptor "every 18 hours or when
something important changes", but dir auths ignore new descriptors if
they are too close in time or other characteristics to one that they
already have. So for example there is a known bad interaction where you
restart your relay, and the relay publishes a new descriptor because
it doesn't know that it just published one earlier, but then the dir
auths discard that new descriptor because they already have the old one,
and then your relay waits 18 hours to create a new one.

For much more backstory, see
https://gitlab.torproject.org/tpo/core/tor/-/issues/1810
https://gitlab.torproject.org/tpo/core/tor/-/issues/2479
https://gitlab.torproject.org/tpo/core/tor/-/issues/3327
https://gitweb.torproject.org/torspec.git/tree/proposals/293-know-when-to-publish.txt

But I guess the other way to look at it is: the StaleDesc flag is a
*feature*, to let your relay know that it has fallen into this edge case
so it can take steps to recover.

> https://metrics.torproject.org/rs.html#details/5D84900DBE6D6365684A9675B81A68ACE9577A68

This relay looks genuinely down.

--Roger

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

[tor-relays] Exit relay operators please help test #2667 branch

[Roger Dingledine]

Hello friendly relay operators,

Another day, another weird thing with the Tor network. This time we
have some jerk bombing the directory authorities with directory fetches,
and doing it via exits:
https://lists.torproject.org/pipermail/network-health/2021-January/000661.html

The network is mostly holding together, but I wouldn't say it is pretty.

One of the long-term fixes will be ticket #2667:
https://gitlab.torproject.org/tpo/core/tor/-/issues/2667
where exit relays refuse to let users connect back into the Tor network.

David and I made a branch this evening that implements #2667, and it
could use some testing. If you're comfortable building your exit relay
from a git branch, please do, and let us know how it goes. It is the
"ticket2667" branch on either
https://git.torproject.org/user/arma/tor
or
https://gitlab.torproject.org/arma/tor/

And if your relay is currently using 100% cpu and/or way more bandwidth
than usual, you might be especially excited to try out this patch. :)

When the defense triggers, you will see an info-level log line like
"%s tried to connect back to a known relay address. Closing."
(where %s is the destination, so don't get upset at them. :)

You can let us know how it's going either by mail just to me, or by a
reply on the list, whichever you prefer. Once we know that you're running
the branch, we can also probe your relay remotely to verify that it is
correctly refusing those connections.

Thanks!
--Roger

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

Re: [tor-relays] consensus

[Roger Dingledine]

On Wed, Jan 06, 2021 at 09:29:32AM +0100, Felix wrote:
> When I try
>   http://authorityip:dirport/tor/status-vote/current/consensus.z
> it's
>  'failed: Operation timed out'
> What works is:
>   http://relayip:dirport/tor/status-vote/current/consensus.z
> 
> Am I missing something and is everything good? A glitch?

You can follow the chaos in more detail at
https://lists.torproject.org/pipermail/tor-consensus-health/

But the very short answer is that it appears the overload from
https://gitlab.torproject.org/tpo/core/tor/-/issues/33018
is back.

It appears that somebody has made their own Tor client implementation
and it fetches its dir info in a very rude way. If anybody knows details
of it, please do let us know.

moria1 is running the what-I-think-is-smarter behavior described in
https://gitlab.torproject.org/tpo/core/tor/-/issues/33072#note_2709867
but in terms of getting that patch merged, I think we're in a "somebody
should" situation.

tl;dr "the network is still working but things could be better"

--Roger

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

Re: [tor-relays] Info from my ISP about investigation of tor exits - Update

[Roger Dingledine]

On Sat, Jan 02, 2021 at 01:31:12PM +0100, Olaf Grimm wrote:
> Exit-IPs:   Please block these Exits /Relays
> 
> 89.34.27.149, active
> 89.34.27.43 , "supended" in panel, but active.   Warning!
> 89.34.27.48, active
> 89.34.27.49, active
> (89.34.27.59 since some days terminated)
> (89.34.27.37 since some week terminated)

Thanks. (Olaf mailed this info to bad-relays@ too, and we've started
the process of making sure the relays won't be able to come back into
the network, just in case.)

--Roger

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

Re: [tor-relays] Tor Traffic De-prioritization Script

[Roger Dingledine]

On Wed, Dec 23, 2020 at 05:47:11AM -0800, tontu wrote:
> I recently acquired a server with "unlimited" (not unmetered) bandwidth
> on a non-Hetzner/OVH/Scaleway network, but the pipe is just 100mbit (and
> will be saturated at some points by personal traffic bursts). That being
> said, I expect the 100mbit pipe to be idle 90% of the time, so it
> doesn't seem ideal to just set a low BandwidthRate.
> 
> The documentation [1] for relay bandwidth shaping options points to a
> script to de-prioritize Tor traffic to ensure that personal traffic
> takes precedence.
> 
> However, the script no longer exists within Tor source code. [2] Is this
> script now deprecated? If not, where can I find it? If so, what
> alternative methods might exist to de-prioritize Tor traffic during
> bursts from personal traffic pipes on Linux or BSD systems?

It looks like yes, we removed it:
https://gitlab.torproject.org/tpo/core/tor/-/issues/29434
https://lists.torproject.org/pipermail/tor-relays/2019-February/016995.html

So it definitely counts as deprecated, in the sense that nobody maintained
it for a long time and then somebody deleted it. :)

But that said, I bet it would still work, or at the very least, it would
be a good set of hints for how to write a new one. If you do write an
updated one, please share it here.

You can find a copy in earlier git branches, e.g.:
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/linux-tor-prio.sh?h=maint-0.3.5

Hope this helps!
--Roger

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

Re: [tor-relays] Relay operators meetup @ rC3

[Roger Dingledine]

On Sun, Dec 27, 2020 at 10:54:44PM +0100, Stefan Leibfarth wrote:
> Hello Tor friends and relay operators,
> 
> I haven't heard of a relay operators meetup at the ongoing rC3.
> Are there any plans?
> If not, who of you is interested?

It looks like there might not be critical mass for such a meetup,
especially trying to create a virtual one with all of the extra complexity
that involves.

That said, qbi points me to a talk this evening (Dec 29 evening) about
running exit relays at universities in Berlin and Hamburg:
https://pretalx.com/rc3/talk/95008/

So for those who speak Deutsch, be sure to check it out!

--Roger

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

Re: [tor-relays] new installation of an established TOR relay

[Roger Dingledine]

On Sun, Dec 27, 2020 at 01:50:03PM +0100, RJ Hofmann wrote:
> caused by a temporary failure of the raspberry I had to completely renew 
> installation of my TOR relay nicknamed mosaik.
> 
> The new installtion is already up and running, but since I had no copies of 
> keys and fingerprints the new relay is completely new in terms of consensus 
> weight etc..
> 
> I wonder if it is helpful in any way to inform you about this change as to 
> accelerate the relay???s ???reputation??? to make it fully functional for the 
> community on the fast track.

No need to inform people -- the process is automated, and your new
relay will go through the process of getting measured, having that
measurement show up in the consensus weights, etc.

Thanks for running a relay!

--Roger

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

Re: [tor-relays] Authorithy clock skew in consensus health page

[Roger Dingledine]

On Tue, Dec 15, 2020 at 04:43:53AM +, torjoy wrote:
> Its just a curiosity question... What is the reference source used in 
> comparsions of authorities clock skew in consensus health?

There are two "consensus health" tools, DepicTor and DocTor:
https://gitweb.torproject.org/depictor.git/tree/
https://gitweb.torproject.org/doctor.git/tree/

And I think if this is the page you're talking about:
https://consensus-health.torproject.org/#authorityclocks
it is generated by DepicTor.

> Are they synced throught NTP daemons (like chrony or opentpd for example)?

The directory authorities each use whatever tools they want to use
for keeping their time accurate. I imagine that yes, many of them use
some sort of ntpd.

> TOR can take advange of very accurate timing in the authorities and relays? I 
> know that just few seconds (or miliseconds?) are fine of clock offset. And if 
> the relay's clock has some fluctuation of hundreds of miliseconds? For 
> example going from -100mS of offset to +300mS offset and them to -200 mS 
> offset...

Correct, clock problems on the order of a second or two are fine.

In fact, I don't think that DepicTor's measurement will be more accurate
than that anyway, because I think the number comes from looking at the
Date stamp in the http header of the response, and comparing it to what
time the local DepicTor script thinks it is. So there will be issues
like network latency that affect it in tiny ways.

> I mean, too much clock noise can be a problem for TOR?

Correct. For directory authorities, they need to synchronize within
a minute or so, because of the timing required for voting about the
consensus documents:
https://spec.torproject.org/dir-spec

Relays can handle some more skew than that, but if they get too skewed
then they will start fetching and serving the wrong directory information.

Hope that helps,
--Roger

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

Re: [tor-relays] Abuse received for middle node (part of the curent problem)

[Roger Dingledine]

On Mon, Nov 02, 2020 at 09:53:09PM +0100, Olaf Grimm wrote:
> I have just received two abuse messages from ISP Scaleway Elements for
> two of my middle nodes. Until now I thought this was not possible.
> 
> No problem for me. Only here for your information.

I get periodic abuse complaints to my directory authority, from people
who think I am attacking them, when really what they are seeing is
connections from *their* users to *my* Tor relay.

Their crappy firewall software interprets the "syn ack" from my server
as being an outgoing connection attempt to them, and so they think they
need to complain to my hoster.

See one example that somebody else experienced here:
https://lists.torproject.org/pipermail/tor-relays/2020-May/018450.html

Keep fighting the good fight,
--Roger

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

Re: [tor-relays] I bumped out some more bad relays

[Roger Dingledine]

On Sat, Oct 31, 2020 at 09:37:38AM +0100, Croax wrote:
> Good. Does this mean it will be check and bumped more regularly? 
> I see that lots of relays are running for more than one month from
> now. 

I hope so. I plan to keep running my new scripts and see where things
go. Part of it depends on the next steps of the jerk who is doing this.

Or said from the other side: if you find a misbehaving relay, or if you
find that a particular url seems like it's being intercepted even if
you can't figure out which relay is doing it, please report it!

The sad version of the story is that there's a "long tail" of possible
sites that they could mess with, and if they only mess with unpopular
or uncommon, it might be a while until anybody notices.

But the happy version of the story is that the more we and others check,
the farther down the long tail we push them, i.e. the lower profile they
need to be to remain unnoticed. And pushing them down the long tail is
also hopefully pushing them towards the point where their operations
are unprofitable.

I am definitely missing the in-person gatherings around the world here.
It used to be that we could say "Oh, you're in country X? Why don't
you meet with so-and-so who is nearby to you" and then build human
trust relationships. This year nobody meets anybody, and it is having
surprising second-order effects like limiting the growth of the global
internet freedom community.

> Yes. From the browser perspective, HTTPS should be enforced whatever
> the context. We may blame final Tor users or website administors for
> not following security guidance (eg. HSTS preload) but in the end it is
> the Tor user privacy that is compromised. This is lasting for months
> and could have been easily prevented. This game of cat and mouse is not
> good for Tor reputation.

I completely agree.

You're seeing the intersection of two core areas of Tor -- "Tor Browser"
and "network health" -- that were both impacted more than average by
our covid budget cuts. We definitely have gotten the attention of the
Tor Browser devs now, and these steps are on their roadmaps, so I'm
optimistic that we'll have some not-just-cat-and-mouse improvements in
the medium term.

--Roger

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

Re: [tor-relays] How to manually change overloaded Guard?

[Roger Dingledine]

On Thu, Oct 29, 2020 at 05:56:59AM +, petra...@protonmail.ch wrote:
> Since tonight I can't get any usable Tor connections anymore; restarting Tor 
> gives the following error message:
> 
> Guard TOR2DFNrelB ($0ED0EA324C931CF41CB5272BFB1D015B3D5772A9) is failing more 
> circuits than usual. Most likely this means the Tor network is overloaded. 
> Success counts are 152/217. Use counts are 45/59. 167 circuits completed, 13 
> were unusable, 2 collapsed, and 51 timed out. For reference, your timeout 
> cutoff is 60 seconds.
> 
> Any idea how to change the Guard - just restarting Tor doesn't help?

It is possible that the overloading happened because of the shift in load
from kicking out the bunch of relays tonight -- and if so, it should sort
itself out over the coming days.

It's also possible that your guard is just encountering other problems
in scaling, like it's hitting cpu limits -- Mike's upcoming "scaling
research" project aims to (among other things) get better at detecting
relays that can't handle their current load, and send less user traffic
toward them so they reach equilibrium. But if that's the underlying
reason for your issue, there isn't really a good short-term fix.

You can change (reset) your current guard by going to your state file
(in Tor's DataDirectory) and removing the "Guard" lines. Or heck, it might
just be easier to delete the state file rather than trying to edit it.

In an ideal world messing with your state file would be a thing that
people do rarely if at all, since it can do complex things to your
anonymity. So, do this step with care. :)

--Roger

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

Re: [tor-relays] I bumped out some more bad relays

[Roger Dingledine]

On Sat, Oct 31, 2020 at 09:46:38AM +0100, Toralf Förster wrote:
> On 10/31/20 4:05 AM, Roger Dingledine wrote:
> > I spent some time this week refining a new exit scanner, and today we
> > pushed some new reject rules to kick out some relays that we confirmed
> > were running mitmproxy to do more sslstrips.

> So these got the flag "Unmeasured" but not "BadExit", right ?

We "rejected" their fingerprints, rather than badexiting the
fingerprints. So nobody will be using them for anything -- not exiting,
not anything else.

The "Unmeasured" flag that you're seeing on relay-search means that for
that vote, that relay didn't have the required threshold of three votes
from directory authorities that run bandwidth authorities. "Unmeasured"
here isn't a flag that we explicitly changed, so much as a byproduct of
doing the blocking: as directory authorities added their "reject" rules
over the course of some hours, the ones that did the reject first happened
to be ones that ran bandwidth authorities, so there was a period of a few
hours where the relays had enough votes to still get listed as Running,
but not enough of the votes came with opinions about bandwidth weights.

And because relay-search shows you the last known thing about the relay
(i.e. from when it was last listed in a consensus), their relay-search
status is frozen in time at that moment before they disappeared entirely.

Hope that explains the weird behavior. :)

--Roger

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

[tor-relays] I bumped out some more bad relays

[Roger Dingledine]

Hi folks,

I spent some time this week refining a new exit scanner, and today we
pushed some new reject rules to kick out some relays that we confirmed
were running mitmproxy to do more sslstrips.

For past context, see these urls:
https://blog.torproject.org/bad-exit-relays-may-june-2020
https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html

Expect some upcoming next steps that aim to change the fundamental arms
race, including experiments to use https by default in Tor Browser, either
via HTTPS Everywhere's "Encrypt All Sites Eligible" option (you can turn
that on right now) or via Firefox's upcoming built-in version of the idea:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850

For completeness, I'm including below the set of fingerprints that we
bumped out. Note that we didn't confirm misbehavior from all of them --
some of them we're bumping out because they seemed sufficiently similar
to the confirmed ones. If any of these are your relays, please speak up!

Thanks,
--Roger

Group #1: COMID (coronamitmdisease2019) at OVH
019839E66C7229039367BEB4E83B27D08A9C2B37
110F26C0BFB2122BBB856EADC9A2D497989DE949
1B473D4B5C1D7C594E88B3044823D04E2BC51DBA
28EA24439668FBE905C801F8170C192E119C9FBD
378C5C8381700EC68EFDC427148CDE18DD94A014
48325E9146758F8636473D6D25FD4D7734E189CB
52DDF76A32CC3E0BFBAD72E511A0354343A224B3
7A8089D801EC09B20B1091CB031C79B7E0371818
7BD7DB37884F3DADC61E755FA9F03F499BC3C552
840C79C994150D6F6A48B5F8E8658AB74D36B052
852FB4885C5F9DEDE66BB9E5515A81EAE6E43B6B
8FAB1ADF9BE2D0E821AF92B8215F692CD715FD73
A2BA8791AA2A27DCB5B0C5B51E8CCF2337A5C1E2
BD32854443E891DBB685E43854BB382DEF081E94
C271F036CDFE8A90881B60712BF6ACF742259764
CA2F7497106CB8B9AAF0E1A7CF9866EAC9DB43B5
D26C58809FBC2C0D0251FB2991470A6AAB3EDC5B
DE50C4066BE7200F5D6AD0FC88452667451D39A9
F2D5E3A3E8B11CA72FF340C450A46F4C67AD8D1E

Group #2: i...@cypherpunklabs.com at OVH
023455597DAB689EE84FB3A7BC7FC5F9A3E27FD6
044E647F34EDA4AC975EDAD628C4E9BCFFF1FB08
04699AF0CB2B5A7F5CF943D31011F50F601BE8C7
05601B110B888BF3A12E10E8BF3C0B02166BF3F1
075FDD85EF4B783BCC9040580168F1FC5576B101
09930800210FF35CE84F2DEEDB4F9B67812B9717
0B7B08C50E419004F77447A72FFD578061F58311
0BAE1E20ACCB1F454A3A473185D83743E140B9D5
0BB27C3A307B35B5B2D2E8774D69DF7FA4B97867
0BE6EEB76C5641BF5D2E63C49C28CD50D2A40C15
0BF30C2AC9DBEF9C79B1119808F2FCC3FD81EE0A
0D58067912EA84D955565C82A4C00A47CDEF11DC
0DD55CF27BBA1F51131A46BC0A0EED68A177D1BB
1766E98ECC8A457FDBCBA7322C93F51FE1F896E7
186FF078A2EE09E8208ACBF4DDB61FFF96AD64B0
1B1351D85E8328BE21539EA9C0C0317E3A1CE380
1BD9EEB672246E8ADFFA5FA6B1D82F43447D
1C11D59B0144E9B33BB932A031BA8A3A5B81C65E
1D0971FA9B98AE2807D6A44AE6EB7EB120AB5675
1D515E91312D5F79895D607D6C27392DD5F6A84E
1EC0CCAFA8ABD5470B062AF470EAC97DD069C655
1F00A270AFDA1172DEDEC138AFEE977CFFB0FAD1
1FD39D081A3AA8E3D6F0962F8281A448D536C879
2369F6855A7CF31E3174CE26678FBBAD6A31D883
23BCFD8AB533AAE05639D1D79A445DEE76F8E57A
2541C0EB6F66C1344B3F14AB65EE7D6882EEF15F
29EC42BC7A3E7ED811578D5F656EC76D7A7AA2A5
2DE12251A7AF25B2CDFA9DE0F1B4022685ABAF3B
325499E7D6927D51229019F2EE031F26EBE095BB
386425D28458D4DB41F74F256AFF99ADB7E25271
38C36322890194015837A1085907DFA6AE3A9B00
3A6164437EF523E4907E7D97CAB135EFC39621F6
3BB398CA2D1F1E83AFC46641ABF8FECC989B8F19
3C5491293747761AFE9AF014FDA4B92960304D21
3CAA25A190B2F030DE86D0E99329E4D399472FB4
3CE91268F607E373482D1BCD33018CF1C77FAFA6
3DF6717E1C62D9ACF65CD5B3C609FBB271D9586D
3EE2A784ADB2F56E631F281F2688104A656E19C2
41280DE9ABE5BF10F7F5DCB13A28C07082064147
41E9201B42807012BCAFA6B94BCF9AD00CD787EA
442058BAE48FDFA68A3992988CBA6E2035FA8782
446FA7DE8A5DC2F2B0EBB9083753D127BB217F60
466F6F3B37435A6285C1F73F49EC58FA9D3A5260
47B22D6B46447B533E962966B9559E249B6F915C
4B777C07DFB28938D7D9B84737275F2412B5CA2A
4C52890A00964648E3AED7EB7CB178BA082610E6
4C6E75E65818844B7D3F3A8A9666525680006EAF
50A4A3A09AC7BC09F578670618A9BB864772EE03
554E9EE1586220B016B7C43490E7398F57C254D5
5A8A80399011B703FDB40E11226A389162DE0DD1
5BA611940BC239597312636D257F615F4F4D7BEB
5E6CB5FC020088CFC99342784A4109E468D7C94A
60D6F3FEE07527E749BD6BB3E401E5EB389EA45C
62CC081F58E5415DDD49A20D80A0E9A8A2E35CF3
63E4BD985E436877C471A743F1625F10FA114458
678FDB3BA0EEAA2572329A0BB0FF50E449D714ED
67FBB854B6DBD2DCBA5747FD761BF36096EFC0C0
6B6B3650F2FF83BD767AD84838600C62F937558B
6DA708660BA6F0BE1B67434951F0D0FE6AE72728
753C8EEDB1C2A9E1DBBF4DF75A2F549FD1A7F0FC
8002F46087D145E1CC5F4F11725494059E7A823D
80DF1465F2F27AA933DDB3A8F8A2AE06D3D859DA
823C31DD41F31ECDB44DB17198EAC2EDB7A295E8
85BFDBFCF9E711CF0F1A22C115368724D7C101F7
85D895B55F1A021663D441587F4FD822082E73C9
8668B39793EBDADD148AE8BB256B1E2E6ACD78D5
87B449E227ACB5C3FEB580942242183993866138
8D112569E620CB316F1FDC08BCFD93FF54F22ED9
8D599159A555665F199DD0F9E81277417C8D3973
94729C093EBFFC6102C47EE1EB40A8827AEF28E8
968CF9A51740B682ABE4DB11829488281B66DBD8
99F01989477E1F553BE789E25FB63CC2A2276E33
9A46602C82BD2C174F1C115A1D6E012DD0DFB57F
9C2EF7092D80859AC3DD4A39DF50B7

Re: [tor-relays] recently saw 4 tor relays in row on tails. bug in tor?

[Roger Dingledine]

On Thu, Oct 22, 2020 at 04:19:35AM +, BRBfGWMz wrote:
> I recently saw a series of 4 relays connected to each other:  
>   
> itomori, MediumSlesmn, hotbrownie, pellidos  
> itomori, docto, Geheimschreiber, 420isGay  
>   
> Dont most relays in the network of length 3? Bug in tor?

Your Tor picks three hops that it controls, and if it needs to build a
circuit that involves a relay that it didn't pick, it uses that other
relay as a fourth hop.

So you didn't tell us what you were doing, but this is normal behavior
for example when you're loading an onion service, because the rendezvous
process involves building circuits to relays that the onion service
picked. Your first three relays are for protecting you, and the later
relays in the path are there for other goals.

--Roger

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

Re: [tor-relays] My Tor exit node not visible

[Roger Dingledine]

On Sun, Oct 18, 2020 at 01:44:31PM +, netaudit wrote:
> I've set up a new Tor exit node around 15 hours ago but despite it had been 
> such a time and my exit is visible from outside world I still get little to 
> no traffic at all. I also cannot see my servers IP on bulk tor exit node list.

relay-search (atlas.torproject.org) is a better way to search Tor
relays than the bulk exit node list.

But that said, if it has published its relay descriptor, but it isn't
getting enough "Running" votes to make it into the consensus, it won't
be on atlas.

In that case, you can look it up by putting the identity fingerprint
onto the form at the bottom of
https://consensus-health.torproject.org/#relayinfo

My guess is that it's the same situation as the person asking this
question a few days ago -- it has an IPv6 address listed, but that IPv6
address is not reachable, so the relay isn't getting enough "Running"
votes to get listed.

Hope this helps!
--Roger

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

Re: [tor-relays] growing guard probability on exits (2020-10-15)

[Roger Dingledine]

On Fri, Oct 16, 2020 at 10:49:43AM +0200, nusenu wrote:
> lets see when this graph stops growing
> https://cryptpad.fr/code/#/2/code/view/1uaA141Mzk91n1EL5w0AGM7zucwFGsLWzt-EsXKzNnE/present/

Sounds good. I think, based on your graph, that it is a coincidence that
we launched the "KISTSchedRunInterval=2" experiment right around this
time. That is, your graph shows that the consensus weights for whether
to use exit relays solely for exiting went from "100%, always do it" to
"a tiny bit less than 100%" *before* we changed the KISTSchedRunInterval
value.

I guess we will get another data point when we turn KISTSchedRunInterval
back to its default of 10ms, and (we hypothesize) it has no impact on
the weights.

> why is this relevant?
> It puts more entities into an end-to-end correlation position than there used 
> to be
> https://nusenu.github.io/OrNetStats/#tor-relay-operators-in-end-to-end-correlation-position

Yep. I'm not worried in the short term here, since one of the features
of our guard design is that just because a relay suddenly has a chance
of being used as a Guard, that doesn't mean it becomes *your* guard. You
(your Tor client) already have your guard, and you'll be sticking with
it for the next few weeks probably.

So this question matters over the coming weeks or months, because clients
will be rotating to new guards and then they will have a tiny chance of
picking one of these exits as their guard, each time they rotate to a
new guard, which is typically an infrequent event.

*That* said: since the chance of picking any of these exits as your
guard is really tiny, I think that means they will have very few users
using them as guards, which puts them in a weird position. For example,
it means that if you're one of the very rare clients who picked an exit
as your guard, then your choice acts as a better fingerprint for you,
if you move around, and if there is an attacker that's in a position to
watch your local network in each new location.

I don't think we ever intended that edge case to happen, and it's kind
of an uncomfortable situation to be in.

I wonder if the right fix is: "if you have the Exit flag, you don't get
the Guard flag"?

I think it would mean that the tiny amount of excess capacity on exit
relays would get pushed into rarely-but-still-sometimes being used as
somebody's middle hop, which seems to me like a much better oucome.

> and it might also decrease exit traffic on exits when a tor client chooses an 
> exit as guard

I think load on these exits would increase, not decrease. They're
already going to be used for exiting. That is, if you need an exit
for your circuit, you're going to use one. The impact of these weights
will actually *increase* traffic on exits, because they will be used
for exiting like normal (there's no choice) but *also* they will be
(very rarely at present, but still more than the 'never' from last week)
used in other circuit positions too.

--Roger

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

Re: [tor-relays] Help setting up 2 Relays

[Roger Dingledine]

On Fri, Oct 16, 2020 at 03:36:30PM -0400, postmas...@coolcomputers.info wrote:
> I was wondering it anyone more experienced could help me with fixing 1
> TOR Exit and 1 TOR Relay. I have everything configured and fingerprints
> made they just seem to not me recognized by tor metrics.
> 
> Tor Relay: B0852A98ECDB40E95319DEE339662EEF50708066 Tor Exit:
> A5D03FC9BE6EE32BD20EE59649BAD802BF4A49FC

Go to the bottom of
https://consensus-health.torproject.org/#relayinfo
and then put in your relay fingerprints.

It looks like some of the directory authorities think they're running,
and some don't.

My guess is that they advertise an IPv6 address, and that this address
is not reachable.

--Roger

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

Re: [tor-relays] Network Performance Experiment - KISTSchedRunInterval - October 2020

[Roger Dingledine]

On Thu, Oct 15, 2020 at 11:40:34PM +0200, nusenu wrote:
> since it is in effect by now 
> https://consensus-health.torproject.org/#consensusparams
> could you publish the exact timestamp when it came into effect?

One can learn this from the recent consensus documents, e.g. at
https://collector.torproject.org/recent/relay-descriptors/consensuses/

And I agree that we should have a central experiment page (e.g. on gitlab)
that lists the experiments, when we ran them, when the network changes
occurred, what we expected to find, and what we *did* find.

David or Mike, can you make sure that page happens?

> I noticed some unusual things today (exits having a non-zero guard 
> probability),
> did you change more parameters than this one or was this the only one?

No, that was the only change.

We had a good discussion with Florentin et al on #tor-dev just now,
where we concluded that yes, we're still in "case 3be (E scarce)", but
the math still allows a little bit of use of exits for other roles:
check out the networkstatus_compute_bw_weights_v10() function in
src/feature/dirauth/dirvote.c.

So as far as we can tell so far, we are still in the "exit scarce"
case of Mike's weight voodoo, but his math allows exits to be used
a little bit in non-exit roles even in this case.

Wed = (weight_scale*(D - 2*E + G + M))/(3*D);

Wgd = (weight_scale - Wed)/2;

And Wed in this case is 9849 rather than 1.

So, to say it much more plainly, we are just barely on the other side
of the line from "exit capacity is so scarce that exits will only ever
be used for exiting."

Mike was expecting some rebalancing to be done by the bwauths, once
we shifted the Kist interval, but I don't know whether we're seeing
that rebalancing or if it this is a coincidence.

--Roger

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

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

[Roger Dingledine]

On Sun, Oct 11, 2020 at 01:39:17PM -0500, Mike Perry wrote:
> > I believe I can tell rerouting exits from exits having distinct IPs for
> > inbound and outbound connections - in most cases.
> 
> Are your scanners available for others to run? I understand that it is a
> risk that making them public may allow bad exits to avoid them, but is
> it ok if other specific people use and adapt the scanners?

Right, in this particular case, we already run a scanner which provides
public output: it's the tordnsel scanner, and check out
https://check.torproject.org/exit-addresses

So what we are missing still is (a) a human to go through that list
periodically to look for exits that have weirdly too many exit addresses,
especially addresses that overlap with other exits, and then (b) somebody
to automate the process that that human uses.

In the 'bad exit finding' world, we've had problems in the past with
false positives, where some automated tool spams us with "possible"
problem relays and we quickly learn that ignoring those reports is the
best use of our time. So as we try to automate this one, I'd be a fan
of putting the detection threshold quite high, so when we trigger on
a relay and escalate to the humans, it's because we're quite confident
there's something that needs action.

> >> Remember that our directory authorities are deliberately independent
> >> from TPI though, and even what I think is not necessarily what TPI
> >> thinks. The dirauths may have different opinions. Coordinating policy of
> >> this nature is difficult and requires consensus building.
> > 
> > Since dir auths have been removing these kinds of relays, I don't think 
> > there
> > is any policy change necessary.
> 
> Ok great! Sometimes I am surprised by their decisions, and I didn't see
> this one.

Right. This one's an easy choice, because not only is it wasteful as
you say, it is also a way that somebody can sign up an exit relay to
look at traffic without needing to actually be the exit for that traffic.

--Roger

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

Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1

[Roger Dingledine]

On Sun, Sep 20, 2020 at 12:57:46PM +0200, Felix wrote:
> Libressl 321 is not compatible to what is needed to make the authorities
> tor26, dizum, gabel., maatu. and longc. happy (let them not grant a
> "Running"). What can that be?
> 
> Please somebody can _confirm_ this thing?

You're not crazy. We had a user on irc reporting a similar thing,
and my guess at the time was also "libressl compatibility issue".

You can see it also by using a Tor client and setting "usebridges 1 bridge
ip:port" where ip:port is your ORPort. If it's like the user from irc,
it will get almost through the TLS handshake but not quite. That is,
the Tor client will fail to bootstrap.

If you could open a gitlab issue for the mystery, that would be great!

--Roger

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

Re: [tor-relays] OVH Mitigation

[Roger Dingledine]

On Wed, Sep 09, 2020 at 12:00:37PM +0100, Dr Gerard Bulger wrote:
> To be fair, the automated system takes it off after an our or two.  If my
> tor server is left in this mitigated state, the tor exit gets labelled a BAD
> EXIT which is something to avoid as takes days to be trusted again.

Can you point us to which relay this happened to, and an approximate
timestamp?

We don't badexit that many relays these days, so I am wondering if
something else is going on instead.

Thanks,
--Roger

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

Re: [tor-relays] anyone else with this issue?

[Roger Dingledine]

On Tue, Aug 25, 2020 at 06:49:01PM +, John Ricketts wrote:
> I as well.
> 
> On Aug 25, 2020, at 13:45, niftybunny  
> wrote:
> 
> ?Daily DDOS love the last 14 days ...

Hi! Can you provide more details? From Nifty's picture it looks like
they are full TCP connections? Do you have a sense of what do they do
when they connect?

And that would mean that they *aren't* packet-level ddoses, i.e. the
"I fill up your network connection with packets so no other packets can
get through" kind?

One of the strange things about working with things at the scale of the
Tor network is that sometimes the combined behavior of many Tor processes
can look like a DDoS. For example, maybe all of these connections come
from out-of-date Tors that are now behaving bizarrely since the network
now doesn't work the way their old logic expects.

We've also seen what looks like DDoS attempts on the directory
authorities, but on closer examination they are some alternative Tor
implementation that is running on many thousands of computers and is
fetching Tor consensus documents in a way that isn't sustainable:
https://gitlab.torproject.org/tpo/core/tor/-/issues/33018

There are also apparently some overloading attacks happening on some
popular onion services currently, and I wonder if those are bleeding
over into looking like many connections. Or, as we saw a few years ago
when we added the "ddos defense subsystem" in Tor, the attacks didn't
actually add much load, but it was when the onion services tried to scale
up to tens of thousands of Tors, to be able to respond to every incoming
rendezvous attempt, that those tens of thousands of Tors together looked
like an attack on the network.

So: the next step would be to try to learn more about what these
connections look like, where they're coming from, what they're doing, etc.

Also, if more people than just Nifty and John are seeing them.

Never a dull moment,
--Roger

___
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)

[Roger Dingledine]

On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
> This shit has to stop. Why are the relays in question still online?

Hm? The relays are not online -- we kicked them in mid June.

We don't know of any relays right now that are attacking users.

Or said another way, if anybody knows of relays that are doing any attacks
on Tor users, ssl stripping or otherwise, please report them. I believe
that we are up to date and have responded to all reports.

That said, there is definitely the uncertainty of "I wonder if those
OVH relays are attacking users -- they are run by people I don't know,
though there is no evidence that they are." We learned from this case
that making people list and answer an email address didn't slow them down.

I still think that long term the answer is that we need to shift the
Tor network toward a group of relay operators that know each other --
transparency, community, relationships, all of those things that are
costly to do but also costly to attack:
https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html

But the short term answer is that nobody to my knowledge has shown us
any current relays that are doing attacks.

Hope that helps,
--Roger

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

Re: [tor-relays] tor relay - vps maintenance - what to do ?

[Roger Dingledine]

On Sun, Jul 12, 2020 at 09:12:31PM +, dluga...@protonmail.com wrote:
> in the next three days, my VPS provider planning to shutdown 
> ("maintenanance") for 6 hours my VPS where tor relay is running (with some 
> services). What should I do ?
> 
> I suspect that my VPS will be copied and reviewed (by not authorized persons) 
> afterwards. How do You react in such a situations ?
> 
> I appreciate any advice.

The conservative choice would be to remove all the key material (that is,
delete the files in your DataDirectory/keys/ directory) before it shuts
down, and then start a fresh relay (with fresh keys) when it comes back.

It really comes down to how much you think they will mess with it (or
maybe even, why you think they've picked your VPS for maintenance at all).

Leaving it alone and not stressing about it, or rotating to fresh keys,
are both valid approaches. It depends how you want to approach it.

Hope that helps,
--Roger

___
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

[Roger Dingledine]

On Tue, Jul 07, 2020 at 01:01:12AM +0200, nusenu wrote:
> > https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> 
> thanks, I'll reply here since I (and probably others) can not reply there.

Fwiw, anybody who wants a gitlab account should just ask for one. Don't
be shy. :)

The instructions for asking are here:
https://gitlab.torproject.org/users/sign_in

> > (A) Limiting each "unverified" relay family to 0.5% doesn't by itself
> > limit the total fraction of the network that's unverified. I see a lot of
> > merit in another option, where the total (global, network-wide) influence
> > from relays we don't "know" is limited to some fraction, like 50% or 25%.
> 
> I like it (it is even stricter than what I proposed), you are basically saying
> the "known" pool should always control a fixed (or minimal?) portion - lets 
> say 75% - 
> of the entire network no matter what capacity the "unknown" pool has

Right.

> but it doesn't address the key question: 
> How do you specifically define "known" and how do you verify entities before 
> you move them to the "known" pool?

Well, the first answer is that these are two separate mechanisms, which
we can consider almost independently:

* One is dividing the network into known and unknown relays, where we
reserve some minimum fraction of attention for the known relays. Here
the next steps are to figure out how to do load balancing properly with
this new parameter (mainly a math problem), and to sort out the logistics
for how to label the known relays so directory authorities can assign
weights properly (mainly coding / operator ux).

* Two is the process we use for deciding if a relay counts as known. My
suggested first version here is that we put together a small team of Tor
core contributors to pool their knowledge about which relay operators
we've met in person or otherwise have a known social relationship with.

One nice property of "do we know you" over "do you respond to mail at
a physical address" is that the thing you're proving matters into the
future too. We meet people at relay operator meetups at CCC and Fosdem
and Tor dev meetings, and many of them are connected to their own local
hacker scenes or other local communities. Or said another way, burning
your "was I able to answer a letter at this fake address" effort is a
different tradeoff than burning your "was I able to convince a bunch of
people in my local and/or international communities that I mean well?"

I am thinking back to various informal meetings over the years at
C-base, Hacking At Random, Defcon, etc. The "social connectivity" bond
is definitely not perfect, but I think it is the best tool available to
us, and it provides some better robustness properties compared to more
faceless "proof of effort" approaches.

That said, on the surface it sure seems to limit the diversity we can
get in the network: people we haven't met in Russia or Mongolia or
wherever can still (eventually, postal service issues aside) answer a
postal letter, whereas it is harder for them to attend a CCC meetup. But
I think the answer there is that we do have a pretty good social fabric
around the world, e.g. with connections to OTF fellows, the communities
that OONI has been building, etc, so for many places around the world,
we can ask people we know there for input.

And it is valuable for other reasons to build and strengthen these
community connections -- so the incentives align.

Here the next step is to figure out the workflow for annotating relays. I
had originally imagined some sort of web-based UI where it leads me
through constructing and maintaining a list of fingerprints that I have
annotated as 'known' and a list annotated as 'unknown', and it shows
me how my lists have been doing over time, and presents me with new
not-yet-annotated relays.

But maybe a set of scripts, that I run locally, is almost as good and
much simpler to put together. Especially since, at least at first,
we are talking about a system that has on the order of ten users.

One of the central functions in those scripts would be to sort the
annotated relays by network impact (some function of consensus weight,
bandwidth carried, time in network, etc), so it's easy to identify the
not-yet-annotated ones that will mean the biggest shifts. Maybe this
ordered list is something we can teach onionoo to output, and then all the
local scripts need to do is go through each relay in the onionoo list,
look them up in the local annotations list to see if they're already
annotated, and present the user with the unannotated ones.

To avoid centralizing too far, I could imagine some process that gathers
the current annotations from the several people who are maintaining them,
and aggregates them somehow. The simplest version of aggregation is
"any relay that anybody in the group knows counts as known", but we
could imagine more complex algorithms too.

And lastly, above I said we can consider the two mechanisms "almost
independently" -

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

[Roger Dingledine]

On Sun, Jul 05, 2020 at 06:35:32PM +0200, nusenu wrote:
> 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). 

Thanks Nusenu!

I like the general goals here.

I've written up what I think would be a useful building block:
https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001



Three highlights from that ticket that tie into this thread:

(A) Limiting each "unverified" relay family to 0.5% doesn't by itself
limit the total fraction of the network that's unverified. I see a lot of
merit in another option, where the total (global, network-wide) influence
from relays we don't "know" is limited to some fraction, like 50% or 25%.

(B) I don't know what you have in mind with verifying a physical address
(somebody goes there in person? somebody sends a postal letter and waits
for a response?), but I think it's trying to be a proxy for verifying
that we trust the relay operator, and I think we should brainstorm more
options for achieving this trust. In particular, I think "humans knowing
humans" could provide a stronger foundation.

More generally, I think we need to very carefully consider the extra
steps we require from relay operators (plus the work they imply for
ourselves), and what security we get from them. Is verifying that each
relay corresponds to some email address worth the higher barrier in
being a relay operator? Are there other approaches that achieve a better
balance? The internet has a lot of experience now on sybil-resistance
ideas, especially on ones that center around proving online resources
(and it's mostly not good news).

(C) Whichever mechanism(s) we pick for assigning trust to relays,
one gap that's been bothering me lately is that we lack the tools for
tracking and visualizing which relays we trust, especially over time,
and especially with the amount of network churn that the Tor network
sees. It would be great to have an easier tool where each of us could
assess the overall network by whichever "trust" mechanisms we pick --
and then armed with that better intuition, we could pick the ones that
are most ready for use now and use them to influence network weights.



At the same time, we need to take other approaches to reduce the impact
and incentives for having evil relays in the network. For examples:

(1) We need to finish getting rid of v2 onion services, so we stop the
stupid arms race with threat intelligence companies who run relays in
order to get the HSDir flag in order to scrape legacy onion addresses.

(2) We need to get rid of http and other unauthenticated internet protocols:
I've rebooted this ticket:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850
with a suggestion of essentially disabling http connections when the
security slider is set to 'safer' or 'safest', to see if that's usable
enough to eventually make it the default in Tor Browser.

(3) We need bandwidth measuring techniques that are more robust and
harder to game, e.g. the design outlined in FlashFlow:
https://arxiv.org/abs/2004.09583

--Roger

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

Re: [tor-relays] Authority Nodes

[Roger Dingledine]

On Fri, Jun 19, 2020 at 07:10:43AM -0300, Vitor Milagres wrote:
> I see the Authority Nodes are located only in North America and Europe.
> I would like to contribute to the TOR network as much as possible. I am
> currently running a node and I would like to make it an Authority Node as
> well.
> I am from Brazil and I believe it would possibly be a good idea to have a
> new Authority Node in South America.
> What are the requirements? What should I do to become one of them?
> FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1

Thanks for your interest in running a directory authority! Long ago we
wrote up a set of goals for new directory authorities:
https://gitweb.torproject.org/torspec.git/tree/attic/authority-policy.txt

It is definitely an informal policy at this point, but it still gets
across some of the requirements.

If you're able to run an exit relay at your location, that's definitely
more useful than another directory authority at this point.

Also, because we haven't automated some steps, each new directory
authority that we add means additional coordination complexity, especially
when we identify misbehaving relays and need to bump them out of the
network quickly.

Here are two big changes since that document:

(1) The directory authorities periodically find themselves needing to
scale to quite large bandwidths -- sustaining 200mbit at a minimum,
and being able to burst to 400mbit or 500mbit, is pretty much needed at
this point:
https://bugs.torproject.org/33018

(2) Tor ships with hundreds of hard-coded relays called Fallback
Directories, which distribute the load for bootstrapping into the Tor
network, and which also provide alternate access points if the main
directory authorities are blocked.
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
So while the directory authorities are still a trust bottleneck,
they are less of a performance bottleneck than they used to be.

In summary: if you want to run a directory authority, your next step
is to join the Tor community, get to know us and get us to know you,
come to one of the dev meetings (once the world is able to travel
again), and see where things go from there.

Thanks,
--Roger

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

Re: [tor-relays] "/var/tor/diff-cache" full!

[Roger Dingledine]

On Thu, Jun 18, 2020 at 10:21:34AM +0200, Salvatore Cuzzilla wrote:
> Hi Folks,
> 
> I'm running a non-exit relay (v0.4.2.7) on OpenBSD 6.7.
> The amount of files within "/var/tor/diff-cache" is steadily increasing.
> Up to almost 6G fulfilling the /var partition to the max.
> 
> Is this an expected behavior? I there any solution to overcome it?

Definitely not expected behavior. Tor maintains a bunch of files there,
and they can grow to take up a huge amount of space, but huge should be
on the order of a few hundred megabytes. In particular, it should be
automatically deleting files that are old enough to be unlikely to be
used in practice.

I wonder if your OS is interfering with the deletion process somehow,
like with an apparmor equivalent?

Or, has your clock changed in a significant way? What are the timestamps
on the files?

Each file should be around 500KBytes to 1MByte ish, so if any of the
files are way way bigger than this, that's good info too.

--Roger

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

Re: [tor-relays] directory servers working on updates?

[Roger Dingledine]

On Sun, Jun 14, 2020 at 07:27:55PM +0200, Paul Geurts wrote:
> anything up this weekend?
> 
> [image: image.png]

Yes. There is a mysterious alternative Tor client out there, which is
programmed to do uncompressed directory fetches just from the directory
authorities. It easily overloads directory authorities if they don't use
the defenses we put in for it over the past few months:
https://bugs.torproject.org/33018

This alternate set of Tor clients recently came back, and you can see
its impact in e.g. the bandwidth graph for gabelmoo:
https://metrics.torproject.org/rs.html#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281

Now, fortunately, it doesn't ask for directory information in the same
way as any of the Tors that we've ever built, so the fix in #33018 was
to keep answering the Tors that we built, while declining to answer
these other requests when we're low on bandwidth.

But even still, some of the directory authorities are having trouble
under the load, and the resulting desynchronization means that not every
directory authority succeeds at participating in every consensus round.

That's probably what you're seeing with the inconsistencies on
https://consensus-health.torproject.org/

If somebody knows some details of what these other Tor clients actually
are, that would be really helpful to know!

--Roger

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

Re: [tor-relays] Unused Relay - Why?

[Roger Dingledine]

On Sat, Jun 06, 2020 at 05:38:09AM +, petra...@protonmail.ch wrote:
> Hello all,
> my relay is set up to support 42 Mbps, however does not get any real traffic 
> routed through it (605EE4375EE4C38215C8949F5808863749FD4F4A). I checked 
> anything I could think of but everything looks fine to me. Anyone with an 
> idea what could be wrong here? Many thanks!

Hi! Thanks for running a relay.

If you go to the bottom of
https://consensus-health.torproject.org/#relayinfo
and put in your relay fingerprint, you'll find that every one of the
bandwidth authorities thinks it is slow compared to its peers -- i.e.
compared to other relays that currently advertise in the same range of
900KBytes/s of peak capacity.

You can see the consensus weight voted by each bwauth in the "bw="
entries. (The numbers for consensus weight are technically unitless
but you can think of them kind of like kilobytes per second. What that
means isn't that the bwauths think your relay can only do 56KBytes/s
of traffic, but that your relay is so overloaded, compared to your
peers, that clients should *treat* it like a relay that is advertising
56KBytes/s, in order to load balance properly among all the relays.)

I just tried using your relay for a while, and I pretty consistently got
a limit of about 250kbytes/s-300kbytes/s (2mbit to 3mbit) out of it --
nowhere near the 42mbits you describe.

I wonder if your internet connection is asymmetric, i.e. you can download
quickly but you can't upload quickly?

--Roger

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

Re: [tor-relays] Bridge log indicates missing geoipdb

[Roger Dingledine]

On Mon, May 25, 2020 at 04:12:07PM +, nottryingtobel...@protonmail.com 
wrote:
> Tried to run sudo apt install tor-geoipdb and got this:
> 
> The following packages have unmet dependencies:
> tor-geoipdb : Depends: tor (>= 0.4.3.5-1~d10.buster+1) but 
> 0.4.2.7-1~d10.buster+1 is to be installed
> E: Unable to correct problems, you have held broken packages.

Are you perhaps on the 32-bit arm architecture, aka armel and armhf?

If so, see weasel's announcement about no longer providing those
because the build machines are too hard to keep working:
https://lists.torproject.org/pipermail/tor-talk/2020-May/045582.html
https://lists.torproject.org/pipermail/tor-talk/2020-May/045583.html

Options include trying the backports repos, or building the deb
yourself, or moving back to the Tor in actual debian buster.

--Roger

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

Re: [tor-relays] Why does it take 4 days to get the HSDir flag back?

[Roger Dingledine]

On Thu, May 21, 2020 at 08:03:03PM +0200, tscha...@posteo.de wrote:
> after an update of tor it always take about 4 days to get the HSDir flag
> back while the other flags are set very qick. What is the reason for
> this delay?

It's because the directory authorities are configured to wait that long
before assigning the flag.

See the MinUptimeHidServDirectoryV2 option:
https://gitweb.torproject.org/tor.git/tree/src/feature/dirauth/dirauth_options.inc?h=tor-0.4.3.5#n55

It used to be 25 hours, long ago, with the reasoning that if a relay
hasn't been up for a day, then it's too likely to go away again soon,
and this churn causes reliability problems in reaching onion services.

We changed it to 96 hours in late 2014, when we saw a Sybil attack (many
new relays suddenly appearing) and realized that while they wouldn't
become Guards for a while, they would become HSDirs quite quickly, and
maybe we want to give ourselves a few more days after new relays appear
before they get to become HSDirs.

And here are two tickets on doing even more to make it hard for jerks
to sign up relays with the goal of cheaply getting the HSDir flag:
https://bugs.torproject.org/16538
and
https://bugs.torproject.org/19162

And of course the long term fix is to drop the deprecated v2 onion
service design, since the v3 onion service design is much better at
limiting what an HSDir relay can learn about onion services:
https://www.youtube.com/watch?v=Di7qAVidy1Y

Hope this helps,
--Roger

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

Re: [tor-relays] consensus page 'down'

[Roger Dingledine]

On Sun, May 17, 2020 at 10:01:24AM +0200, Paul Geurts wrote:
> it seems to me that the tor consensus page has not been updated since:
> Consensus was published 2020-05-14 19:00:00 UTC

You're right!
https://consensus-health.torproject.org/

I've mentioned it to Tom, our volunteer maintainer for the page. And
also I think he is getting these mails.

Hopefully he'll find a neat bug somewhere and we'll all get smarter. :)

Thanks,
--Roger

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

Re: [tor-relays] obfs4 bridge port question

[Roger Dingledine]

On Sat, May 09, 2020 at 01:15:46PM -0700, Eddie wrote:
> > Bridge obfs4 :  cert= iat-mode=0
> > I have all the parts mentioned in the text except for .
> >
> It's the port from this line:  ServerTransportListenAddr obfs4
> 0.0.0.0: where the odfs4 is listening.

Right. Or if you didn't set a ServerTransportListenAddr line in your
torrc file, then you can get it either from the log line:

[notice] Registered server transport 'obfs4' at '[::]:46396'

or from a corresponding line the 'state' file in your DataDirectory.

But really, if you didn't choose it via ServerTransportListenAddr, you
probably haven't set up port forwarding for it, or made a hole for it
in your firewall, or whatever you will need to do to make it reachable
from the outside.

You can test reachability for it using this tool that Philipp set up:
https://bridges.torproject.org/scan/

Bridges don't yet automatically test reachability for their obfs4 port
(sad but true).

Thanks!
--Roger

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

Re: [tor-relays] Feature request to aide bridge operators

[Roger Dingledine]

On Fri, May 01, 2020 at 09:28:09PM +, nottryingtobel...@protonmail.com 
wrote:
> I brought up a new bridge and thought everything was fine according to the 
> logs (OR port accessible, check, server descriptor published, check, etc.). I 
> didn't see any activity on it after awhile, so I tried to test it and was 
> unable to connect. Turns out, I forgot to open the randomized server 
> transport port.
> 
> I think it would be really nice if there was a log entry confirming the OBFS4 
> port is open and accessible. Currently the only entry you get related to this 
> is "[notice] Registered server transport 'obfs4' at '[::]:35375'".
> 
> Wondering how the community feels about this. Thanks.

Yes, we would love to have this feature, but nobody has built it.

That's partly because testing the ORPort is relatively easy, because the
Tor program speaks the Tor protocol; but testing the obfs4 port is harder,
because the obfs4 server side doesn't usually do client things too.

Here are two tickets to watch:
https://bugs.torproject.org/30477
https://bugs.torproject.org/31874
...or you don't have to watch, you can jump in and help. :)

In the mean time, also check out the "bridge scan" tool that phw put up:
https://bridges.torproject.org/scan/
which is linked from the instructions in e.g.
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/

Thanks,
--Roger

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

Re: [tor-relays] Again: abuse email for non-exit relay (masergy)

[Roger Dingledine]

On Sun, May 03, 2020 at 10:15:47PM +0200, li...@for-privacy.net wrote:
> Below is the information about the attack.  Keep in mind that the source IP
> of our client has been sanitized for anonymity.
> 
> Date: 04/30/2020
> Time: 11:05:37
> Time Zone: America/Chicago
> Source(s): 37.157.255.118
> Type of Attack/Scan: Generic
> Hosts: 10.10.10.182
> Log:
> 
> 37.157.255.118:9002 > 10.10.10.182:24562

The person sending you this abuse complaint is deeply confused. My guess
is that they are running some automated "attack detector" software, and
the software is buggy and telling them things that are wrong.

If your relay were making connections to their user, it would not be
using port 9002. It would be using some high-numbered port for the
outgoing connection.

So what's likely happening here instead is that *their* user is contacting
*your* relay -- that is, the person they call "our client" is a Tor user
using your relay -- but their automated attack detector is not seeing the
initial connection from their user to your relay, and it's misinterpreting
the response from your relay to the user as an outgoing connection.

I get these sort of automated abuse complaints a few times a year to
moria1, my directory authority, and in many cases it's people running a
Tor client or relay somewhere, and that somewhere's ISP really wants me
to stop "attacking" their user, when actually what's happening is that
their user contacts my relay a lot.

So in summary: there is nothing to fix, because the complaint is wrong
about what's going on.

Whether you should respond depends on whether you need to answer your
own hosting provider to keep them happy, and/or whether you want to try
to engage with the stranger on the internet who doesn't yet understand
that their own reporting software is buggy. :)

Hope that helps,
--Roger

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

Re: [tor-relays] Exit stops after one year, then again after few days

[Roger Dingledine]

On Thu, Apr 30, 2020 at 11:14:11PM +0200, yl wrote:
> I am too tired now to look into it, but I would love to get some
> requests for information to supply and will look to supply all info
> needed. The server is still in the error state.

Did you ever tell us a fingerprint (and/or nickname) for your relay?

My first question would be whether the relay has an IPv6 ORPort, because
maybe that address became unreachable.

--Roger

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

[Roger Dingledine]

On Sat, Apr 18, 2020 at 10:16:34AM +0200, Clément Février wrote:
> The issue is back. After more than 3 days, the relay appears offline.
> All flags are gone in nyx. There is a bug.

I believe there is something wrong with your ipv6 port.

I see that your relay is advertising
[2001:41d0:fecf:8900:216:3eff:fe8a:e4a6]:9001

and when I go to
https://bridges.torproject.org/scan/
and put in
"[2001:41d0:fecf:8900:216:3eff:fe8a:e4a6]" and "9001", it tells
me "i/o timeout".

So I would suggest removing the ipv6 stuff for a while and see if things
get better for you.

And then also exploring why your ipv6 address is not consistently
routable, or not consistently reachable, or whatever else is going wrong
with it.

Thanks,
--Roger

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