Tor Relay Operators Needs
Hi everyone, My name is Eran Sandler and I'm the Operator of tor4thepeople1 (98F44299592FC31FD3F2F8969D27374D00E96B9B) and tor4thepeople3 (CEACA34874EAD103D27CA6A7650B16112F12B209) - tor4thepeople2 had to go away, unfortunately. I also developed the gonionoo (https://github.com/erans/gonionoo) an Go wrapper around the Onionoo API. I've been running various tor relays and exit nodes since Sep/2015. Being a software developer by trade I've been thinking about projects and services that might help Tor Relay Operators and Tor in general and have a few ideas I wanted to pass along and see if anyone sticks. A few of the most notable ones are: - *Tor Weather Replacement* - ever since Tor Weather went down I've found that I actually miss it. It doesn't happen often that my relays are down but it does happen from time to time and in the past Tor Weather really helped get notified. A few things I thought about adding in addition to "Your node is down" alert are: - Node version is too old - New versions of Tor that are relevant to you are available etc - Sends node stats every given interval - *Free domain name for every Tor node operator who wants it*. A while back I purchased torexitnode.net and I wanted to develop a system that, upon verifying a running node (send an email to the published Email address of a node and verify its running) - will give a subdomain under torexitnode.net. I'm currently using it for tor4thepeople1.torexitnode.net and tor4thepeople3.torexitnode.net. I find that it makes things easier to explain when that's the node name. If you can get your hosting service to provide you with an updated reverse DNS for your IP address and point it to a subdomain of torexitnode.net it make it very clear that this is a Tor exit node. - *System to provide tor exit node verification*. Given a pre-registered app and callback and a fingerprint of a node it will find the Email of the operator and email a unique link. When that link is clicked a callback will be made to the preregistered URL - allowing a developer to verify that a certain node operator is truely the one accessing the service. That is actually needed for both of the services mentioned above. - *Simple package to run a webserver + customized tor exit node notice page* - similar to what I configured for http://tor4thepeople1.torexitnode.net. It's very useful and if we can get a super basic web server that only serves this page and would be easy to install (maybe even bundle with Tor) + let's encrypt integration (to serve it under SSL) it would provide great benefit to all operators. If you have additional ideas and or thoughts about the above projects or other projects please let me know. Looking forward to your thoughts. Thanks, Eran
Hi Eran, a developer offering to help relay operators what better can we ask for :) Eran Sandler:
Being a software developer by trade I've been thinking about projects and services that might help Tor Relay Operators and Tor in general and have a few ideas I wanted to pass along and see if anyone sticks.
A few of the most notable ones are:
- *Tor Weather Replacement* - ever since Tor Weather went down I've found that I actually miss it. It doesn't happen often that my relays are down but it does happen from time to time and in the past Tor Weather really helped get notified.
yes, this is on the radar of the relay advocate - Colin and maybe also the Tor Metrics team to some extend - and they are certainly happy if someone takes this on - especially if you are also considering to maintain this on the long term (the last service has been discontinued to to missing maintainership) you can find more about this on trac and the previous thread: https://lists.torproject.org/pipermail/tor-relays/2018-May/015238.html https://trac.torproject.org/projects/tor/ticket/26124
- *System to provide tor exit node verification*. Given a pre-registered app and callback and a fingerprint of a node it will find the Email of the operator and email a unique link. When that link is clicked a callback will be made to the preregistered URL - allowing a developer to verify that a certain node operator is truely the one accessing the service. That is actually needed for both of the services mentioned above.
This yet another good point and I had that (verified contactInfo) specifically in mind when starting the ContactInfo specification: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification: "provide the foundation for an automated contactInfo verification bot." So if you are going to implement something like that I would be happy to work with you.
- *Simple package to run a webserver + customized tor exit node notice page* - similar to what I configured for http://tor4thepeople1.torexitnode.net. It's very useful and if we can get a super basic web server that only serves this page and would be easy to install (maybe even bundle with Tor) + let's encrypt integration (to serve it under SSL) it would provide great benefit to all operators.
Since this functionality can be done with tor alone (DirPortFrontPage) and additional software (webserver) increases the attack surface I'm more leaning towards not recommending every relay operator to run also a webserver. looking forward to how this progresses! :) thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On Wed, Jun 20, 2018 at 5:21 PM nusenu <nusenu-lists@riseup.net> wrote:
Hi Eran,
a developer offering to help relay operators what better can we ask for :)
Certainly happy to help :-)
yes, this is on the radar of the relay advocate - Colin and maybe also the Tor Metrics team to some extend - and they are certainly happy if someone takes this on - especially if you are also considering to maintain this on the long term (the last service has been discontinued to to missing maintainership)
you can find more about this on trac and the previous thread: https://lists.torproject.org/pipermail/tor-relays/2018-May/015238.html https://trac.torproject.org/projects/tor/ticket/26124
Thanks for the links. I'll review those. I'm more then willing to help and maintain the service. One more feature I was thinking about was callbacks. So I can register for callback on certain things - this allows services to figure out when to stop give access to a certain node if its down.
This yet another good point and I had that (verified contactInfo) specifically in mind when starting the ContactInfo specification:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification: "provide the foundation for an automated contactInfo verification bot."
So if you are going to implement something like that I would be happy to work with you.
Interesting spec. I'll go over it. I think this is the basis for a lot of operator service as this would allow the make sure services are rendered to actual nodes.
Since this functionality can be done with tor alone (DirPortFrontPage) and additional software (webserver) increases the attack surface I'm more leaning towards not recommending every relay operator to run also a webserver.
I understand that but my issues with this feature are: 1. It requires configuration and doesn't come preconfigured. 2. You need to manually edit the HTML to include various information (maybe adding templating support will allow to embed certain ContactInfo inside the page itself when being served). 3. It doesn't support, as far as I can see (maybe I'm missing it) HTTPS support - which I think in this day and age is kinda mandatory. And if we are on the HTTPS bandwagon let's encrypt integration would go a long way.
looking forward to how this progresses! :)
Me too! Eran
Eran Sandler:
I understand that but my issues with this feature are:
1. It requires configuration and doesn't come preconfigured. 2. You need to manually edit the HTML to include various information (maybe adding templating support will allow to embed certain ContactInfo inside the page itself when being served).
1+2 (including template support) are implemented in https://github.com/nusenu/ansible-relayor
3. It doesn't support, as far as I can see (maybe I'm missing it) HTTPS support - which I think in this day and age is kinda mandatory. And if we are on the HTTPS bandwagon let's encrypt integration would go a long way.
Yes DirPort does not speak TLS, but since 443 is also best used for ORPort (because it is often one of the ports that are allowed to pass through firewalls) - https is not possible on the same IP (when already used by the ORPort). -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On Wed, Jun 20, 2018 at 5:52 PM nusenu <nusenu-lists@riseup.net> wrote:
1+2 (including template support) are implemented in https://github.com/nusenu/ansible-relayor
Thanks. I'll take a look.
Yes DirPort does not speak TLS, but since 443 is also best used for ORPort (because it is often one of the ports that are allowed to pass through firewalls) - https is not possible on the same IP (when already used by the ORPort).
Well... that's kind of a hack to handle ORPort going through in various hosting scenarios. I would say it should be used as a last resort and not as the default. I don't know what ORPort most relays use (I guess I can get that from onionoo to some degree) but I do want to hope they are not all riding 443 (I know I don't use 443 for my ORPort on both relays). Eran
Yes DirPort does not speak TLS, but since 443 is also best used for ORPort (because it is often one of the ports that are allowed to pass through firewalls) - https is not possible on the same IP (when already used by the ORPort).
Well... that's kind of a hack to handle ORPort going through in various hosting scenarios.
The ORPort selection is primarily important for the client -> guard connection. For relay <> relay connections firewalls shouldn't matter (that much)
I don't know what ORPort most relays use (I guess I can get that from onionoo to some degree) but I do want to hope they are not all riding 443 (I know I don't use 443 for my ORPort on both relays).
Top 20 ORPorts by relay count: +---------+----------+ | or_port | #relays | +---------+----------+ | 9001 | 3289 | | 443 | 2080 | | 9002 | 67 | | 80 | 62 | | 8443 | 53 | | 8080 | 52 | | 9090 | 35 | | 9100 | 31 | | 110 | 30 | | 444 | 29 | | 21093 | 26 | | 9000 | 22 | | 993 | 22 | | 9003 | 21 | | 21 | 18 | | 9010 | 15 | | 20 | 14 | | 22 | 14 | | 143 | 14 | | 19001 | 13 | +---------+----------+ -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Relays intending to act as Guards choose port 443 because it (and 80) are usually reachable in the tightest of network security situations (where traffic destined for most all other ports is blocked at the gateway/firewall.) At least that's my reasoning for it. On Wed, Jun 20, 2018 at 11:16 AM nusenu <nusenu-lists@riseup.net> wrote:
Yes DirPort does not speak TLS, but since 443 is also best used for ORPort (because it is often one of the ports that are allowed to pass through firewalls) - https is not possible on the same IP (when already used by the ORPort).
Well... that's kind of a hack to handle ORPort going through in various hosting scenarios.
The ORPort selection is primarily important for the client -> guard connection. For relay <> relay connections firewalls shouldn't matter (that much)
I don't know what ORPort most relays use (I guess I can get that from onionoo to some degree) but I do want to hope they are not all riding 443 (I know I don't use 443 for my ORPort on both relays).
Top 20 ORPorts by relay count:
+---------+----------+ | or_port | #relays | +---------+----------+ | 9001 | 3289 | | 443 | 2080 | | 9002 | 67 | | 80 | 62 | | 8443 | 53 | | 8080 | 52 | | 9090 | 35 | | 9100 | 31 | | 110 | 30 | | 444 | 29 | | 21093 | 26 | | 9000 | 22 | | 993 | 22 | | 9003 | 21 | | 21 | 18 | | 9010 | 15 | | 20 | 14 | | 22 | 14 | | 143 | 14 | | 19001 | 13 | +---------+----------+
-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane
On 2018-06-21 08:25, Matthew Glennon wrote:
Relays intending to act as Guards choose port 443 because it (and 80) are usually reachable in the tightest of network security situations (where traffic destined for most all other ports is blocked at the gateway/firewall.) At least that's my reasoning for it.
I run a bridge [1] on other ports (9030 and 9001). How much would it help to move it to port 80? I think at the time I configured it I still had a normal http server on port 80, but this no longer applies. By the way: why can I not see the ports (under OR Addresses) or anything under Transport protocols in the metrics listing? [1] https://metrics.torproject.org/rs.html#details/EEB31B5D6DE98CFA1C3243DA0E7CF... -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
On Thu, Jun 21, 2018 at 4:14 PM Ian Zimmerman <itz@very.loosely.org> wrote:
On 2018-06-21 08:25, Matthew Glennon wrote:
Relays intending to act as Guards choose port 443 because it (and 80) are usually reachable in the tightest of network security situations (where traffic destined for most all other ports is blocked at the gateway/firewall.) At least that's my reasoning for it.
I run a bridge [1] on other ports (9030 and 9001). How much would it help to move it to port 80? I think at the time I configured it I still had a normal http server on port 80, but this no longer applies.
That depends on your target audience. Because you're a Bridge, you need to advertise your entry point in external ways. If the audience you're reaching can't get to you on the ports you choose then considering other ports is an option.
By the way: why can I not see the ports (under OR Addresses) or anything under Transport protocols in the metrics listing?
I believe this is because you're a bridge. The entire point of a Bridge is to be hidden from the censors trying to block entry to the Tor Network, so we don't want to publish that information on Metrics.
[1]
https://metrics.torproject.org/rs.html#details/EEB31B5D6DE98CFA1C3243DA0E7CF...
-- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane
Eran Sandler:
1. It requires configuration and doesn't come preconfigured.
also: if you think DirPort on exits should ship a HTML file by default, we can bring this up with tor developers in a trac ticket. In that case tor should warn (logfiles) if DirPort is not enabled or not on port 80 The biggest problem would probably be: what html would you ship globally by _default_? or should we use the (already available) geoip info to detect in which country the exit is in and display a localized* version accordingly? *) localized: not only language-wise but also legal-wise -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On Wed, Jun 20, 2018 at 6:00 PM nusenu <nusenu-lists@riseup.net> wrote:
Eran Sandler:
1. It requires configuration and doesn't come preconfigured.
also: if you think DirPort on exits should ship a HTML file by default, we can bring this up with tor developers in a trac ticket.
I certainly think it should be added by default.
In that case tor should warn (logfiles) if DirPort is not enabled or not on port 80
The biggest problem would probably be: what html would you ship globally by _default_? or should we use the (already available) geoip info to detect in which country the exit is in and display a localized* version accordingly?
*) localized: not only language-wise but also legal-wise
We can ask the community (or get some friends over at EFF) to help draft something that is legally correct and language relevant (though I don't think that it has to be in the local language for it to be legally binding). Regarding what to display and how, that can be a combination of a few things: 1. Defined country in the config (can be part of the proposed contactinfo spec you mentioned) - so that if there is a way to set it in case geoip DB is not up-to-date with all the various IP addresses migrations that happen 2. GeoIP based on a local DB. That might be great but it would a) increase download size and b) would have to be updated a bit more frequently. It doesn't make too much send to ship a geoip DB just to verify an address once. Another solution would be some kind of a Tor managed or secure server to perform resolution when the relay starts (should have a flag to disable it in the config). That way no logs are saved and we can figured things out in a more accessible manner. Installation would be smaller and that service will always have an up-to-date geoip DB. Eran
Eran Sandler:
I certainly think it should be added by default.
I agree that an html page giving some basic information about tor on every exit relay IP makes sense. If there are no major concerns from other operators to enable this _by default_ I will open a trac ticket to start discussions with the tor developers.
We can ask the community (or get some friends over at EFF) to help draft something that is legally correct and language relevant (though I don't think that it has to be in the local language for it to be legally binding).
Regarding what to display and how, that can be a combination of a few things:
1. Defined country in the config (can be part of the proposed contactinfo spec you mentioned) - so that if there is a way to set it in case geoip DB is not up-to-date with all the various IP addresses migrations that happen 2. GeoIP based on a local DB. That might be great but it would a) increase download size and b) would have to be updated a bit more frequently. It doesn't make too much send to ship a geoip DB just to verify an address once.
in my last email I was referring to the local DB (that is already shipped with tor packages and is based of maxmind's data).
Another solution would be some kind of a Tor managed or secure server to perform resolution when the relay starts (should have a flag to disable it in the config). That way no logs are saved and we can figured things out in a more accessible manner. Installation would be smaller and that service will always have an up-to-date geoip DB.
you might also use RIPEstat APIs for this. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
nusenu wrote:
Eran Sandler:
I certainly think it should be added by default.
I agree that an html page giving some basic information about tor on every exit relay IP makes sense.
If there are no major concerns from other operators to enable this _by default_ I will open a trac ticket to start discussions with the tor developers.
I agree this is a very useful feature, I use it on all exits. But it only makes sense if DirPort is running on port 80, otherwise nobody will just try the IP address with :randomport in their browsers until they see a working web page. Also note that since some time BEGIN_DIR is used, so relays serve directory data via their ORPorts, thus not making DirPort mandatory if you want to serve directory data. The long-term plan is to entirely use ORPort, so relays will need 1 single port to run for both Tor traffic and Tor directory data, making things easier to configure in firewalls, less data in our consensus documents, etc. It will not hurt if a page is added as a default if the relay is Exit and the request is HTTP, display an info web page, but this again will only make sense if ORPort == 80. I think it's simpler if this is pushed to the operator's control, to do it at their own choice. Maybe one wants to run a webserver and show that page, or even more advanced statistics like bw usage, etc. Maybe one wants to add his company banner, or etc. Making this optional and configurable at operator side makes sense, since it's hard to come up with some sane defaults that will just work outside the box for everyone.
I agree this is a very useful feature, I use it on all exits. But it only makes sense if DirPort is running on port 80, otherwise nobody will just try the IP address with :randomport in their browsers until they see a working web page.
this is why I wrote: "In that case tor should warn (logfiles) if DirPort is not enabled or not on port 80"
Also note that since some time BEGIN_DIR is used, so relays serve directory data via their ORPorts, thus not making DirPort mandatory if you want to serve directory data. The long-term plan is to entirely use ORPort, so relays will need 1 single port to run for both Tor traffic and Tor directory data, making things easier to configure in firewalls, less data in our consensus documents, etc.
I hope tor will retain the DirFrontPage functionality past the day where DirPorts are needed - so exit operators don't have to install additional services.
I think it's simpler if this is pushed to the operator's control,
can you elaborate on what you mean with 'simpler' in this context?
to do it at their own choice. Maybe one wants to run a webserver and show that page, or even more advanced statistics like bw usage, etc. Maybe one wants to add his company banner, or etc. Making this optional and configurable at operator side makes sense, since it's hard to come up with some sane defaults that will just work outside the box for everyone.
we are not arguing against keeping things configurable (as they are currently) the suggestion was to change the defaults -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
participants (5)
-
Eran Sandler -
Ian Zimmerman -
Matthew Glennon -
nusenu -
s7r