tor for static

added 1 commit

9a5d18e3 - Bug: fix hidden service for static

This looks good, it needs to be rebased off of master before it can be merged (gitlab says it is 5 commits behind now).

closed

reopened

I know this has been merged, and I said it looks good, but I've discovered that it is wrong.

First some clarification: Nodes with the service 'tor' create a relay on the node with some default configuration (bandwidth_rate, contacts, nickname and family). If the node has service webapp, it will also enable the webapp and the API to be available over a tor hidden service.

However, it is desirable to have a hidden service available for static/webapp nodes, without the node also being a relay. When a node is configured as a relay, it is listed in the tor consensus, and automatically added to various RBLs that list all tor relays. For riseup, this ended up being a problem, because we are using leap to manage the static https://riseup.net, with a hidden service, and because the relay also got enabled, it got all of riseup.net listed in RBLs.

Also, it is not considered secure to have a node configured as a relay and a hidden service at the same time (see https://trac.torproject.org/8742)

Previous to this commit, a hidden service can be enabled on a node for a static/webapp site+API, without the 'tor' service added to a node.

This means the entire tor configuration is confusing, and should be overhauled so it is more straight forward. I propose that we do the following:

next release: refactor the "tor" service by replacing it with "tor_relay", "tor_exit" and "tor_hidden_service"
next release: leap cli should error out if you try to enable both the relay and the hidden service
this release: revert this commit, this will allow hidden services to be configured without a relay being enabled. It is somewhat opaque because you should not have the service 'tor' defined for such a node, so we would clarify the documentation for the tor service to be as follows (compare with: https://leap.se/en/docs/platform/services/tor:

Topology
------------------------

Nodes with `tor` service will run a Tor relay with some pre-defined settings, which can be changed with some configuration (see *Configuration* below). You can enable an exit or a hidden service with additional configuration.

Configuration
------------------------------

By default, if a node has service 'tor' configured, it will run a tor relay (not an exit). The relay will be configured with bandwidth limitations, contacts, a nickname and a family. The defaults for these (shown below), can be overridden as desired.

* `tor.bandwidth_rate`: the max bandwidth allocated to Tor, in KB per second, when used as an exit node (default: 6550 KB/sec).
* `tor.type`: what type of tor node to make, at this moment only 'exit' is supported. If not specified, acts as a relay.
* `tor.contacts`: the contact information for the relay (default: the list of provider contacts)
* `tor.nickname`: the nickname of the relay (default: a combination of the node name and a hash of the family)
* `tor.family`: a list of the other nicknames that are part of the same provider
* `tor.hidden_service`: to enable a hidden service, set 'active' to be true (see below for an example), do *not* configure "services": ["tor"] for the node!

Examples:

To add a relay to a node:

    { 
     "services": ["tor"]
    }
    
To enable a hidden service, without a relay, do *not* specify the tor service (it is not considered secure to have a node configured as a relay and a hidden service at the same time, see: https://trac.torproject.org/8742), instead configure the node to have the following: 

    {
      "tor": {
        "hidden_service": {
        "active": true
      }
    }

If activated, you can list the hidden service .onion addresses this way:

   leap ls --print tor.hidden_service.address tor

Then just add '.onion' to the end of the printed addresses.

To enable a Tor exit node:

    {
      "tor": {
        "bandwidth_rate": 6550,
        "type": "exit"
      }
    }

i agree that this configuration confusion has always been a problem. i didn't think this MR would start an exit because it doesn't touch any of the exit code. All it does is fix the hidden service code, which was broken and non-functional.

so, it must be that the part that sets up an exit node is the broken part, and that should be fixed with an additional MR, not reverting this one.

i propose that we create three service tags: tor-exit, tor-relay, and onion

for now, we can just ignore tor-relay

I'm confused about the current state of this MR. It's unassigned, merged, still open - now what ?

closed

reopened

@varac this MR was merged, and then I determined it was not right, and should be reverted, so I re-opened this MR

@elijah I did not say that this MR starts an exit. What this MR does is make it so it is impossible to have a hidden service on the node without it also being a relay. That is undesirable for the reasons stated above.

closed

@elijah - ?

@micah that is not what this MR does. It just fixes hidden service. The problem with it being an exit is elsewhere. This change should NOT be rolled back.

The problem is with single hop onion service, not an exit node per se. Single hop makes the node public, which is cool and it should be ok but there is the .tor.dan.me.uk list, which lists tor relays. A relay shouldn't be a problem, but they are becoming every day more commonly blocked because of different worm attacks and that specific list has already been used against riseup (even if it's not an mx, they just block *.riseup.net).

How others are viewing Tor nodes is not something we can control, neither they are correct to block *.riseup.net because a webpage offers a single hop onion service... but the situation is today a little complicated and I really would like to not promote a static website as single hop to reduce this harm. People can wait a couple of seconds more (in worse case) and we can keep delivering e-mail.

mentioned in issue #8864 (closed)

tor for static

Merge request reports

Activity