-
Jona
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
-
Licaon_Kter
Jona: you wanna point to what?
-
Jona
I want to point to a prosody instance which runs on a subdomain. I successfully use xmpp-client SRV for records for this but I was wondering about HTTP to get through corporate firewalls✎ -
Jona
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 ✏
-
Peter Waher
You have the _xmppconnect TXT record you can add, with a _xmpp-client-websocket=wss://... string.
-
Menel
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
-
Menel
No txt or srv records needed
-
Menel
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
-
Peter Waher
In what way insecure? Insecure as much as DNS is insecure? Or something else?
-
moparisthebest
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
-
Jona
Menel: my main domain has no IP address so it cannot serve the /.well-known location
-
Menel
Then you're out of luck.
-
moparisthebest
Peter Waher: https://mail.jabber.org/pipermail/standards/2022-February/038759.html
-
moparisthebest
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
-
Peter Waher
Thanks. Yes, I remember this mail. But it is the same problem as with DNS overall, and SRV records as well, no?
-
Jona
moparisthebest: thanks, that sounds interesting
-
Jona
The mail explain domain validation is not the same for https as it is fir xmpp c2s✎ -
Jona
The mail explains domain validation is not the same for https as it is fir xmpp c2s ✏
-
moparisthebest
No with SRV we validate the record with TLS certificates, with this record that wasn't happening
-
moparisthebest
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
-
moparisthebest
Plus #2 is an impossible situation, what do you sent for SNI and Host: header?
-
Peter Waher
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?
-
moparisthebest
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
-
Peter Waher
(I mean, the same operations occur in both cases: DNS resolve, redirect, connect via TLS, validate certificate)
-
moparisthebest
And nearly no clients or libraries allow you to do that kind of certificate validation either
-
Peter Waher
Se 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.✎ -
Peter Waher
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. ✏
-
moparisthebest
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
-
jaj
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
-
jaj
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
-
jaj
This is the way it is implemented in matrix which allows domain delegation with https
-
Menel
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.
-
Menel
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
-
Menel
And yes, theoretically, xmpp connection methods could add it to a xep to specify it and clients could implement it
-
Licaon_Kter
jaj: what's the difference between "manually checked by the client" and "automatically checked by the client"? :)
-
moparisthebest
jaj: domain delegation with https is what host-meta files are in XMPP, it's secure
-
Menel
At the moment they don't. But generally, if you own example.net you can add stuff to .well-known/ there and everything works
-
moparisthebest
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
> 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
-
jaj
> 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
-
jaj
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.
-
Licaon_Kter
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? :)
-
moparisthebest
In practice it doesn't really matter
-
moparisthebest
jaj: can you point to where matrix does delegation with DNS? I'm curious now
-
jaj
moparisthebest: https://github.com/matrix-org/synapse/blob/develop/docs/delegate.md
-
jaj
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
-
jaj
This is required by the spec and if the certificate is noy valid for both, the client will error out
-
jaj
Also briefly explained here: https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi
-
jaj
" 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. "
-
moparisthebest
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
-
moparisthebest
> 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
-
moparisthebest
Basically fetch page https://bob.com/ but ask for TLS cert for example.com in SNI and Host: header
-
pep.
domain fronting?
-
pep.
Hmm not really
-
pep.
You're still getting bob.com
-
moparisthebest
You are connecting to bob.com's IP but asking for example.com
-
moparisthebest
I wonder what clients/servers implement this and if they do it right considering it'd be trivial to get wrong
-
jaj
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
-
moparisthebest
jaj: that's what the matrix spec suggests
-
moparisthebest
It doesn't say it can't be valid for bob.com of course but doesn't require or suggest it
-
jaj
Yes but in practice it will be valid fir bob.com as well or the http server will complain
-
moparisthebest
The https server doesn't even know about bob.com in this case, only example.com
-
jaj
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
-
jaj
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
-
Licaon_Kter
jaj: only web clients use bosh/ws anyway
-
moparisthebest
Licaon_Kter: untrue
-
Licaon_Kter
Oh?
-
jaj
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.
-
moparisthebest
jaj: how do you discover the path etc? That's not hardcoded
-
jaj
Yes indeed, that's a problem I was considering
-
moparisthebest
Licaon_Kter: pidgin supports Bosh, gajim supports WebSocket for sure and I think Bosh too...
-
Licaon_Kter
Interesting, good to know
-
moparisthebest
converse-tauri also ;)
-
jaj
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 :)
-
moparisthebest
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