config support for running a tor hidden service

[slingamn]

1. Designate one (or more) of the listen addresses as a tor address; anything coming in on that address will be treated as a tor connection. (Config syntax could be similar to the current designation of listen addresses as TLS.) This address then becomes the target of the torrc HiddenServicePort directive.
2. PROXY and WEBIRC are not accepted for connections on this address, even if they would otherwise be, e.g., if localhost is in proxy-allowed-from and the tor listen address is loopback or unix domain
3. These connections are assigned a fictional hostmask (tor-hidden-service.onion, but it should be configurable obviously); client.IP() can return 127.0.0.1 though
4. There is a configurable limit for the number of concurrent Tor connections (also maybe throttling? to what extent can we reuse the regular limiter/throttler?)

[slingamn]

Any tor connection is end-to-end encrypted, so it gets the TLS flag (so it can resume), the +Z mode, etc.

[csmith]

It'd be good if you could optionally require SASL auth from tor users so it's still possible to ban an individual user (which is the behaviour freenode has at the minute).

[DanielOaks]

Ah, so this idea is really interesting, but I'm not sure of exactly the right way to do it.

So I'd be fully up for this. Given that it's an idea that very inherently touches on security though, I need to be really sure that we're doing everything correctly for a tor hidden service IRC server to be secure.

For example, having a description in the manual and/or config file of exactly how to set this up, to disable DNS/ident lookups, or whatever else could possibly be used to identify the server host (or to do that automagically for connections that are using Tor). Gonna be a lil paranoid about the implementation of this.

[slingamn]

Yeah, totally. So:

1. My primary use case for this is adding an .onion address to a server whose address is public (same as what Freenode does). This is discussed a bit here: host a .onion site for darwin dot irc dot network darwin-network/slash#11
2. We should definitely provide some code support or advice for preventing deanonymization attacks against Oragono running as a truly hidden service (the DNS and ident issue are good catches), but overall I think the potential attack surface is huge and given the amount of code churn, we can't hope to catch every possible issue. I think we should advise people who are running true hidden services to put Oragono in some kind of jail, e.g., an isolated network namespace with no direct network connectivity (and then the Tor daemon connects to it via unix domain socket).

[DanielOaks]

Sounds good, I'd be up for something like that for sure.

[slingamn]

Might also want to watch out for potential deanonymization of end users via the CTCP (I don't know too much about how that works).

[DanielOaks]

Aha, hahaha, aha. Oh yes that is definitely an issue. A very interesting issue. Note to self: maybe doing a CTCP token check on join and sending a note to those who do have DCC available would be a good thing.

[slingamn]

Thoughts on just blocking delivery of CTCP privmsgs (anything starting with \001?) to Tor clients?

[slingamn]

Correction: I want to block everything except ACTION.

[slingamn]

Fixed in #430