892703 - Add Tor "hidden services" listener for Mozilla's IRC servers

Status: RESOLVED WONTFIX

(Infrastructure & Operations Graveyard :: Infrastructure: IRC, task)

Description

[Dave Huseby [:huseby]]

Currently Mozilla's IRC servers use the EFNet RB list to block abusive IRC clients.  It turns out that most abusive IRC clients use Tor to hide their origin IP and thus, legitimate Tor access to our servers is routinely blocked.

Freenode and OFTC have enabled Tor access to their IRC network using Tor hidden services.  By using a hidden service, SASL auth, and requiring a registered nick, they have struck a usable balance between anonymity and accountability.

Can we set up a hidden service for the mozilla IRC network?  The Unreal IRC server we use already has support for SASL auth and we have a nickserv running too.

To set up a hidden service, following these instructions: https://www.torproject.org/docs/tor-hidden-service.html.en  Instead of pointing it at a web server, point it at our IRC servers.

Then we need to update this wiki page: https://wiki.mozilla.org/IRC so that it has a section about accessing our IRC server over Tor.  We can use Freenode's section as an example: http://freenode.net/irc_servers.shtml#tor

Both freedone and oftc turn on cloaking (user mode +x) by default for clients connecting through the hidden service.  Mozilla's Unreal IRC server supports cloaking: http://www.unrealircd.com/files/docs/unreal32docs.html#feature_cloaking

Comment 1

[Justin Dow [:jabba]]

CC'ing some ircops and opsec people for an opinion and further direction here.

Comment 2

[Joe Stevensen [:joe]]

What value does Mozilla gain by allowing abusive hosts that would otherwise be blocked?

From the EFNET RBL page:

The collected sources are as follows:
* Scanned open proxies by the EFnet Open Proxy Monitors
* Spamtrap hosts with scores of 666 (known self spreading virii and trojans)
* Spamtrap hosts with scores of 50 or more (virii and trojans known to self-spread)
* Scanned TOR exit node proxies
* Other unsavory types, manually added by trusted admins (don't use this if you don't trust us), or automatically added by drone detection patterns

These are good things to block, IMO.

Comment 3

[:Atoll]

If our IRC server permitted us to configure a new SSL TCP port that required any of:

- SSL client certificate verification
- NickServ or LDAP authorization (at the IRC connect phase)
- NickServ authentication (before permitting any /JOIN, /MSG, /NOTICE, etc)

Then we would have the ability to restrict TOR clients to authorized, identifiable (to us) users. Authenticated untraceable users are less of a concern than anonymous ones.

Comment 4

[Dave Miller [:justdave]]

We do have a separate blocklist for TOR exit nodes configured.  It's normally disabled, but we've been known to temporarily enable it when actively under attack by someone that appears to be using TOR for ban evasion.

So the EFNet list includes TOR exit nodes now?  Might need to re-think our use of it then.  Our intention has always been to permit TOR except when it's actively being used for abuse as mentioned above.

Comment 5

[:Atoll]

Someone points out that this request was about running an IRC listener on a .onion address. If we did that, we would still be accepting TOR connections, only they wouldn't have to use an exit node to do so. This doesn't require us to become a TOR relay, so that's a plus, and if we're being attacked by someone using TOR for exit evasion, we would be need to block both exit nodes *and* the .onion listener simultaneously.

Comment 6

[Justin Dow [:jabba]]

I don't know much about TOR or what possible implications implementing this might bring. I also don't know what would be involved from our end to set this up. I'm needinfo'ing :joes for an official "do it" or "don't do it" decision from OpSec and then I'll need some info on what all is involved in order to determine both initial time/resources that would be involved in this, as well how it would be managed/maintained. Also some more input from some of the ircopers would be good on whether this is something that we want on our network, as our network is for community/collaboration first and foremost and not so much for anonymity. Once all this information is present, we can look at what kind of timeline we could expect for this, if we decide to implement it.

Comment 7

[Dave Huseby [:huseby]]

(In reply to Dave Huseby [:huseby] from comment #0)
> Freenode and OFTC have enabled Tor access to their IRC network using Tor
> hidden services.  By using a hidden service, SASL auth, and requiring a
> registered nick, they have struck a usable balance between anonymity and
> accountability.

I just want to point out what I said in the original comment.  I'm not asking for anonymous hidden service access.  I think requiring SASL auth and a registered nick is an appropriate expectation.  What that gives me is the ability to log in, but still hide the source of my traffic.  It protects me from other users seeing where I'm located and potentially attacking my machine.

Comment 8

[Shyam Mani [:fox2mike]]

(In reply to Dave Huseby [:huseby] from comment #7)

> a registered nick is an appropriate expectation.  What that gives me is the
> ability to log in, but still hide the source of my traffic.  It protects me
> from other users seeing where I'm located and potentially attacking my
> machine.

This is already provided today by UnrealIRCd. No other normal user sees your real IP address.

Comment 9

[Joe Stevensen [:joe]]

Looks like this problem is solved, according to comment 8.

Comment 10

[:Atoll]

(In reply to Dave Huseby [:huseby] from comment #7)
> I just want to point out what I said in the original comment.  I'm not
> asking for anonymous hidden service access.  I think requiring SASL auth and
> a registered nick is an appropriate expectation.  What that gives me is the
> ability to log in, but still hide the source of my traffic.  It protects me
> from other users seeing where I'm located and potentially attacking my
> machine.

To clarify:

Are you trying to hide the source of your traffic from other users on the Mozilla network (either partially, with wildcard *.domain cloaking, or entirely, with a custom 'your.custom.here' cloak)?

As noted above, we already offer partial cloaking by default (umode +x), and we have custom cloaks available for users who require full cloaking. So if that's sufficient to provide you the anonymity desired, then an ircop can set you up with whatever you need and some basic instructions for activating/deactivating it as desired.


Or, are you trying to hide the source of your traffic from any of the network carriers between your endpoint and our IRC server?

In this case, cloaking is of no use whatsoever, since your internet provider, and our internet provider(s), and anyone in between, will know with certainty that your IRC connection exists (though presumably you're using SSL, so it will be encrypted).


I can't discern which of these fits your request, so setting needinfo? to request clarification.

Comment 11

[Dave Huseby [:huseby]]

My official use case is: I'm a private citizen.  :)

I use Tor to anonymize all of my traffic on principle.  I just want to be able to use Tor with the Mozilla IRC server too.  As it stands now, Mozilla's IRC server is the only one I have to drop my shields for.  It's not 100%.  Some days it works.  Other days it doesn't.

Comment 12

[:Atoll]

Okay, so cloaking won't be sufficient for this request. Retitling slightly and thank you for clarifying, Dave!

Restated summary: Add a Tor "hidden service" endpoint that connects to Mozilla's IRC network. It may, if we choose, require authentication somehow.

Comment 13

[Michael Henry [:tinfoil]]

Being the devil's advocate -- Is it possible to create an authentication system for blacklisted IP's?  ie - You're blacklisted, auth to continue or go away; either that or a separate listening port that is 100% auth.  Possibly tied to ldap?

We're an organization that strives to protect privacy.  We should allow team and community who use such methods to continue to use them while still being able to limit abuse.  Otherwise we're penalizing community members who are doing what we advocate.  Setting up such an authenticating gate system could help with that.  This would allow someone to keep their source private, but still identify with us who they are.

On that note, as opsec I could not support a hidden service unless it had authentication, for the same reasons.  We would have no way to control it otherwise, except through obscurity.

...

On the flip side, how many people would benefit from this and how much would would go into it.  If it's easy, lets do it.  It not, how many people would benefit?

Comment 14

[:Atoll]

It's a Tor endpoint hosted *inside* the Tor network, so we can't blacklist IPs, because we literally have no source to block.

Comment 15

[Dave Huseby [:huseby]]

There's two different things we're talking about:
1. Exposing the Mozilla IRC as a hidden service in the Tor network.
2. Providing some way for Tor users to access the public IP's of the Mozilla IRC servers.

With #1, that would be ideal.  Mozilla can continue to use EFNet's black list as-is but still allow Tor access.  I think, as a compromise, it would probably be best if we only accepted LDAP authenticated clients over the hidden service.

With #2, things are more difficult.  Tor exit nodes show up in EFNet's black list all the time.  That's the problem I'm running into now.  If I use Tor to log in, I can only get in about 30% of the time.  Most days, the Mozilla IRC server kicks me because my Tor exit node IP is banned.

I still think we should pursue this issue.  Tor is still the only real choice for people who want to live a private online life.  IMO, Mozilla should be out in front of this.

Comment 16

[Dave Huseby [:huseby]]

I'm of the opinion that if we build this, people will use it.  It isn't hard to set up a hidden service.  When setting it up you can specify the IP:PORT that hidden service connections get relayed to.  Setting up an IP:PORT that requires LDAP authentication would be the hard part.

Comment 17

[Chip]

(In reply to Dave Huseby [:huseby] from comment #16)
> I'm of the opinion that if we build this, people will use it.  It isn't hard
> to set up a hidden service.  When setting it up you can specify the IP:PORT
> that hidden service connections get relayed to.  Setting up an IP:PORT that
> requires LDAP authentication would be the hard part.

Several IRC networks have hidden services. When connecting through the hidden service, you'll be assigned a Tor 'cloak'.
In the case of Freenode: gateway/tor-sasl/<username>

Some other IRC networks don't have hidden services, but listen for connections from Tor nodes and assign cloaks based on the IP you connect from:
In the case of OFTC: <random connection ID>.tor-irc.dnsbl.oftc.net

Freenode's method is far nicer, blocking connections from Tor to the normal 'clearnet' addresses (irc.freenode.net) but allowing them only from the .onion addresses.

I'd like Mozilla to employ the same method as Freenode, in my opinion it's the most secure+safe way of handling Tor traffic.

Comment 18

[Joe Stevensen [:joe]]

I don't have an issue with doing this or with not doing this.

Comment 19

[Dave Huseby [:huseby]]

So Facebook just enabled access to their site via a Tor hidden service.  Can we set up a freenode-like access system for irc.mozilla.org now?

Comment 20

[nicoo]

Comment from the peanut gallery:
Assuming you will want to mandate user authentication (using SASL?) to limit the possibility of abuse, it would probably be easier to setup the IRC servers so that authenticated users are not subjected to blacklists.

Comment 21

[nicoo]

PS: To force SASL on a hidden service, the connect blocks for InspIRCd look like this:
> <connect name="tor-preSASL"
>          usednsbl="no"
>          allow="<Tor instance's IP>"
>          [usual parameters for your network]
>          registered="false"
>          requireaccount="no">
> 
> <connect name="tor-SASL"
>          usednsbl="no"
>          allow="<Tor instance's IP>"
>          [Usual parameters]
>          registered="true"
>          requireaccount="yes">

Comment 22

[Dave Huseby [:huseby]]

There's also TLS cert concerns.  Facebook had to go through some extra steps to get a cert that worked with their .onion address.

Comment 23

[:Atoll]

:cshields, we have technical ability to proceed with implementation here, once time is available to do so.

Comment 24

[nicoo]

:huseby, TLS is not required on a hidden service, as the .onion address is already supposedly hard to forge.
However, using TLS would make that authentication safer (Tor's HSv1 still uses 1024bit RSA identity keys), and possibly client authentication by certificate (using SASL EXTERNAL, if supported).

Expecting Tor users to make their IRC client use a specific CA and/or pin the certificate doesn't seem an unreasonable burden, though, if acquiring a certificate for a .onion proves to be to hard/lengthy.

Comment 25

[:Atoll]

TLS must be supported on the hidden service (and, likely, required) due to SASL - but also because the IRC server itself enforces a mandatory "TLS required" bit on various channels.

Comment 26

[Chip]

For the short term, a self-signed cert could be used. We can safely assume if Mozilla IRC users are going to use Tor, they would be willing to take an extra step to install the client CA.

Comment 27

[Corey Shields [:cshields]]

I'm not too keen on increasing the support of tor use on our irc network when so many of our problems (spammers, abuse reports) come from tor users as it is today.

Is there a business justification for this documented somewhere?

Comment 28

[Dave Huseby [:huseby]]

Corey, in the case of IRC, I'm not arguing for anonymous access to our IRC.  I think a reasonable compromise is that Tor users are allowed to access the IRC server as long as they do SASL authentication.  The .onion access will allow people to access our IRC server in regions of the world where censorship is the norm.

The compelling reason to deploy and maintain .onion access to our web properties has to with how the Tor network is organized.  Exit nodes in the Tor network are the primary bottleneck in terms of bandwidth.  If we provide .onion access, then accessing our web properties anonymously over the Tor network will not consume any of the bandwidth of the exit nodes.

Comment 29

[Corey Shields [:cshields]]

We won't be resourcing any tor connectivity in IT-managed services so I'm going to close this out.