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
karmehas joined
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✎
Chris Machas joined
Steven Roosehas left
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 ✏
william.chatnerhas joined
papatutuwawahas left
Maranda[x]has left
marc0shas left
marc0shas joined
jajhas left
ralphmhas joined
ijhas left
Peter Waher
You have the _xmppconnect TXT record you can add, with a _xmpp-client-websocket=wss://... string.
Peter Waherhas left
marc0shas left
marc0shas joined
belonghas left
resolihas joined
Peter Waherhas joined
belonghas joined
sonnyhas left
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
*IM*has left
sonnyhas joined
Peter Waher
In what way insecure? Insecure as much as DNS is insecure? Or something else?
Maranda[x]has joined
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?
*IM*has joined
Jona
moparisthebest: thanks, that sounds interesting
resolihas left
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 ✏
ijhas joined
$h00tthe®00thas left
qwemnbhas left
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
$h00tthe®00thas joined
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
schäfchen726has left
schäfchen726has joined
sonnyhas left
ralphmhas left
barlashas left
barlashas joined
antranigvhas joined
Jonahas left
sonnyhas joined
ralphmhas joined
djorzhas left
marc0shas left
marc0shas joined
schäfchen726has left
schäfchen726has joined
allbombsonhas joined
serge90has left
Friendly Resident Cynichas joined
Steven Roosehas joined
Chris Machas left
timothyhas left
timothyhas joined
p42ityhas left
marc0shas left
marc0shas joined
allbombsonhas left
sonnyhas left
p42ityhas joined
allbombsonhas joined
millesimushas left
sonnyhas joined
marc0shas left
marc0shas joined
karimhas joined
millesimushas joined
ru_maniachas left
ru_maniachas joined
schäfchen726has left
schäfchen726has joined
marc0shas left
marc0shas joined
Chris Machas joined
xsohas left
marc0shas left
marc0shas joined
xsohas joined
hshdhdhchas joined
ralphmhas left
papatutuwawahas joined
snowhas joined
sonnyhas left
sonnyhas joined
Ingolfhas left
alacerhas joined
Ingolfhas joined
schäfchen726has left
schäfchen726has joined
allbombsonhas left
allbombsonhas joined
antranigvhas left
sonnyhas left
belonghas left
Steven Roosehas left
mxhas left
mxhas joined
marc0shas left
marc0shas joined
beanhas joined
belonghas joined
schäfchen726has left
schäfchen726has joined
marc0shas left
marc0shas joined
beanhas left
sonnyhas joined
Chris Machas left
marc0shas left
marc0shas joined
catchyhas left
catchyhas joined
ralphmhas joined
marc0shas left
marc0shas joined
djorzhas joined
marc0shas left
marc0shas joined
世界之保證has left
世界之保證has joined
schäfchen726has left
schäfchen726has joined
marc0shas left
marc0shas joined
sonnyhas left
Ingolfhas left
Steven Roosehas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
sonnyhas joined
Ingolfhas joined
marc0shas left
marc0shas joined
Chris Machas joined
schäfchen726has left
schäfchen726has joined
jgarthas left
resolihas joined
Chris Machas left
antranigvhas joined
kuba_has left
antranigvhas left
Trunghas left
Trunghas joined
Chris Machas joined
andrey.utkinhas left
mxhas left
beanhas joined
dora71has left
dora71has joined
beanhas left
mxhas joined
antranigvhas joined
dora71has left
dora71has joined
Trunghas left
dora71has left
dora71has joined
Trunghas joined
andrey.utkinhas joined
kuba_has joined
sonnyhas left
writer77has left
resolihas left
sonnyhas joined
allbombsonhas left
allbombsonhas joined
belonghas left
sonnyhas left
marc0shas left
marc0shas joined
Arnehas left
mxhas left
marc0shas left
marc0shas joined
Arnehas joined
mxhas joined
belonghas joined
sonnyhas joined
marc0shas left
marc0shas joined
Steven Roosehas left
antranigvhas left
papatutuwawahas left
marc0shas left
marc0shas joined
belonghas left
abdullahhas joined
ricciohas left
ricciohas joined
marc0shas left
marc0shas joined
Ingolfhas left
kuba_has left
Chris Machas left
Chris Machas joined
abdullahhas left
kuba_has joined
writer77has joined
djorzhas left
savagepeanuthas joined
belonghas joined
jajhas joined
savagepeanuthas left
savagepeanuthas joined
Chris Machas left
papatutuwawahas joined
jgarthas joined
Maranda[x]has left
Menelhas left
belonghas left
karlhas joined
belonghas joined
savagepeanuthas left
dryanhas joined
savagepeanuthas joined
Menelhas joined
alacerhas left
Steven Roosehas joined
kapadhas joined
schäfchen726has left
schäfchen726has joined
djorzhas joined
dryanhas left
alacerhas joined
Ingolfhas joined
andrey.utkinhas left
jgarthas left
antranigvhas joined
andrey.utkinhas joined
loopboomhas joined
ricciohas left
Maranda[x]has joined
alacerhas left
snowhas left
ricciohas joined
loopboomhas left
greyhas left
greyhas joined
froghas left
ricciohas left
ricciohas joined
savagepeanuthas left
savagepeanuthas joined
schäfchen726has left
schäfchen726has joined
djorzhas left
djorzhas joined
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
me9has left
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
marc0shas left
marc0shas joined
resolihas joined
hshdhdhchas left
xsohas left
xsohas joined
beanhas joined
beanhas left
msavoritiashas left
savagepeanuthas left
savagepeanuthas joined
schäfchen726has left
schäfchen726has joined
j.r (jugendhacker.de)has left
j.r (jugendhacker.de)has joined
beanhas joined
schäfchen726has left
schäfchen726has joined
beanhas left
belonghas left
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
serge90has joined
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"? :)
belonghas joined
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
ricciohas left
$h00tthe®00thas left
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
karimhas left
karimhas joined
patascahas left
patascahas joined
jchas left
jchas joined
greyhas left
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
greyhas joined
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
djorzhas left
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.
andrey.utkinhas left
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
waelhas left
andrey.utkinhas joined
moparisthebest
jaj: can you point to where matrix does delegation with DNS? I'm curious now
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
Steven Roosehas left
marc0shas left
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
$h00tthe®00thas joined
bunghas left
jzmartinhas left
etaurushas left
etaurushas joined
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
ricciohas joined
moparisthebest
You are connecting to bob.com's IP but asking for example.com
guus.der.kinderenhas joined
guus.der.kinderenhas left
moparisthebest
I wonder what clients/servers implement this and if they do it right considering it'd be trivial to get wrong
Steven Roosehas joined
patascahas left
patascahas joined
ororohas joined
sonnyhas left
antranigvhas left
raverhas left
raverhas joined
Peter Waherhas left
sonnyhas joined
Steven Roosehas left
Peter Waherhas joined
djorzhas left
Maranda[x]has left
Steven Roosehas joined
xsohas left
ricciohas left
Trunghas left
me9has joined
xsohas joined
ricciohas joined
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
resolihas left
antranigvhas joined
alacerhas joined
eevvoorhas left
greyhas left
greyhas joined
resolihas joined
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
Maranda[x]has joined
moparisthebest
The https server doesn't even know about bob.com in this case, only example.com
belonghas left
Steven Roosehas left
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
belonghas joined
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
Steven Roosehas joined
Licaon_Kter
jaj: only web clients use bosh/ws anyway
moparisthebest
Licaon_Kter: untrue
Licaon_Kter
Oh?
resolihas left
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.
froghas joined
moparisthebest
jaj: how do you discover the path etc? That's not hardcoded
jaj
Yes indeed, that's a problem I was considering
wurstsalathas left
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 ;)
ricciohas left
djorzhas joined
patascahas left
patascahas joined
dora71has left
Christopher M0YNGhas left
Christopher M0YNGhas joined
kuba_has left
kuba_has joined
tbm16has joined
snowhas joined
raverhas left
Chris Machas joined
raverhas joined
antranigvhas left
antranigvhas joined
beanhas joined
beanhas left
beanhas joined
beanhas left
jchas left
Steven Roosehas left
podhas left
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 :)
ibikkhas left
Maranda[x]has left
p42ityhas left
catchyhas left
Menelhas left
resolihas joined
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