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] Exit relay operators please help test #2667 branch

[s7r]

Roger Dingledine wrote:

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



Hello,

Indeed the defense is triggered more often than I expected. Very nice.

I tried to read on that ticket that's a decade old but didn't understand 
what was the final resolution.


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?


What happens if the abuser has a different valid consensus (newer/older) 
that has some relays which are not known by the Exit? Or if the abuser 
uses for re-entry a relay configured with `PublishServerDescriptor 0`? 
How does it treat bridges?


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?




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

Re: [tor-relays] 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] tor-relays Digest, Vol 120, Issue 25

[Patrice Bönig]

Am 03.02.2021 um 21:14 schrieb Patrice Bönig:
I am now compiling the new 0.4.4.7 version and by that I saw that the 
entry of "systemd support (--enable-systemd)" is is "no". So I assume 
that the systemd functionality is not on board, or am I wrong?

How do I enable for the compiling process?

regards
Karl


Permissions issue of /var/lib/tor / DataDirectory most likely, and 
Tor can't fix it itself since it's likely owned by root, however the 
systemd unit starts it under a separate user. 2021-01-22 12:03 GMT, 
Patrice B?nig :

Hi @ list,

I am operating a relay for several years and I really do like it and
will do it for more years.

My current relay residents on Pi 4. At first I installed it via apt but
now the 32 Bit sources are no longer available. So I thought I could
build the from source.

The building process went well but now I have a problem with the user
permissions. I can't get tor really running.

_My first attempt was:_

To start tor with "systemctl start tor". But tor won't start and "
journalctl -u tor" says only this:

Jan 22 09:06:23 rpi4tor systemd[1]: Starting LSB: Starts The Onion
Router daemon
Jan 22 09:06:23 rpi4tor systemd[1]: Started LSB: Starts The Onion Router
daemon
Jan 22 09:08:32 rpi4tor systemd[1]: Stopping LSB: Starts The Onion
Router daemon
Jan 22 09:08:32 rpi4tor systemd[1]: tor.service: Succeeded.
Jan 22 09:08:32 rpi4tor systemd[1]: Stopped LSB: Starts The Onion Router
daemon
lines 1-6/6 (END)...skipping...
-- Logs begin at Thu 2019-02-14 11:11:59 CET, end at Fri 2021-01-22
11:54:47 CET. --
Jan 22 09:06:23 rpi4tor systemd[1]: Starting LSB: Starts The Onion
Router daemon processes...
Jan 22 09:06:23 rpi4tor systemd[1]: Started LSB: Starts The Onion Router
daemon processes.
Jan 22 09:08:32 rpi4tor systemd[1]: Stopping LSB: Starts The Onion
Router daemon processes...
Jan 22 09:08:32 rpi4tor systemd[1]: tor.service: Succeeded.
Jan 22 09:08:32 rpi4tor systemd[1]: Stopped LSB: Starts The Onion Router
daemon processes.

_My second attempt was:_

I changed the user of all tor files to the current user "pi". After that
I was able to start tor with "tor --quiet" as user "pi". All went fine
until I rebooted the system and all my changes to "pi" where changed to
"debian-tor".

_My third attempt was:_

I did "sudo tor --quiet". It works, but in "notices.log" is the
information that I shouldn't do that.


So, now I am standing here and don't know what to do. I would like to
start tor via systemd but I don't know what's wrong (maybe the
permissions). Does someone has a hint for me?

regards,
Karl



___
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

[volker.mink]

Hi Matt.

 

This cmd could help, give it a try

 

sudo apt-key adv --recv-keys --keyserver keys.gnupg.net  YOURMISSINGKEY

 

 

Best regards,

volker 

 

 

 

Von: tor-relays  Im Auftrag von tor
Gesendet: Mittwoch, 3. Februar 2021 18:17
An: tor-relays@lists.torproject.org
Betreff: [tor-relays] Sig ver error

 

Hi all,

 

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

Fetched 3528 B in 3s (998 B/s)

Reading package lists... Done

W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error:  
 
https://deb.torproject.org/torproject.org stretch InRelease: The following 
signatures were invalid: EXPKEYSIG 74A941BA219EC810  
 deb.torproject.org archive signing key

W: Failed to fetch  
 
https://deb.torproject.org/torproject.org/dists/stretch/InRelease  The 
following signatures were invalid: EXPKEYSIG 74A941BA219EC810  
 deb.torproject.org archive signing key

W: Some index files failed to download. They have been ignored, or old ones 
used instead.

 

 

Any thoughts would be appreciated.

 

thanks,

matt

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

[tor-relays] Sig ver error

[tor]

Hi all,

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

Fetched 3528 B in 3s (998 B/s)

Reading package lists... Done

W: An error occurred during the signature verification. The repository is
not updated and the previous index files will be used. GPG error:
https://deb.torproject.org/torproject.org stretch InRelease: The following
signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive
signing key

W: Failed to fetch
https://deb.torproject.org/torproject.org/dists/stretch/InRelease  The
following signatures were invalid: EXPKEYSIG 74A941BA219EC810
deb.torproject.org archive signing key

W: Some index files failed to download. They have been ignored, or old ones
used instead.



Any thoughts would be appreciated.


thanks,

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