XMPP Service Operators - 2023-02-05


  1. 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

  2. Licaon_Kter

    Jona: you wanna point to what?

  3. 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

  4. 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

  5. Peter Waher

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

  6. 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

  7. Menel

    No txt or srv records needed

  8. 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

  9. Peter Waher

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

  10. 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

  11. Jona

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

  12. Menel

    Then you're out of luck.

  13. moparisthebest

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

  14. 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

  15. Peter Waher

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

  16. Jona

    moparisthebest: thanks, that sounds interesting

  17. Jona

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

  18. Jona

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

  19. moparisthebest

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

  20. 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

  21. moparisthebest

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

  22. 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?

  23. 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

  24. Peter Waher

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

  25. moparisthebest

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

  26. 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.

  27. 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.

  28. 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

  29. 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

  30. 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

  31. jaj

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

  32. 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.

  33. 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

  34. Menel

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

  35. Licaon_Kter

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

  36. moparisthebest

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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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.

  42. 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? :)

  43. moparisthebest

    In practice it doesn't really matter

  44. moparisthebest

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

  45. jaj

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

  46. 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

  47. jaj

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

  48. jaj

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

  49. 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. "

  50. 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

  51. 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

  52. moparisthebest

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

  53. pep.

    domain fronting?

  54. pep.

    Hmm not really

  55. pep.

    You're still getting bob.com

  56. moparisthebest

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

  57. moparisthebest

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

  58. 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

  59. moparisthebest

    jaj: that's what the matrix spec suggests

  60. moparisthebest

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

  61. jaj

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

  62. moparisthebest

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

  63. 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

  64. 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

  65. Licaon_Kter

    jaj: only web clients use bosh/ws anyway

  66. moparisthebest

    Licaon_Kter: untrue

  67. Licaon_Kter

    Oh?

  68. 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.

  69. moparisthebest

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

  70. jaj

    Yes indeed, that's a problem I was considering

  71. moparisthebest

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

  72. Licaon_Kter

    Interesting, good to know

  73. moparisthebest

    converse-tauri also ;)

  74. 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 :)

  75. 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