Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anonymous homeservers (Tor/I2P support): Modifying the federation system #1277

Open
ghost opened this issue Oct 7, 2022 · 8 comments
Open
Labels
A-S2S Server-to-Server API (federation) improvement An idea/future MSC for the spec

Comments

@ghost
Copy link

ghost commented Oct 7, 2022

Suggestion
What would you like to see in Matrix? If your idea is vaguely complete enough, we
recommend submitting an MSC instead.

To accomplish this, the federation system would need to be modified, we probably also want to do this in a way that the Matrix homeserver doesn't need a Tor/I2P proxy running (because not everyone would be comfortable with that).
In that case, the connection from Tor to Matrix (clearnet) is only possible on reverse (Tor to Matrix clearnet works) (Matrix clearnet to Tor doesn't work).

Possible ideas:

Related non-duplicate issues:

@ghost ghost added the improvement An idea/future MSC for the spec label Oct 7, 2022
@ghost ghost changed the title Anonymous homeservers (Tor/I2P support) Anonymous homeservers (Tor/I2P support): Modifying the federation system Oct 7, 2022
@turt2live turt2live added the A-S2S Server-to-Server API (federation) label Oct 13, 2022
@m00nwtchr
Copy link

m00nwtchr commented Dec 27, 2022

You don't need a separate mechanism for keeping track of known Matrix servers, since you can just have the user input the url to the matrix homeserver they want to connect to, e.g. matrix.org and then get more homeservers from the member list of the rooms they join. (Basically how it already works)

@walksanatora
Copy link

support for Tor/I2P homeservers would be perfect for people who do not want to/can not buy a domain
although mentioning them would be annoying since Tor urls are long

@oscar230
Copy link

oscar230 commented Apr 5, 2023

Thanks for raising this issue. 😍 I would also like to see this implemented, does anyone know the status of the Tor-support issue? Is this planned?

@ghost
Copy link

ghost commented May 2, 2023

Since it already works as-is in my PoC (matrix-org/synapse#5152 (comment)), I don't think the federation system needs bigger changes. Make note that federations need to work in both directions in any use case, so no tricky workarounds can exist over simply enabling Synapse to integrate automatically with existing Tor SOCKS, DNS and non-SSL instances as I suggested in my editorial. Concluding, you may wish to close this ticket now.

@Sazu-bit
Copy link

Sazu-bit commented May 7, 2023

I think it's worth waiting until a more workable solution is found. As you pointed out yourself, you disabled a few security features to get it to work.

@ghost
Copy link

ghost commented May 7, 2023

Security is a process, not a feature. In this case, as TOR uses its own domain name system, the following question arises:

Why would an .onion site need a TLS certificate? This is a great question. Especially because .onion services provide pretty much the same protections offered by an HTTPS connection regarding protecting the data in transit from man in the middle attacks and validating that the user is indeed connecting the server the domain in the browser bar is requesting. Onion services do the same thing, so why would an .onion site need a TLS certificate?

As such, I don't see anything wrong in disabling SSL for onion<->onion federations. The only issue is that if such a homeserver also handles clearnet connections, impairing certificate checks for those may hurt. This is fixable by recognizing .onion hostnames and simply doing what I did with those only. Which means we only need a few steps forward (a small grep, a small if), not many steps backwards or waiting for another year or so.

@nihilist001
Copy link

nihilist001 commented Jul 29, 2024

Moving it here from element-hq/synapse#7088 as apparently the synapse devs can't do anything about it since it requires some actual protocol changes:

to whoever that wants to work on this : add .onion support for matrix servers to federate as an opt-in feature, no need for i2p (userbase is too small)

i'll pay whoever successfully implements this in matrix protocol + synapse server and merges it with 5 Monero (XMR) (meaning 750 euros)

take the usecase where i have a matrix server at home, at whateverlink.onion with port 8448 ONLY accessible over the onion link through tor alone, and with just that it needs to be able to federate to other servers, and over tor.

exactly what was described above :

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.onion in the same message without having to do anything special).

Point is, i shouldnt have to pay for a VPS, and a domain with port 8448 forwarded, to be able to federate somewhere. (maybe add a server setting somewhere to prevent abuse, fine by me if that's the concern)

detailing the idea a little further, by default your matrix synapse server doesn't come equipped with the capability to access a potential matrix server through tor.

So you would need a server setting mentionning the SOCKS5 proxy (by default 127.0.0.1:9050 for tor connections), and for the onion nodes, they'd need to access the clearnet nodes through tor (meaning through the socks proxy)

"socks-proxy":"127.0.0.1:9050" (empty by default)
"access-clearnet-peers-through-socks-proxy" set to false by default

There, to prevent abuse on the clearnet matrix servers, i guess you would have the 2 following settings:

"allow-onion-peers" set to false by default, 
"allow-clearnet-peers" set to true by default.

So you would have the following ecosystems:
image

1) the clearnet ecosystem of nodes federating with each other

requirement per clearnet node :
-1 public ip
-port 8448 forwarded,
-a clearnet domain

"allow-onion-peers":false
"allow-clearnet-peers":true

2) the clearnet w/ optional onion ecosystem:

requirement per clearnet node:
-1 public ip
-port 8448 forwarded,
-a clearnet domain
-and the opt-in setting to allow onion federation, with the mentionned SOCKS Proxy port 127.0.0.1:9050

"socks-proxy":"127.0.0.1:9050"
"access-clearnet-peers-through-socks-proxy":false
"allow-onion-peers":true
"allow-clearnet-peers":true

requirement per onion node :
-1 server (can be self-hosted), no need for any port forward nor any public IP
-needs tor service running locally,
-a .onion domain that can access the local port 8448
-the setting saying they want to access clearnet nodes through the local socksproxy 127.0.0.1:9050

"socks-proxy":"127.0.0.1:9050"
"access-clearnet-peers-through-socks-proxy":true
"allow-onion-peers":true
"allow-clearnet-peers":true

and to federate to the clearnet, it would require a clearnet node to also have access to a tor socks proxy, and to have enabled the setting that they allow federation from onion nodes (opt-in due to the abuse potential of course)

3) purely onion ecosystem (no clearnet at all)

requirement per onion node :
-1 server (can be self-hosted), no need for any port forward nor any public IP
-needs tor service running locally,
-a .onion domain that can access the local port 8448

"socks-proxy":"127.0.0.1:9050"
"allow-onion-peers":true
"allow-clearnet-peers":false

and the nodes would federate with each other, no clearnet needed at all, just matrix servers with tor connectivity.

EDIT AS OF 05/10/2024: it looks like noone in matrix seems to take that seriously, so i'm cancelling the bounty. I have moved my entire community from matrix to SimpleX, where onion support is already there. Besides, matrix has become a mess and is apparently going nowhere anonymity-wise and deniability-wise. Until you guys catch up to the standard that SimpleX has achieved, i'm not going back there.

@Louis2747
Copy link

Louis2747 commented Aug 26, 2024

Also consider GNUnet longterm, and I don't think the userbase matters all that much, people will use what is available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-S2S Server-to-Server API (federation) improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

7 participants