XSF Discussion - 2024-05-08

  1. moparisthebest

    I found the answer in theory is https://datatracker.ietf.org/doc/html/rfc7627 but in practice it's probably "tls-unique is not safe" I sent my thoughts to the mailing list... tl;dr I think '440 should be deprecated

  2. emus

    nicola: yes please go.ahead

  3. Menel

    Isn't the fix to not allow a certificate change during renegotiation, then it is fine?

  4. moparisthebest

    Menel, the way I understand it, both the attack on renegotiation and tls-unique is a result of the "bad" server (mitm) being able to create another TLS connection with the same master_secret with the real server, and just pass things along so the "fix" for both renegotiation and tls-unique is the same, don't continue a TLS handshake that is vulnerable to the above, but if the server doesn't support it (or a mitm lies and says they don't support it), you *cannot* do tls-unique or renegotiation because it is not secure

  5. moparisthebest

    in practice none of the major XMPP clients have any idea at all whether their TLS lib supports the extended master secret extension, and it's likely near-zero of them could enforce it or fail the connection, and therefore none of them should be using tls-unique (or, they can use it, but it provides literally zero security/mitm protection)

  6. moparisthebest

    dino is going to be dynamically linked to whatever old gnutls happens to be on the distro, gajim same-ish deal (unsure what exact library it uses) conversations and forks are going to be using 999999 different buggy TLS implementations that all depend on android version iOS clients are going to be using... SecureTransport on old versions and forked+hacky libressl on newer ones I think? I would bet 0 clients implement TLS 1.2 tls-unique securely today, and I would bet 100% of TLS 1.3 tls-exporter clients are vulnerable to the MITM simply not offering it... or offering only tls-unique or something like that

  7. moparisthebest

    *if* a client decides it can securely do TLS 1.2 tls-unique it should just always do it, asking the attacker whether and how you should try to detect them is never a good idea

  8. moparisthebest

    rustls is probably the state of the art TLS lib, and it documents this specifically, implements the extension, but even it doesn't say anywhere I can find whether it's mandatory or not https://docs.rs/rustls/latest/rustls/manual/_02_tls_vulnerabilities/index.html#3shake

  9. moparisthebest

    ah even rustls defaults to false for requiring extended master secret https://docs.rs/rustls/latest/rustls/client/struct.ClientConfig.html#structfield.require_ems RIP

  10. moparisthebest

    TIL tls-unique was broken a different way later in 2015 with XMPP specifically called out as a vulnerable implementation https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/message/ZLEH3O62JKOLFLWUKYPTFSZAXJ4CI2Y2/

  11. singpolyma

    > *if* a client decides it can securely do TLS 1.2 tls-unique it should just always do it, asking the attacker whether and how you should try to detect them is never a good idea Well it's a TOFU style situation right? You only ask once :P

  12. moparisthebest

    singpolyma: says who? Not '440 at all

  13. singpolyma

    well, says common sense and implementation experience. But also: https://xmpp.org/extensions/xep-0474.html

  14. moparisthebest

    you aren't supposed to need "common sense and implementation experience" to securely implement a security standard, if you do, it's not a good standard and needs fixed

  15. asdfasd

    I am looking for a tiny / simple (php) webchat support solution, any ideas?

  16. moparisthebest

    asdfasd: https://conversejs.org/ maybe?

  17. Guus

    asdfasd: have a look at the Workgroup Queues XEP. Openfire's FastPath and the Converse client implements that, iirc.

  18. asdfasd

    I was just on the converse.js asking, they told me probably it will not work when the user reloads the browser. I used fastpath in the past, but that is a bit to much for my current requirements. I am looking for something like this https://www.livechat.com/ (if you click this chat button) But without everything just writing directly with visitor. Don't even need email or so

  19. flow

    thanks for migrating the XSF MLs to hyperkitty. are the old archives anywhere?

  20. flow

    ok, this could be misunderstood, I think its really great to have mailman 3, but I wonder if the old archives are still there

  21. Guus

    flow: I believe that the old archives are lost in a hardware failure.

  22. moparisthebest

    Most of them are on web.archive.org though

  23. flow

    uh, we had a major hardware failure? and no backups? that totally went under my radar

  24. Guus

    flow, that might have been... two years ago?

  25. singpolyma

    many but not all lists were on https://www.mail-archive.com/

  26. singpolyma

    eg https://www.mail-archive.com/standards@xmpp.org/

  27. MattJ

    I don't think the old archives are lost, we had backups

  28. MattJ

    But they are not compatible with mailman3

  29. MattJ

    In addition to this, I think there is a gap because after we got mailman3 running I don't think archiving was enabled for (some/all?) lists

  30. singpolyma


  31. singpolyma

    there is definitely a gap

  32. singpolyma

    (that gap is filled by mail-archive for lists that were already set up there before though)

  33. Guus

    I stand corrected.


    > Guus: > I stand corrected. Was scrolling in my XMPP roster and i cannot for the life of me figure out WHY i misread this as "I stand circumcised" ???