Anonymous Homeservers (Tor/I2P)

[jakehemmerle]

Intro

Several people in the Matrix community, including myself, would love to see anonymous homeservers. It didn't seem appropriate to use either of the other I2P or Tor threads, since both had some awesome points by awesome people (looking at you @richvdh @cyphar @vsatmydynipnet @Ekleog @ara4n). Big thanks to @ara4n for giving this a proofread before I posted!

Why this Tor/I2P thread

It seemed appropriate to start a new thread (and lock) for the following reasons and with the following hopes:

1. Create a central thread for the discussion of Tor/I2P homeservers and DNS-addressed homeservers that federate to Tor/I2P homeservers, merging the I2P homeserver thread [Feature] Support i2p #5455 with the two Tor homeserver threads Support routing .onion traffic over tor #5152 and Support Tor-hidden homeservers #2111 (as each thread contained at least some useful and non-duplicate information that I have tried to consolidate in this post). Both protocols could theoretically be implemented, but for the sake of anonymous homeservers, we should just pick one.
2. Come to a community decision about which anonymity network to use for homeservers and for what reasons
3. Create a roadmap and/or tickets that I and other community members can start working on

Since this is a large post on a new thread that discusses several steps that are dependent on the previous, for the sake of organization it will probably make sense to break this into smaller threads over time, rename threads, and/or move stuff to a wiki or something.

Tor or I2P?

Here is an excellent and pretty unbiased post comparing Tor and I2P from I2P’s website: https://geti2p.net/en/comparison/tor

(Summarized from above link):

Benefits of Tor over I2P

• Bigger user base, significant funding
• Has already addressed some scaling issues I2P has yet to address
• More resistant to state-level blocking due to Pluggable Transports
• More efficient memory usage
• Tor client nodes have very low bandwidth overhead
• SOCKS is (probably) easier to build with than I2P's API
• Designed and optimized for exit traffic, with a large number of exit nodes (possibly faster to federate to DNS-addressed HSs)
  Written in C, while I2P is Java (EDIT: I found a C++ implementation of I2P (https://github.com/PurpleI2P/i2pd))

Benefits of I2P over Tor

• Designed and optimized for hidden services, which are much faster than Tor (how much faster?)
• UDP support instead of just TCP (QUIC, CoAP)
  • Although I don't expect there to be many audio/video transmissions from anonymous Matrix users, receiving them could be nice).
  • Could we see coap-proxy get some love here? How much slower would it be with TCP as transport?
• I2P's APIs are designed specifically for anonymity and security, while SOCKS is designed for functionality.
• Fully distributed and self organizing nodes
• P2P friendly
• Packet switched instead of circuit switched

I am no expert in network protocols and I don't want to provide an ill-equip opinion, but it seems that Tor HSs would be easier to implement, while I2P HSs appear more 'proper'.

UX and Federation Behavior

I thought it would be useful to include expected behavior in this discussion. This and everything below this will be split into a separate thread with more details after decision on Tor or I2P.

UX (Client)

In a perfect world, I would think we would want the following behavior to apply (I will use terms 'Tor/I2P HSs' and 'DNS-addressed HSs' to describe homeservers that end in .onion/.i2p and in .com/etc for lack of better terminology):

1. Tor/I2P HSs and DNS-addressed HSs should be able to participate in the same rooms and federate to each other (I can ping @matthew:matrix.org and @somefella:sdfasdfdfd.i2p/.onion in the same message without having to do anything special).

Behind the scenes (Server)

1. Having a HS that does not support federating to Tor/I2P HSs should not break anything.
   • How would we handle legacy HSs that don't support specifying a Tor/I2P client? Would adding a bridge to the room solve catching Tor/I2P servers up or would it be cleaner to do a breaking server update during a big release? interesting comment related to this by @OlegGirko on Homeservers don't catch up with missed traffic until someone sends another event #2528 )
2. In a perfect world, we would have every HS running a Tor/I2P client, providing native federation to all HS types. I don't think this should be a requirement as this will probably induce non-insignificant overhead, but we should include a server config entry to just specify an external relay (ie IP/port of a Tor SOCKS5 proxy). Maybe include native Tor/I2P client in the stable Dendrite release? Food for thought, I'm just dreaming here.
3. Tor/I2P HSs would have to route all their requests through Tor/I2P while DNS-addressed HSs would split where they route outgoing packets.

@richvdh in #2111 recognized that for both types of HSs to federate to each other, it may be easiest to propose a change to the Matrix specification (specifically 'raising an MSC in the matrix-doc'). See post for context.

Depending on the expected future support of Synapse and with the building of Dendrite, would it make sense to skip building this for Synapse and just implement this for Dendrite?

Next steps

I hope this post finds the community well and brings some organization to the awesome discussions started around Tor/I2P homeservers. What should we start with? Tor or I2P?

[jakehemmerle]

It seems like the best way to not lock specifically into Tor or I2P would be to have some sort of low level Network API that specifies config, transport and authentication for federation. This interface would allow support for Tor, I2P, DNS or any other homeserver type and prevent the need to rewrite the spec to add support for a new homeserver type.

I will try to dive deeper into this and start a spec proposal mid May (Working part time and taking a full load of classes has my hands full until then).

[dr-bonez]

@jakehemmerle thanks for being on top of this. I'm personally invested in adding Tor support, since hidden services solve an addressability problem for people who want to run servers behind a NAT.
I agree that having a more modular transport layer for the application would be the best way to do this. This way the main code base shouldn't have to care about how services are being hosted, it should be able to deal exclusively in URLs.

That said, I would recommend prioritizing Tor over I2P when it comes to implementation as Tor has better ecosystem support. Based on my own experience, I have found that integrating Tor is easier than I2P and tends to be more reliable. It may also be worth noting that, as far as I'm aware, there is no I2P browser available for iOS. Additionally, there is a plugin being developed for Ionic Capacitor that will allow adding Tor support to both Android and iOS applications very easily, which will likely be finished in the coming weeks.

Those are my thoughts on the matter. Happy to lend help wherever needed.

[vsatmydynipnet]

This would finally open Matrix/Synapse to everybody and removes the NAT/dynamic IP problem:

#5152

[cyphar]

My one concern is that we need to make sure that .onion homeservers are absolutely forbidden from connecting to anything over the clear-net. This is the biggest issue with hosting an .onion service -- everything from nginx and Apache to PHP and Django seem giddy about disclosing your public IP address.

Another thing I'm a little worried about is while it is necessary to route .onion-bound packets through other servers if you don't have a Tor client locally, it does mean that every homeserver along the chain knows who you're talking to. Then again, this might not be a problem if the routing for messages in a given room only happens within the set of servers that are involved in that room.

[dr-bonez]

I mean it should be configurable. Connecting to another server over clearnet only harms your own anonymity, not anyone else's. So if you're using Tor for NAT punching but not anonymity, you could use the proxy for hidden services only. But I agree that by default it should use the proxy for everything.

As for the second point, long term we could bundle a Tor client, and only run it if we don't detect anything listening on 127.0.0.1:9050. Remote Tor proxies should be an advanced configuration option, you need to know what you're doing if you use one.

[jakehemmerle]

while it is necessary to route .onion-bound packets through other servers if you don't have a Tor client locally, it does mean that every homeserver along the chain knows who you're talking to

@cyphar If I understand your statement correctly, why would it matter if another server (who/whatever is hosting the Tor SOCKS5) can see the data going to the onion .onion homeserver, if all that's in there is the .onion address? I don't see any sort of malicious stuff that could happen other than the hoster of the SOCKS5 intentionally dropping packets.

My one concern is that we need to make sure that .onion homeservers are absolutely forbidden from connecting to anything over the clear-net. This is the biggest issue with hosting an .onion service -- everything from nginx and Apache to PHP and Django seem giddy about disclosing your public IP address.

It might be worth 'highly recommending' that people running .onion homeservers host their server via Docker by simply spinning up a hardened 'official' docker-compose.yaml file instead of configuring nginx and Tor themselves. That would make it even easier to pass in fun things like custom .onion addresses via Shallot or something

[dr-bonez]

shallot is v2, so probably should use https://github.com/cathugger/mkp224o instead

[cyphar]

@jakehemmerle

If I understand your statement correctly, why would it matter if another server (who/whatever is hosting the Tor SOCKS5) can see the data going to the onion .onion homeserver, if all that's in there is the .onion address? I don't see any sort of malicious stuff that could happen other than the hoster of the SOCKS5 intentionally dropping packets.

It makes it so the relaying server is aware of the social graph of people talking. For instance, knowing that user @a:abc.onion and @b:b.com are speaking together (or @b:b.com is speaking in !foobar:abc.onion) may betray some sensitive information. Even the knowledge that @b:b.com is speaking to someone on abc.onion might be a problem if abc.onion is (for instance) a server for HIV-positive users or whistleblowers or pick-your-own-vulnerable-group. This is information that would not be known by anyone not in the room if b.com routes through Tor.

Leaking such information does defeat some of the anonymity properties of .onion addresses. If you compare this to other chat systems built on top of .onion addresses (such as the sadly dead Ricochet), they specifically protect against social graph building through the use of .onion addresses. Obviously Matrix will probably never be as privacy-preserving as tools like Ricochet but we should still make an effort.

My point is that if we're going to do clear-net packet routing to people who are on .onion servers or for conversations in .onion rooms, it must be done by routing through homeservers that are currently involved in the room the message was sent in. At the very least this reduces the scope of the information leak.

It might be worth 'highly recommending' that people running .onion homeservers host their server via Docker by simply spinning up a hardened 'official' docker-compose.yaml file instead of configuring nginx and Tor themselves.

Sure, though I imagine a lot of the work would also involve making sure that Twisted doesn't leak such information. Docker doesn't solve all of your problems (how do you make sure you don't leak information about the host system over the internet, and so on). Don't get me wrong, these are all stretch goals but are things that should be kept in mind if the intention is to get people to host .onion homeservers for privacy-preserving reasons. If the intention is just to get around NAT, then it's a different story.

[jakehemmerle]

Even the knowledge that @b:b.com is speaking to someone on abc.onion might be a problem if abc.onion is (for instance) a server for HIV-positive users or whistleblowers or pick-your-own-vulnerable-group.

I don’t think that matters (or rather, it matters much less) that it is known that someone on a clear-net homeserver is speaking to an onion homeserver (even though you can make associations like you described above). If a user ranks anonymity as a high priority for them, they should use an onion homeserver anyway (or at the very least, a clear-net homeserver through Tor, but still opens up that clearnet server to censorship or targeted attacks).

An onion homeserver should simply provide anonymity to its users, not necessarily to clearnet servers/users in a room it’s hosting. If we want more privacy from clear to onion (or even clear to clear), that should be a separate proposal (although related).

I imagine a lot of the work would also involve making sure that Twisted doesn't leak such information. Docker doesn't solve all of your problems (how do you make sure you don't leak information about the host system over the internet, and so on).

A crafted docker-compose file would eliminate/reduce the issue of a misconfigured or information-exposing service like nginx as well as Twisted reducing privacy. Docker itself doesn’t inherently remove these issues, and Twisted under the hood may want to expose things, but forcing a container (Synapse) to route all traffic through another container (a router configured to route all traffic through Tor) does.

[jakehemmerle]

Docker doesn't solve all of your problems (how do you make sure you don't leak information about the host system over the internet, and so on).

Rereading this a few months later I realize I misunderstood what you were saying! I'm not sure if theres a way to completely eliminate this issue at the docker level. Someone who knows docker and security pretty well would have to answer that.

[jakehemmerle]

https://www.ndss-symposium.org/wp-content/uploads/2020/02/24199-paper.pdf

Stuff like 0-RTT TLS, TCP fast open, and (if going the I2P route) QUIC should speed up some of the loading time. I expect this to be pretty slow trying to federate everything, but I could be wrong. Anyway, this paper might come in handy at some point.

[hstock]

Support for ENS domains (https://ens.domains/) and/or unstoppable domains (https://unstoppabledomains.com/) could be interesting. This would allow decoupling of anonymous domains and the type of anonymizing technology used. (if for example Tor and I2P are implemented in the future)