Re: [tor-relays] Active MetricsPort logs "Address already in use"

[Alexander Dietrich]

> David Goulet  hat am 22.03.2021 13:24 geschrieben:
> 
> > Sending GET requests to the address returns empty responses.
> 
> You should be able to get the metrics with a GET on /metrics.
> 
> Let us know if this works for you!

The empty 200 response is returned from "/metrics", I guess due to the "address 
already in use" problem. Requests to "/" return a 404.

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

Re: [tor-relays] is this valid bridge config

[Toralf Förster]

On 3/23/21 4:13 PM, gi vian wrote:

ExitPolicy reject *:*

IMO this is not needed


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

[tor-relays] Failed upgrade

[r1610091651]

Hi

FYI

So I've upgraded tor package from 0.4.4.6 to 0.4.5.7-1~xenial+1. No other
changes.
Yet on startup tor is complaining about mis-configuration:

Mar 23 20:55:02.928 [notice] Read configuration file
"/usr/share/tor/tor-service-defaults-torrc".
Mar 23 20:55:02.929 [notice] Read configuration file "/etc/tor/torrc".
Mar 23 20:55:02.932 [warn] Configuration port ORPort 9443 superseded by
ORPort :9443
Mar 23 20:55:02.932 [warn] We are listening on an ORPort, but not
advertising any ORPorts. This will keep us from building a router
descriptor, and make us impossible to use.
Mar 23 20:55:02.932 [warn] Failed to parse/validate config: Misconfigured
server ports
Mar 23 20:55:02.932 [err] Reading config failed--see warnings above.

config:
ORPort :9443 NoAdvertise
ORPort 9443 NoListen IPv4Only
AddressDisableIPv6 1
OutboundBindAddress 

This config is according to spec and worked with 4.4.6.

Seems to be related to thes issues, except for me it's blocking: tor fails
to start.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40300
https://gitlab.torproject.org/tpo/core/tor/-/issues/40302

I had to add 0.0.0.0 as ip to make tor start, although that's not
documented...
ORPort :9443 NoAdvertise
ORPort 0.0.0.0:9443 NoListen IPv4Only

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

[tor-relays] is this valid bridge config

[gi vian]

hello,

i want to run bridge. i have configured using tor relay configurator(1). is
this valid or can it be improved.

config

--

ORPort auto
SocksPort 0
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:8042
ExtOrPort auto
Log notice file /var/log/tor/notices.log
ExitPolicy reject *:*

--

regards,
vian

(1) https://tor-relay.co/
___
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?

[William Kane]

Roger:

>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'm fully aware of that, but wouldn't it take a "malicious" guard in
order to forward all these circuit creation requests anyway?

Last time I checked, the authorities were configured to vote on /
publish reasonable thresholds of consecutive connections and circuit
creation requests for relays to adapt (however most of the mitigation
only takes place on guards, which makes sense), so even if a client is
doing all this and we obviously can't get their IP address, the guard
would have to be configured in a way that allows this scenario to
happen in the first place, in my opinion making them bad relays -
right now my relay only takes place as a middle in a circuit, so
figuring out the guard is possible (not considering the onion service
scenario right now).

- William

On 23/03/2021, Roger Dingledine  wrote:
> 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
>
___
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