Add features improving onion services' interaction with Tor.

[moonsikpark]

Tor lacks features allowing onion services' interaction with it, mainly because it is a tunneling protocol, not an application layer protocol. I think this aspect of Tor should be addressed more.

I suggest three directives that can improve onion services' interaction with Tor.

1. HiddenServiceExportRendPoint

With HiddenServiceExportCircuitID and this directive enabled, Tor exports IP and port of rendezvous point, along with the circuit ID, to the onion service. With this, operators can easily aggregate, analyze and monitor their services' rendezvous point connections.

2. HiddenServiceExportInstanceID

With HiddenServiceExportCircuitID and this directive enabled, Tor exports a user-provided instance ID, along with the circuit ID, to the onion service. With this, operators running multiple instances of Tor can accurately differentiate traffics with the same circuit ID. Fixes #32428.

3. HiddenServiceEnableClosingCircuit

This might be controversial because this feature exclusively targets the HTTP application protocol, and I know there are ways to close a circuit using the control protocol. But it's nearly impossible and too much error-prone to implement it in real environments.

With this directive enabled, when onion services' backend returns an HTTP status code of 447, it marks the circuit to be closed. It's lightweight, straightforward and easy to configure.

I've crudely implemented them. Please feel free to leave ideas or comments below.

[moonsikpark]

I've made a pull request. ​https://github.com/torproject/tor/pull/1543

[arma]

There is a patch to look at here

[dgoulet]

Thanks moonsikpark! I hope to provide useful feedback here. I have several questions also. We can move to tor-dev@ at some point if the discussion expands since over a Trac ticket, it can become painful :).

(FYI, the following has been discussed a bit with ahf which implemented the HiddenServiceExportCircuitID feature and had discussions with Cloudflare about it)

1. HiddenServiceExportRendPoint

The reasoning seems reasonable to have this.

2. HiddenServiceExportInstanceID

Same, this also seems reasonable especially if you end up running many onion services.

Both of the above, it would need a bit of tweaking on the patch but that is easy.

3. HiddenServiceEnableClosingCircuit

This one is a bit more controversial. We are unsure if _in_ tor is the right place to parse every single payload coming in from a client.

The right place to do such an action is really through the ControlPort but you mention that it seems complicated and error-prone on your side. If you could expand there so we can maybe try to make it better?

Another option that ahf raised is that probably a sort of "tor agent" would be more desirable that is you would tell the agent on a socket to "terminate circuit <ID>" and then it tells tor. That agent can aggregate multiple tor instances if needed, and so on.

Unfortunately, we don't have such an "agent" but making tor do "payload inspection" for specific behaviors is not really what we think should be done here.

We would _really_ love for you to expand on your needs and complications you had with the control port + CLOSECIRCUIT.

[asn]

OK now this is splitted into two tickets. This ticket is for the third controversial ticket, and #32604 is for the other two.

[asn]

I have made a [tor-dev] thread about the third feature as I'd like to see progress here ASAP: ​https://lists.torproject.org/pipermail/tor-dev/2019-December/014097.html

Nick asked a good question that would be great to have answers to. moonsikpark or anyone else please chime in if you have feedback :)