Conversation

Notices

1. Embed this notice
   jabberati (jabberati@social.anoxinon.de)'s status on Wednesday, 25-Oct-2023 00:08:45 JST jabberati

   Machine-in-the-middle Detection and Monitoring for #XMPP Servers

   https://certwatch.xmpp.net/

   This service allows you to check your XMPP server's #TLS setup, helps you publicly store the hash of the public key in a secure way, and then monitors your server to make sure that connections to it get the same public key that you have configured and sends notifications if anything changes (which may indicate a #mitm attack on your service).

   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 25-Oct-2023 00:08:43 JST feld

     in reply to
     but why is this XMPP specific? It's just testing the TLS handshake; it could work for any protocol that uses TLS
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 25-Oct-2023 01:13:13 JST feld

     in reply to

     • Wolf480pl
     > XMPP uses starttls.
     
     well that's the first problem. starttls is officially deprecated for over 10 years now IIRC...
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Wednesday, 25-Oct-2023 01:13:14 JST Wolf480pl

     in reply to

     • feld

     @feld @jabberati
     XMPP uses starttls.

     IOW, you open an XMPP connection, signal in an XMPP-specific way that you want to use TLS, the server confirms it, and only then you run a TLS handshake.

   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 25-Oct-2023 01:20:56 JST feld

     in reply to

     • feld
     • Wolf480pl
     oh that's only for SMTP/IMAP :laugh:
     
     I don't trust anything doing starttls. Sounds like the XMPP community needs to get their shit together first.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 25-Oct-2023 01:57:44 JST feld

     in reply to

     • Wolf480pl
     Sure they can. Fastmail has refused to support STARTTLS its entire existence and they're doing just fine. (except SMTP / email federation, as the only way to encrypt that is STARTTLS if the other end supports it)
     
     XMPP may very well need STARTTLS for federation too, but not for client <> server.
     
     Though the federated XMPP ecosystem is so small compared to SMTP I don't know why they don't just organize a cutover date and move on.
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Wednesday, 25-Oct-2023 01:57:45 JST Wolf480pl

     in reply to

     • feld

     @feld @jabberati
     Well tough luck, it was the recommended way back then and now a bunch of protocols are stuck with it. They can't get rid of it now.

   • Embed this notice
     Another Linux Walt Alt (lnxw37b2@shitposter.club)'s status on Wednesday, 25-Oct-2023 02:08:11 JST Another Linux Walt Alt

     in reply to

     • feld
     • Wolf480pl
     @feld @wolf480pl @jabberati
     
     I checked https://xmpp.org/extensions/xep-0479.html#core and https://datatracker.ietf.org/doc/html/rfc7590#section-3.1 ... I was surprised to find STARTTLS. I expected just mandatory TLS.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 25-Oct-2023 02:58:20 JST feld

     in reply to

     • Wolf480pl
     @jabberati @wolf480pl if the socket only accepts TLS the attack surface is very much hardened already and trusted that it will Do The Right Thing all the time and sanely handle anyone throwing bad data at it
     
     if the socket accepts plaintext and has its own parsing of the data before the upgrade to TLS it gives attackers something much more interesting to work with that probably hasn't been as thoroughly fuzzed. I'm less interested in downgrade attacks as those are pretty much dead in the water for XMPP as TLS is "required" by the specs, but other attacks on the XMPP server itself.
   • Embed this notice
     jabberati (jabberati@social.anoxinon.de)'s status on Wednesday, 25-Oct-2023 02:58:22 JST jabberati

     in reply to

     • feld
     • Wolf480pl

     @feld @wolf480pl What's wrong with STARTTLS? Direct TLS is also possible and widely supported btw.

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Wednesday, 25-Oct-2023 04:02:16 JST Wolf480pl

     in reply to

     • feld

     @jabberati @feld
     they attacker could try send valid XMPP stanzas unencrypted, together with the starttls and a buggy server may interpret them as part of the encrypted and authenticated connection after starttls.

     If a server has a bug like that, an attacker in a MITM position can inject stanzas into client's session without actually MITMing the TLS.

     this blog has an example for SMTP:

     https://blog.apnic.net/2021/11/18/vulnerabilities-show-why-starttls-should-be-avoided-if-possible/
     (haven't read the whole blog post, only the example SMTP exchange)

     feld likes this.
   • Embed this notice
     jabberati (jabberati@social.anoxinon.de)'s status on Wednesday, 25-Oct-2023 04:02:17 JST jabberati

     in reply to

     • feld
     • Wolf480pl

     @feld @wolf480pl if you look for weaknesses in the XML parsing, you can also do so after TLS has been established. What's the difference? Anyhow those concerns don't really move the needle in terms of overall security.