3 ms·

That's already what happens in practice, as defined in XEP-0368 SRV records for XMPP over TLS https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensi

That's already what happens in practice, as defined in XEP-0368 SRV records for XMPP over TLS https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html That UX description is intended for "additional connection options" prompts, which are useful when your server is misconfigured or you want to reach it in a different manner than advertized over DNS (eg. over a .onion address).

giancarlostoro 5y ago
Oh I see, that makes sense then. I didn't realize Onion instances needed special customization, is there no way to fix this UX?
- southerntofu 5y ago
  Great question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate). "Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel. Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections). Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html https://modules.prosody.im/mod_onions.html Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list. All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
  - southerntofu 5y ago
    So we just had some conversation about it and it and in fact onion discovery works fine with SRV records. The problem is if you set the highest priority for an onion, tor-unaware clients may try to make a DNS request for it, and i believe a bunch of resolvers are still happy to try and resolve onions despite rfc7686 special-casing .onion (back in 2015), which would result in metadata leak: your resolver would learn what onion addresses you tried to reach. Whether that's a huge concern or not is a good debate. In the case where the .onion is a security upgrade to the network connection for a "normal" vhost, then it's not a problem because your resolver has already learned about the vhost you'd like to reach (via the SRV query). The real problem would be if a client tried to resolve foobar.onion through DNS when provided with a user@foobar.onion login. According to spec DNS software should not do that, but from a super quick review it appears a number of DNS implementations still do that. I'm not sure what the best approach is here. But surely there's a solution to find.

giancarlostoro 5y ago

Oh I see, that makes sense then. I didn't realize Onion instances needed special customization, is there no way to fix this UX?

southerntofu 5y ago
Great question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate). "Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel. Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections). Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html https://modules.prosody.im/mod_onions.html Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list. All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
- southerntofu 5y ago
  So we just had some conversation about it and it and in fact onion discovery works fine with SRV records. The problem is if you set the highest priority for an onion, tor-unaware clients may try to make a DNS request for it, and i believe a bunch of resolvers are still happy to try and resolve onions despite rfc7686 special-casing .onion (back in 2015), which would result in metadata leak: your resolver would learn what onion addresses you tried to reach. Whether that's a huge concern or not is a good debate. In the case where the .onion is a security upgrade to the network connection for a "normal" vhost, then it's not a problem because your resolver has already learned about the vhost you'd like to reach (via the SRV query). The real problem would be if a client tried to resolve foobar.onion through DNS when provided with a user@foobar.onion login. According to spec DNS software should not do that, but from a super quick review it appears a number of DNS implementations still do that. I'm not sure what the best approach is here. But surely there's a solution to find.