XMPP Service Operators - 2021-09-20


  1. mimi89999

    Establishing a secure connection from emevth.no-ip.biz to lebihan.pl failed. Certificate hash: 8f290539741489af4dd385f82c0f285ebd77751f26c1d1d3112ee361b8dfd20b. Error with certificate 0: certificate has expired.

  2. Licaon_Kter

    The deadliest enemy...

  3. moparisthebest

    Dane and never expiring certs when

  4. rozzin

    moparisthebest: ... when?

  5. moparisthebest

    rozzin: how is tomorrow looking for you?

  6. rozzin

    moparisthebest: 😑️

  7. rozzin

    moparisthebest: TBH, I look forward to tomorrow with a sense of _existential dread_ more than anything, but the reasons for that our out-of-scope for this discussion... 😜️ What I meant was that I'm having trouble parsing and understanding your last line: "Dane and never expiring certs when". Like... was that a statement with a tail that fell off before it arrived?

  8. moparisthebest

    Ah, in response to a certificate expiring, I was lamenting that we could have permanently solved this problem already by moving to DANE pinning public keys and issuing our own certs with 100+ year expiry dates instead, but the whole public federation of XMPP servers would have to do it together hence the half-hearted "when" :)

  9. rozzin

    And then rely on certificate-revocations when the newbie server operators leak their keys 6 months in, I guess?

  10. rozzin

    And when they wholly abandon their "maybe a running a server would be fun!" ideas after a year or 5, shut down their hosting, let the domain lapse... and then don't even bother informing their users.... Actually, revocations don't happen in that situation, so. 🤷️

  11. rozzin

    Not sure the expiries with something like Let's Encrypt really help that latter situation either.

  12. moparisthebest

    No, the "valid certs" just live in DNS at that point so no revocations required

  13. moparisthebest

    TTLs apply as usual

  14. rozzin

    I should admit that I'm really not up to speed on DANE 😅️

  15. moparisthebest

    The only problem is entire TLDs are stuck in the past and don't support DNSSEC at all, the biggest problem of which for XMPP is .im -.-

  16. moparisthebest

    So everyone just needs to abandon their .im domains first, then we can have nice things :)

  17. Menel

    Do really all have to change at once? Can't the server software have a check for it implemented and allows the conventional method or DANE to establish a connection?

  18. rob

    I think it could, no reason we couldn't at support for DANE in a given server ahead of others. But would require still supporting regular certs too

  19. Menel

    Yes.. But its unlikely whole established networks change stuff like that on some effective date. Be it xmpp or http or whatever

  20. Menel

    So it must be both methods for some time and then after a long time discontinue the "legacy" method

  21. rob

    Permission to quit my job so I can do fun things like implement DANE support in prosody

  22. MattJ

    You mean https://modules.prosody.im/mod_s2s_auth_dane ?

  23. rob

    Oh neat 🤓

  24. rob

    But can I set two certificates, one used by the dane module and the other as default

  25. rob

    Or I guess you could just update the tlsa records when new certs are generated

  26. Martin

    Broke s2s to several servers when I tested it due to broken tlsa records.

  27. rob

    So a nice automated update method and fairly short TTL might be good

  28. rob

    But does the module allow fallback when dane isn't present?

  29. Licaon_Kter

    The key is under a fake rock near the backdoor, as usual.

  30. moparisthebest

    Yea existing servers can trust DANE today, but until they all or most do, no server can sanely avoid getting a letsencrypt cert all together

  31. jonas’

    are muc.tigase.im operators around?

  32. bung

    İs blabber mucs are close?

  33. neox

    bung, were you living in a cave the last few months? 🤔️

  34. bung

    No, ı say room

  35. bung

    Not server

  36. neox

    bung, well blabber mucs were on the blabber server, so ?

  37. neox

    bung, well blabber mucs were on the blabber server, so?

  38. bung

    > neox wrote: > bung, well blabber mucs were on the blabber server, so? No

  39. neox

    bung, what do you mean by "blabber mucs" then ?

  40. bung

    > neox wrote: > bung, what do you mean by "blabber mucs" then ? Blabber support and dev room

  41. neox

    bung, ok : as I said it was xmpp:blabber-dev@conference.blabber.im?join and xmpp:blabber@conference.blabber.im?join (so located on blabber.im server)

  42. neox

    These mucs are now down forever, and I don't know if there are new rooms elsewhere

  43. MattJ

    xmpp:support@room.pix-art.de?join

  44. MattJ

    Is the new support room for the app

  45. bung

    But not working with my Phone

  46. bung

    I people

  47. bung

    Resolved