let's make ContactInfo mandatory for exits (and warn others)
After looking at lots of malicious relay data of the past few months I've come to the conclusion that exit relays without ContactInfo are largely run by malicious actors. I propose to make torrc's ContactInfo mandatory for exit relays with the following timeline: * tor 0.4.6: log a warning that tor will require ContactInfo to be set on an exit relays starting with tor v0.4.7 * tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo (< 5 chars) in their descriptor. Log a warning for relay operators, I'll add graphs that show exit fraction provided by exit relays without ContactInfo over time to OrNetStats. Is this an effective remedy to deter malicious actors? No and it is not meant to be one. It is trivial to set a random non-empty ContactInfo, only in combination with other countermeasures it becomes actually useful. ContactInfo is also mentioned in this draft: https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Re... I'll make it easy for Tor Browser users to exclude exit relays without ContactInfo from their configuration. This might makes the proposal irrelevant should the release alone result in exits getting non-empty ContactInfos. More details will follow soon. kind regards, nusenu -- https://nusenu.github.io
On 4/24/21 12:11 PM, nusenu wrote:
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo (< 5 chars) in their descriptor. Log a warning for relay operators,
I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays. So I do not have the Exit flag. Nevertheless I see about 100 exit connections at 2 relays here and do wonder now if opening those ports is ok and which types of clients use them ? Here're the data of one of the relays got with [1] ORport 9051 0.4.7.0-alpha-dev uptime: 7-19:57:56 flags: Fast, Guard, HSDir, Running, Stable, V2Dir, Valid +------------------------------+------+------+ | Type | IPv4 | IPv6 | +------------------------------+------+------+ | Inbound to our OR from relay | 1899 | 260 | | Inbound to our OR from other | 3361 | 32 | | Inbound to our ControlPort | 1 | | | Outbound to relay OR | 4770 | 956 | | Outbound to relay non-OR | 1 | | | Outbound exit traffic | 56 | 9 | | Outbound unknown | 10 | | +------------------------------+------+------+ | Total | 10098 | 1257 | +------------------------------+------+------+ +------------------------------+------+------+ | Exit Port | IPv4 | IPv6 | +------------------------------+------+------+ | 53 (DNS) | 1 | | | 563 (NNTPS) | 2 | | | 853 | 2 | | | 5222 (Jabber) | 31 | 5 | | 5223 (Jabber) | 7 | | | 6667 (IRC) | 5 | 2 | | 6697 (IRC) | 8 | 2 | +------------------------------+------+------+ | Total | 56 | 9 | +------------------------------+------+------+ [1] https://github.com/toralf/torutils/blob/master/info.py -- Toralf
Hi Toralf, Toralf Förster:
On 4/24/21 12:11 PM, nusenu wrote:
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo (< 5 chars) in their descriptor. Log a warning for relay operators,
I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays. So I do not have the Exit flag.
I don't see how your email es related to my email? :) Would you mind to elaborate? kind regards, nusenu -- https://nusenu.github.io
On 4/24/21 9:21 PM, nusenu wrote:
Hi Toralf,
Toralf Förster:
On 4/24/21 12:11 PM, nusenu wrote:
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo (< 5 chars) in their descriptor. Log a warning for relay operators,
I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays. So I do not have the Exit flag.
I don't see how your email es related to my email? :) Would you mind to elaborate?
kind regards, nusenu
Well, not really to your email,just to the fraction "assign the exit flag" - yeah, sry, maybe a separate thread would be better. -- Toralf
nusenu:
After looking at lots of malicious relay data of the past few months I've come to the conclusion that exit relays without ContactInfo are largely run by malicious actors.
I propose to make torrc's ContactInfo mandatory for exit relays with the following timeline:
* tor 0.4.6: log a warning that tor will require ContactInfo to be set on an exit relays starting with tor v0.4.7
* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo (< 5 chars) in their descriptor. Log a warning for relay operators,
I'll add graphs that show exit fraction provided by exit relays without ContactInfo over time to OrNetStats.
Is this an effective remedy to deter malicious actors? No and it is not meant to be one. It is trivial to set a random non-empty ContactInfo, only in combination with other countermeasures it becomes actually useful.
ContactInfo is also mentioned in this draft: https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Re...
I'll make it easy for Tor Browser users to exclude exit relays without ContactInfo from their configuration. This might makes the proposal irrelevant should the release alone result in exits getting non-empty ContactInfos. More details will follow soon.
I don't think we should go to add something into tor. That's a lot of effort and additional code compared to the expected win. First of all, this is easy to game as you are mentioning. Secondly, and more importantly, we should instead catch such malicious relays when scanning or looking over the nodes joining the network. Additionally, looking over the last couple of weeks and months it seems there are some non-malicious exit nodes with no contact info joining the network, too. There is the risk that we drive those relay operators away by a) raising the bar generally for entering the network and b) making it more confusing to setup relays by requiring some (even non-valid) contact info for exit relays yet not for non-exits. So, yes, fighting against malicious (exit) nodes is an important and ongoing task but we should use the right means for that goal without adding additional burdens to exit node operators if we can help it. (FWIW: on the client side there is still the HTTPS-only mode in the pipeline, which could easily be a game-changer here, too.) Georg
kind regards, nusenu
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
(FWIW: on the client side there is still the HTTPS-only mode in the pipeline, which could easily be a game-changer here, too.)
Is the torproject backporting https-only mode [1] to 78esr / Tor Browser? kind regards, nusenu [1] https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-onl... -- https://nusenu.github.io
On Sun, Apr 25, 2021 at 7:13 PM nusenu <nusenu-lists@riseup.net> wrote:
(FWIW: on the client side there is still the HTTPS-only mode in the pipeline, which could easily be a game-changer here, too.)
Is the torproject backporting https-only mode [1] to 78esr / Tor Browser?
No. Firefox 78esr has an older version of https-only mode, but newer versions of Firefox have many bugfixes. We don't feel comfortable enabling the current implementation available in Tor Browser, and backporting the fixes/improvements would be challenging. Currently, our recommendation is enabling EASE mode in https-everywhere if you feel comfortable with the trade-offs, but that mode has usability issues as well, and we aren't comfortable enabling that for everyone. When Tor Browser migrates to Firefox 91esr we will look at enabling https-only mode for everyone, but there remains a significant concern that there are many sites that do not support HTTPS (especially more region specific sites) and the question of what messaging Tor Browser should use in that case.
kind regards, nusenu
[1] https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-onl...
-- https://nusenu.github.io _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, April 24, 2021 3:11 AM, nusenu <nusenu-lists@riseup.net> wrote:
Is this an effective remedy to deter malicious actors? No and it is not meant to be one. It is trivial to set a random non-empty ContactInfo, only in combination with other countermeasures it becomes actually useful.
This. Also, not all of us are okay with the world finding out that we run Tor nodes. Some of us just do it and don't make a big deal about it. The Doctor [412/724/301/703/415/510] WWW: https://drwho.virtadpt.net/ The old world is dying, and the new world struggles to be born. Now is the time of monsters.
The Doctor [412/724/301/703/415/510]:
Also, not all of us are okay with the world finding out that we run Tor nodes. Some of us just do it and don't make a big deal about it.
Since this is an often misunderstood point: a non-empty contactinfo is far from anything that requires a person to be linked to their tor relay. My email was also intended to let exit operators know that they might notice less traffic in the near future on exits that have no contactinfo. kind regards, nusenu -- https://nusenu.github.io
nusenu:
The Doctor [412/724/301/703/415/510]:
Also, not all of us are okay with the world finding out that we run Tor nodes. Some of us just do it and don't make a big deal about it.
Since this is an often misunderstood point:
a non-empty contactinfo is far from anything that requires a person to be linked to their tor relay.
My email was also intended to let exit operators know that they might notice less traffic in the near future on exits that have no contactinfo.
Just to be clear on that point: there is currently no plan to implement such a "exit nodes with no contactinfo get less traffic"-plan. Georg
On Samstag, 24. April 2021 22:35:44 CEST The Doctor [412/724/301/703/415/510] wrote:
Also, not all of us are okay with the world finding out that we run Tor nodes. Some of us just do it and don't make a big deal about it.
Then take an anonymous mail address. Productive services on the Internet must be accessible somehow. Just a few weeks ago, Roger had to write to many exit operators because there are problems with the routing|reachability to some IPs in ASN A3 (@MIT). The 3 Letter Agencys have no problem getting your home address if you have an exit for a longer period of time. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On Sat, 24 Apr 2021 12:11:46 +0200 nusenu <nusenu-lists@riseup.net> allegedly wrote:
After looking at lots of malicious relay data of the past few months I've come to the conclusion that exit relays without ContactInfo are largely run by malicious actors.
I propose to make torrc's ContactInfo mandatory for exit relays with the following timeline:
With respect nusenu, exactly what is your relationship to the Tor project? Are you even in a position to mandate anything? I recognise, and applaud, the (apparent) time and effort you put in to looking at the health of the network, and I am grateful for that, but I have never been at all clear what your role is and how it is connected to the core project. Regards Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------
I propose to make torrc's ContactInfo mandatory for exit relays with the following timeline:
With respect nusenu, exactly what is your relationship to the Tor project?
To be clear: I'm not a member of the Tor Project and I don't claim to be one.
Are you even in a position to mandate anything?
Maybe I was misunderstood, I'm not making anything mandatory nor am I claiming to be in a position to do so. I did propose making ContactInfo mandatory for exits. Anyone can make proposals and everyone is free to challenge them. kind regards, nusenu -- https://nusenu.github.io
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, April 24, 2021 3:11 AM, nusenu wrote:
Is this an effective remedy to deter malicious actors? No and it is not meant to be one. It is trivial to set a random non-empty ContactInfo, only in combination with other countermeasures it becomes actually useful.
This.
Also, not all of us are okay with the world finding out that we run Tor nodes. Some of us just do it and don't make a big deal about it.
+1 Additionally, by forcing a sort of verifiable contact scheme, you are making it easy for global law enforcement and criminals to identify, harass, and otherwise harm exit operators. This has the side effect of bypassing legal process and "notice to customer" policies at the ISP. I do not understand this drive for de-anonymization, coercion, and control of what volunteers can and cannot do with tor.
participants (8)
-
Georg Koppen -
Jonas -
lists＠for-privacy.net -
Matthew Finkel -
mick -
nusenu -
The Doctor [412/724/301/703/415/510] -
Toralf Förster