XMPP Service Operators - 2024-07-31

> Make it match what you have in > nano /etc/network/interfaces > For ipv6 was finally looking into this, and i have nothing in there https://envs.sh/ilb.png ↺

using null ptr instance since my http rev proxy is stopped

``` root@snapshot-115842185-debian-2gb-hil-1:/home/joseph# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5) # Include files from /etc/network/interfaces.d: source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback root@snapshot-115842185-debian-2gb-hil-1:/home/joseph# ip -6 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a01:4ff:1f0:c2f2::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::9400:2ff:fe4d:986d/64 scope link valid_lft forever preferred_lft forever 4: br-2410bde0046c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP inet6 fe80::42:86ff:fed7:4daa/64 scope link valid_lft forever preferred_lft forever 9: vethc039dcd@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP inet6 fe80::c8aa:62ff:fec6:9448/64 scope link valid_lft forever preferred_lft forever root@snapshot-115842185-debian-2gb-hil-1:/home/joseph# ```

you need to check the files referencesd there in `source`, too

or that

this is a very stupid question but how do i know which ip to read from the ip output

ignore everything with fe80, because those are so-called link-local addresses

ignore ::1, because that's loopback (think 127.0.0.1, but for IPv6)

okay seems #2 it is

yup :)

https://envs.sh/ilw.png

okay ive added the records. i did it just after renewing my letsencrypt certs so i dont know if that was the wrong order per se but oh well

thankfully, let's encrypt doesn't care :)

if anyone knows how to see if ipv6 only is working, feel free to test and let me know. i have both ipv4 and ipv6 here i believe

or at least for sure ipv4

and ping isnt set to work with my server

anyways jonas’ tysm for your help

i can at least reach your xmpp server on port 5222 over IPv6

and port 5269

so there's that

jjj333_p [pain.agency] ``` xmpp-dns -6cfstv pain.agency failure in xmpp-client lookup: lookup _xmpp-client._tcp.pain.agency. on 127.0.0.53:53: no such host failure in xmpps-client lookup: lookup _xmpps-client._tcp.pain.agency. on 127.0.0.53:53: no such host Trying fallback ports. xmpp-client pain.agency. 5222 Priority: 0 Weight: 0 IP: 2a01:4ff:1f0:c2f2::1 Connection: [OK] StartTLS: [OK] Certificate: [OK] xmpps-client pain.agency. 5223 Priority: 0 Weight: 0 IP: 2a01:4ff:1f0:c2f2::1 Connection: [OK] TLS: [OK] Certificate: [OK] xmpps-client pain.agency. 443 Priority: 0 Weight: 0 IP: 2a01:4ff:1f0:c2f2::1 Connection: [OK] TLS: [Not OK] remote error: tls: no application protocol failure in xmpp-server lookup: lookup _xmpp-server._tcp.pain.agency. on 127.0.0.53:53: no such host failure in xmpps-server lookup: lookup _xmpps-server._tcp.pain.agency. on 127.0.0.53:53: no such host Trying fallback ports. xmpp-server pain.agency. 5269 Priority: 0 Weight: 0 IP: 2a01:4ff:1f0:c2f2::1 Connection: [OK] StartTLS: [OK] Certificate: [OK] xmpps-server pain.agency. 5270 Priority: 0 Weight: 0 IP: 2a01:4ff:1f0:c2f2::1 Connection: [OK] TLS: [OK] Certificate: [OK] ```

the one `TLS: [Not OK]` concerns me a little, but otherwise that seems fine. thanks =)

yeah. To repeat the test: https://salsa.debian.org/mdosch/xmpp-dns

tysm

np

Seems you're missing srv records.

why does xmpp-dns default to direct TLS on port 443 if there are no SRV records for that?

oh yes, i was told those arent necessary as my domain already points to my vps

> oh yes, i was told those arent necessary as my domain already points to my vps i can add them if i should, i just have been too lazy ↺

Then clients will probably only use default 5222 StartTLS as long as you don't manually configure them to use direct tls. Same for s2s. But as you set up direct tls you might also want to use it.

> Then clients will probably only use default 5222 StartTLS as long as you don't manually configure them to use direct tls. Same for s2s. But as you set up direct tls you might also want to use it. is there anything wrong with them using that default? ↺

No, but l assumed you want to use direct tls as you set it up.

> No, but l assumed you want to use direct tls as you set it up. oh i was just told you have to? is there some other form of tls that xmpp uses? ↺

(to be fair i was inducted into the xmpp cult by people i no longer talk to, and they all kinda were telling me conflicting things)

telepath.im admin, welcome

Thank you

>> No, but l assumed you want to use direct tls as you set it up. > oh i was just told you have to? is there some other form of tls that xmpp uses? jjj333_p [pain.agency]: look up STARTTLS ↺

> (to be fair i was inducted into the xmpp cult by people i no longer talk to, and they all kinda were telling me conflicting things) xmppeaking ↺

> jjj333_p [pain.agency]: look up STARTTLS ah. so i should probably set up srv records. ill do that... eventually ↺

> xmppeaking eh just the normal autism of online nice communities ↺

our brand of autism before everything fell apart just happened to be xmpp and programming in old versions of c for whatever reason (not me personally)

for the record: you do not need SRV records for starttls to work

> for the record: you do not need SRV records for starttls to work my understanding is starttls is what its using when you dont have srv records? ↺

or was i misunderstanding

starttls is used with _xmpp-server / _xmpp-client SRV records, and by default when you don't have SRV records

the other variant, direct tls, is only used with _xmpps-server / _xmpps-client SRV records and is not supported by all clients and servers which may connect to your server.

direct tls has fewer roundtrips than starttls, which may be an advantage for mobile clients on high-latency or otherwise slow links

> direct tls has fewer roundtrips than starttls, which may be an advantage for mobile clients on high-latency or otherwise slow links got it, makes sense ↺

how do the srv lookups not outweight the fewer round trips?

ukko, they can be cached.

oh

> how do the srv lookups not outweight the fewer round trips? i just always figured that it came with the rest of the dns information ↺

no reason to assume that i just did

nice DNS servers may actually also hand you the address records alongside the SRV response, yeah, but it's not too common.

but caches certainly help.

> got it, makes sense might be something that matters to me as i live in bumfuck, pacific ocean and selfhost because most foss services are hosted in the eu which i get approx 600ms ping to ↺

ukko, not to mention that the SRV records must be queried regardless, because a client needs to find out first whether there even are SRV records before they can fall back to non-SRV endpoints.

even my vps (west coast usa) to eu servers is about 400-500ms ping

but anyways thats good to know that its realistically mostly a latency improvement more than anything

clarifies it in my mind

Hm also an udp dns package is more lightweight then any part of the tls handshake I guess

> Hm also an udp dns package is more lightweight then any part of the tls handshake I guess also often dns servers (such as clownflare) do a lot of work to reduce latency otherwise ↺

jjj333_p [pain.agency], well and direct TLS on port 443 tends to be easier to get through some nasty firewalls than starttls on port 5222, but whether you want to cater for those is up to you

Thanks to #Whatsapp, 5222 is still very good, but yeah. Nothing beats 443/tcp

> jjj333_p [pain.agency], well and direct TLS on port 443 tends to be easier to get through some nasty firewalls than starttls on port 5222, but whether you want to cater for those is up to you i mean so far i havent run into that problem yet i dont think, but good to know ↺

> about 400-500ms ping you can use https://ping.pe to ping/traceroute/mtr from dozens of locations

actually wait, very dumb question, does direct tls being on port 443 conflict with reverse proxy? because i know i have to stop caddy to work certbot? or is it only for http traffic

you shouldn't have to stop caddy, switch to standalone plugin for certbot or let caddy handle certs itself

> > about 400-500ms ping > > you can use https://ping.pe to ping/traceroute/mtr from dozens of locations pretty sure i never set up ping to work, not sure how i would make it work and havent bothered to car ↺

care

https://downloadable.pain.agency/file_share/cvM60BXcaQ70Xp3DdfbPIkmv/d8fca9ad-68f4-459a-a655-7b807ee2e46f.png

> you shouldn't have to stop caddy, switch to standalone plugin for certbot or let caddy handle certs itself i use standalone for the domains that are xmpp specific, and then caddy handles certs for all the others. do i add all the xmpp subdomains into caddy to be reverse proxied? ↺

like ive never had to renew pain.agency because it is managed by caddy and ive had it for years. but the xmpp subdomains i figured cant be managed by caddy since caddy is only http traffic?

jjj333_p [pain.agency]: xmpp on 443 will conflict with caddy listening on 443 tcp

Two services on the same port can't work

>> >> you can use https://ping.pe to ping/traceroute/mtr from dozens of locations > pretty sure i never set up ping to work, not sure how i would make it work and havent bothered to car Allow ICMP ↺

But I think caddy can do raw tls proxy stuff. So it could receive on port 443 for your xmpp server and serve that to the xmpp server locally on another port like 5223

> But I think caddy can do raw tls proxy stuff. > So it could receive on port 443 for your xmpp server and serve that to the xmpp server locally on another port like 5223 so i should just add the xmpp subdomains into caddy and tell it to redirect to the respective ports? ↺

Something about a layer4 app in caddy is what the internet tells me. A normal reverse proxy won't work. Because the normal one is for https

https://wiki.xmpp.org/web/Tech_pages/XEP-0368#Transparent_Proxying Nobody added caddy yet here

> why does xmpp-dns default to direct TLS on port 443 if there are no SRV records for that? This is what all clients and servers should be doing 🙂 ↺

Also same for QUIC

moparisthebest, that's non-standard behaviour though

But xmpp-dns only does that when you tell it to "just try stuff" right? It's a sensible assumption. Like 5223 too.

ok

I _think_ it's the second most used xmpps_client port

we should just get rid off `ports` all together

what's the point when we just use all on the one and only 443

With ip6 we can instead just use ips and not ports true

The real issue is that HTTPS records weren't the default

No reason it should be hardcoded to 443

I'm using xmpp over 443 for clients without sslh on ipv6. Thanks to the power of so many ips 😍

Alternatively just think using onions like ogres

> what's the point when we just use all on the one and only 443 Correct ↺

it should be hardcoded to 443 because that's the most likely to work, that's all

internet == 443

>> why does xmpp-dns default to direct TLS on port 443 if there are no SRV records for that? > This is what all clients and servers should be doing 🙂 _in your opinion_ ↺

Wasn't DirectTLS considered legacy?

*the world's opinion

until Openfire 4.8.0 I believe DirectTLS was Legacy TLS

> Wasn't DirectTLS considered legacy? Xep-0368 never was, but back in 2000 when XMPP standardized as an RFC and people thought non-encrypted was ok the previous seperate hardcoded port of 5223 was deprecated in favor of starttls which was hot at the time ↺

>> Wasn't DirectTLS considered legacy? > Xep-0368 never was, but back in 2000 when XMPP standardized as an RFC and people thought non-encrypted was ok the previous seperate hardcoded port of 5223 was deprecated in favor of starttls which was hot at the time yet startls is the most commonly used ↺

if you disable startls you will struggle to peer with servers ✏

A friend of mine learnt that the hard way...

Not sure that's true anymore actually

> A friend of mine learnt that the hard way... this was 1 year ago ↺

so I assume it still is

There are indeed servers not using direct tls.

But yes it's unsurprising the way that's worked for 25 years is more widely supported than the 8 year old way

> There are indeed servers not using direct tls. _cough cough_ ↺

lets just say I got a little lazy when setting up my current server... it was a test server and then became my main server... so it uses an embedded database and only have the bare minimum setup

that's your problem

Indeed. But I am not the only one :)

There is no harm having both, or only starttls on s2s

The handshake isn't very relevant for s2s

Menel: servers are dropping startls s2s

I have seen it a few times now

I've never seen it

I assume moparisthebest *would* like to if everyone used DirectTLS

so that the handshake is encrypted and not just the payload

hosts that only allow TLS on 443 are getting more common, it's becoming more important :)

Just saying it's a no-issue currently.

correct, can't do nice things like ECH with starttls

> hosts that only allow TLS on 443 are getting more common, it's becoming more important :) Thankfully I dont need to worry about extreme firewalls like that :) ↺

> correct, can't do nice things like ECH with starttls almost nobody has adopted ECH ↺

You do if you need to talk to hosts over s2s behind them

I've zero servers that don't talk to mine (that I would want) currently. Well I'm preferring direct tls on ipv6 but I guess that doesn't matter

im decommissioning my server in the coming months anyways

Ech is supported by all browsers for years, it's coming along, these things move slowly

Being able to move slowly in the right direction is one of the main benefits of an eXtensible standardized protocol, flag days are best avoided

> Ech is supported by all browsers for years, it's coming along, these things move slowly server side? no ↺

> I'm using xmpp over 443 for clients without sslh on ipv6. Thanks to the power of so many ips 😍 Menel: ipv4 is a requirement ↺

ipv6 doesn't work on any networks i've tried in georgia ✏

ipv6 doesn't work on any network i've tried in georgia ✏

Well I'm saving the route through sslh for ipv6 with it. Ipv4 can still use 5222,5223 and 443 through sslh ✏

I do the same

> Well I'm saving the route through sslh for ipv6 with it. > Ipv4 can still use 5222,5223 and 443 through sslh I have never used sslh and havent had the need to ↺

i have

just do it

do what... I aint setting something up I dont need

you must

it's the only way

to do what?

if an XMPP server cant use ports other than 443 then they shouldnt host a server... simple!

My university blocks IRC and XMPP... I simply dont use their network... they provide an unencrypted secondary network with no firewall and it goes through a different backhaul and isnt directly managed by the uni... or... I use mobile data... There is some efforts to try to unblock some of these services as they can affect the computing department. Plus the devices arent able to update properly as the firewall keeps dropping microsoft updater packets.

sometimes the simpler solution is better... I dont need to use the network so i dont.

also sshl could break contracts and TOS... resulting in legal trouble... or in my case, my education revoked (they can do that) and permanent suspension

> if an XMPP server cant use ports other than 443 then they shouldnt host a server... simple! If you cannot configure my (our) firewall, nobody inside our company will connect your server. ... simple!!!

A server op may or may not be interested in supporting clients behind restrictive firewalls. No need to agree on a single policy here.

as their firewall is in place to enforce their policies, bypassing it goes against your employment/education contract

so I would actually be concerned about pushing sshl as a standard/default

> as their firewall is in place to enforce their policies, bypassing it goes against your employment/education contract _I think I see why I am considered so boring_ ↺

>> if an XMPP server cant use ports other than 443 then they shouldnt host a server... simple! > If you cannot configure my (our) firewall, nobody inside our company will connect your server. > ... simple!!! so if the company chooses to host said server? why would they block its ports? ↺

and force an extra point of failure?

Polarian. There's hotel WiFis or whatever operated by admins who believe security is increased by allowing only TLS on 443. I'd like to use XMPP from such networks so I offer TLS on 443. If the hotel admin wanted to block XMPPS on 443 then they obviously got it wrong. Not my problem. I understand you don't care about that use case. Fine then. End of story. No?

So much bikeshedding all day long ...

> Polarian. There's hotel WiFis or whatever operated by admins who believe security is increased by allowing only TLS on 443. I'd like to use XMPP from such networks so I offer TLS on 443. If the hotel admin wanted to block XMPPS on 443 then they obviously got it wrong. Not my problem. I understand you don't care about that use case. Fine then. End of story. No? sure... but why not just use data then? ↺

also unless they are using deep packet inspection you can TCP VPN on 443 to a more free network, this is more versatile too :)

Because it costs me and I don't want to? Or maybe it's not available there.

I doubt discussing such stuff helps anyone in here in any way.

> also unless they are using deep packet inspection you can TCP VPN on 443 to a more free network, this is more versatile too :) also means server providers dont have to do any extra work ↺

> I doubt discussing such stuff helps anyone in here in any way. true... sorry. ↺

Don't mind occasional small talk at all, but the amount reduces the value of this channel for me.

Okay, you seems to be a 12-15year old kiddy which never worked in a company Let me explain: There are companies which block your mobil. But this companies will offer you a proxy to go through the internet. They open 80/443/.... in *their* firewall. If somebody try to connect your server, he will get no connect. If he will connect to my server (via 443 and sslh) he is able to do so. It is his (her) will to do so and I'm not the judgement.

> also sshl could break contracts and TOS... resulting in legal trouble... or in my case, my education revoked (they can do that) and permanent suspension you do realize that human beings run your uni right? ↺

drop the topic

> if an XMPP server cant use ports other than 443 then they shouldnt host a server... simple! Polarian: i allow connection to like 4 ports ↺

maybe 5

> Okay, you seems to be a 12-15year old kiddy which never worked in a company > > Let me explain: > There are companies which block your mobil. But this companies will offer you a proxy to go through the internet. They open 80/443/.... in *their* firewall. > > If somebody try to connect your server, he will get no connect. > > If he will connect to my server (via 443 and sslh) he is able to do so. > > It is his (her) will to do so and I'm not the judgement. I do not personally agree with bypassing corporate restrictions considering it is likely a violation of your contract if caught, and even then, you are at work... you shouldnt be on XMPP, and if you want to use XMPP, use your data, why should they pay to route your packets which arent work related? Also drop the topic Also also mind your language, I will gladly admit I am not 12-15, I am quite a bit older, older than some others in this channel, do not use ageist remarks to invalidate my opinion, or to belittle me. ↺

On topic question I was wondering, if you use standard ports do you guys still publish SRV records?

Srv are also useful if you want addresses on the root domain, but run the actually xmpp server on a subdomain.

For various reasons, typically because they point to physically separate servers.

To see and get inspired what people use I recommend using xmpp-dns on some public servers and see

> Srv are also useful if you want addresses on the root domain, but run the actually xmpp server on a subdomain. sorry, say you didn't... say you had the root domain as your FQDN and you are using standard ports? ↺

Some do, some don't Polarian. Some say it's cleaner to publish anyway. The current clients and severs will work in any case

> Some do, some don't Polarian. Some say it's cleaner to publish anyway. The current clients and severs will work in any case whats the standard on this? ↺

Polarian: RFC 6120

The rfc? You may read that yourself at xmpp.org

> Polarian: RFC 6120 someone knows their rfcs ↺