The module mod_onions allows for the federation of *.onion addresses. For onion addresses that are also connected to a clearnet address, one can easily obtain a valid certificate, and can even get a free one from Let's Encrypt, for example. But for those who only have an *.onion address, obtaining such a valid certificate is extremely difficult, and certainly not for free or without giving personal information. So for *.onion addresses without a clearnet address, using a self-signed certificate is really the only possibility. But, for security reasons, many, many servers force s2s encryption and authentication, even the ones that also have an *.onion address, and such servers will not connect with *.onion addresses that have only a self-signed certificate. The only way then to actually federate with other *.onion address is to either also have a clearnet address and obtain a valid certificate, or for the other servers to completely disable s2s encryption and authentication. If someone who wants to run the Prosody sever only as a Tor onion service, the only federation that actually happens then is with servers that disable all s2s encryption. Completely disabling s2s encryption though is considered by many a security risk. So we propose to continue having the option to require s2s encryption and valid certificates (for those who want to have it), but add another option that gives an exception for when connecting s2s with an *.onion address. Which makes sense anyway since *.onion to *.onion connections are already encrypted and having a valid (or even self-signed) certificate is unnecessary anyway. This will give those who add an *.onion address to their clearnet address the ability to federate with *.onion-only XMPP servers without also having to disable s2s encryption. This would give the best of both worlds and feel it's the only way to really have the servers federate and propagate through Tor or have servers that are only on Tor be able to connect with the majority of other *.onion servers.

Hi, thanks for the report. This should be a pretty easy fix for someone to do. As you say, .onion connections are already encrypted. The module should set the 'secure' property on the session to indicate this to Prosody. This could be as simple as adding in a couple of places: session.secure = true I don't have a Tor setup, and we are working on other improvements in Prosody in preparation for the next release. As such, we probably won't be working on this issue, but will leave it here in case a community member feels able to take it on.

• tags Status-Accepted Component-Community Difficulty-Easy

We discussed this in the chatroom earlier today. Just treating all .onion domains as secure is not sensible on a server that also accepts non-tor connections. Consider a non-tor server connecting, and claiming to be 'foo.onion'. It would bypass all TLS and certificate checks, and potentially impersonate a real .onion domain while having none of the security benefits. Prosody cannot rely on the domain asserted by the connecting server to determine whether the connection is appropriately secured. It needs another way to determine whether the connection came via tor. One possibility is to detect connections to/from a particular network interface (e.g. you will likely be running tor on localhost). For this, mod_secure_interfaces already exists: https://modules.prosody.im/mod_secure_interfaces