XMPP Service Operators - 2023-02-05

Hi, I wonder if it is possible to use BOSH and/or websocket connections with DNS delegation? I see that TXT records have been deprecated for this purpose and no SRV records seem to exist for this

Jona: you wanna point to what?

I want to point to a prosody instance which runs on a subdomain. I successfully use xmpp-client SRV records for this but I was wondering about HTTP to get through corporate firewalls ✏

You have the _xmppconnect TXT record you can add, with a _xmpp-client-websocket=wss://... string.

Jona: on your main domain serve https://xmpp.org/extensions/xep-0156.html At your /.well-known location and point that to your prosody webserver

No txt or srv records needed

Peter Waher: > A previous version of this XEP defined a DNS method to look up this info using a TXT _xmppconnect record, this was insecure and has been removed. Thats not a thing anymore

In what way insecure? Insecure as much as DNS is insecure? Or something else?

Jona, Peter Waher: https://xmpp.org/extensions/xep-0156.html#security > A previous version of this XEP defined a DNS method to look up this info using a TXT _xmppconnect record, this was insecure and has been removed. But you can add the host-meta file instead

Menel: my main domain has no IP address so it cannot serve the /.well-known location

Then you're out of luck.

Peter Waher: https://mail.jabber.org/pipermail/standards/2022-February/038759.html

Jona: you can use this instead to listen on 443 and go through most firewalls that only allow https https://wiki.xmpp.org/web/Tech_pages/XEP-0368

Thanks. Yes, I remember this mail. But it is the same problem as with DNS overall, and SRV records as well, no?

moparisthebest: thanks, that sounds interesting

The mail explains domain validation is not the same for https as it is fir xmpp c2s ✏

No with SRV we validate the record with TLS certificates, with this record that wasn't happening

Example: you are example.com: 1. Your srv record say your XMPP is hosted at bob.com, clients/servers will connect there, but only proceed if bob.com has a valid cert for example.com 2. Your xmppconnect txt record says your XMPP is hosted at bob.com, clients connect and only check that the cert is valid for bob.com, this is insecure

Plus #2 is an impossible situation, what do you sent for SNI and Host: header?

The wss would also validate using a TLS certificate. But the point in the mail seems to indicate that in the xmpp c2s case, the certificate includes the domain name of the original domain (and/or the host name used?) and in the wss case the certificate only contains the host name pointed to? Sounds like an implementation issue, or is this behaviour specified as well?

It wasn't specified and all implementations were vulnerable, and no known http servers allow you to configure it to serve a cert for example.com if Bob.com is sni

(I mean, the same operations occur in both cases: DNS resolve, redirect, connect via TLS, validate certificate)

And nearly no clients or libraries allow you to do that kind of certificate validation either

We set the same certificate for both XMPP server and HTTP server (they are integrated), so the problem is the same (for us) for both XMPP SRV and TXT paths. But, better to use another method, if client libraries have issues. ✏

Yes that could work, and specify clients always send bob.com in sni and host: but always write custom cert validation code to also check for example.com but... In practice it'd likely never work

You could have a cert which is valid for example.com and sub.example.com though. And the client could check whether the cert is valid for both. That's how it works for c2s anyway. So I don't see why http would be different

FWIW XMPP c2s is vulnerable to the same kind of domain exploit, it is just manually checked by the client. XMPP clients could do the same kind of check independently of the http library they use

This is the way it is implemented in matrix which allows domain delegation with https

c2s is not vulnerable, because certs have to be valid for their host. Independent of the dns name. And yes, obviously clients need to check that. Thats always true for everything.

There just isn't yet a rule for webstuff and normal webserver don't work that way. I guess Matrix isn't a normal webserver

And yes, theoretically, xmpp connection methods could add it to a xep to specify it and clients could implement it

jaj: what's the difference between "manually checked by the client" and "automatically checked by the client"? :)

jaj: domain delegation with https is what host-meta files are in XMPP, it's secure

At the moment they don't. But generally, if you own example.net you can add stuff to .well-known/ there and everything works

But the way the xmppconnect txt record was underspecified and used was incompatible with how any http server works, and I found dozens of vulnerable implementations

> jaj: what's the difference between "manually checked by the client" and "automatically checked by the client"? :) "automatically" would be to just trust your http library (libcurl etc.) and if they don't error out on https then everything is okay. Manual would be to fetch the certificate and invoke some additional openssl magic to make sure the certificate is valid for all the domain names

> There just isn't yet a rule for webstuff and normal webserver don't work that way. > I guess Matrix isn't a normal webserver Matrix runs behind a reverse proxy most of the time and nginx is quite happy to use a cert which is valid for both example.com and foo.example.com when example.com is your "pretty" domain and foo.example.com is the actual server

Of course you can provide an IP for example.com and spin up a web server there to serve /.well-known but it's much less elegant IMO.

jaj: not sure I follow, you say domain and subdomain, while moparisthebest was way more complex with domain and different domain. You sure not talking past each other? :)

In practice it doesn't really matter

jaj: can you point to where matrix does delegation with DNS? I'm curious now

moparisthebest: https://github.com/matrix-org/synapse/blob/develop/docs/delegate.md

I have it working at joachim.cc. I have a SRV record for _matrix._tcp.joachim.cc which points to menial.joachim.cc and the certificate is valid for both joachim.cc and menial.joachim.cc

This is required by the spec and if the certificate is noy valid for both, the client will error out

Also briefly explained here: https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi

" Alternatively, you could advertise the server via DNS, if you don't have write access to /.well-known on your main domain. However, to prove you are allowed to host the Matrix traffic for dangerousdemos.net, you would have to configure nginx to use the dangerousdemos.net TLS certificate for the matrix.dangerousdemos.net vhost (i.e. the "wrong" one), and in general we think that /.well-known is much easier to reason about. In this case you would advertise the server with an SRV record like this: _matrix._tcp.dangerousdemos.net. 300 IN SRV 10 5 443 matrix.dangerousdemos.net. "

That says use .well-known and that DNS is not recommended, and links https://matrix.org/docs/spec/server_server/latest#resolving-server-names for how DNS works, still chasing it

> If the /.well-known request resulted in an error response, a server is found by resolving an SRV record for _matrix._tcp.<hostname>. This may result in a hostname (to be resolved using AAAA or A records) and port. Requests are made to the resolved IP address and port, using 8448 as a default port, with a Host header of <hostname>. The target server must present a valid certificate for <hostname>. This is the relevant part, it's secure to do it this way, just impossible to configure most https servers this way, and not how any https clients work out of the box

Basically fetch page https://bob.com/ but ask for TLS cert for example.com in SNI and Host: header

domain fronting?

Hmm not really

You're still getting bob.com

You are connecting to bob.com's IP but asking for example.com

I wonder what clients/servers implement this and if they do it right considering it'd be trivial to get wrong

Yes, you cannot have > Basically fetch page https://bob.com/ but ask for TLS cert for example.com in SNI and Host: header It would be problematic if you were to serve on bob.com a certificate which is valid exclusively for example.com but if you have a certificate which is valid for both then you're golden. And that's something that can be easily achieved even for letsencrypt. But indeed the client needs to check it correctly

jaj: that's what the matrix spec suggests

It doesn't say it can't be valid for bob.com of course but doesn't require or suggest it

Yes but in practice it will be valid fir bob.com as well or the http server will complain

The https server doesn't even know about bob.com in this case, only example.com

Anyway I didn't want to complain or anything, I was just wondering whether this was possible. I found the documentation a bit misleading because it says TXT records have been deprecated and you can use SRV records but just not for the same protocol

I thought maybe you could have a _xmpp-client SRV record which point to an http port and then magically the client would detect it's http and switch to BOSH or ws

jaj: only web clients use bosh/ws anyway

Licaon_Kter: untrue

Oh?

Something like that: _xmpp-client._tcp.example.net. TTL IN SRV 10 0 5222 foo.example.com. _xmpp-client._tcp.example.net. TTL IN SRV 20 0 443 foo.example.com.

jaj: how do you discover the path etc? That's not hardcoded

Yes indeed, that's a problem I was considering

Licaon_Kter: pidgin supports Bosh, gajim supports WebSocket for sure and I think Bosh too...

Interesting, good to know

converse-tauri also ;)

moparisthebest: I looked at XEP-0368 about using XMPP with ALPN. It's very interesting and nearly what I need. Unfortunately, the institution I have in mind allows outgoing connections only over an authenticated http proxy, so websocket works but if you start talking XMPP over port 443, the http proxy will not like it. Using a hosted movim or converse instance works of course :)

jaj: most http proxies accept a CONNECT command and proxy TLS directly without MITM'ing it, xep368 works fine over this, if they MITM then all bets are off