XSF Discussion - 2024-05-08

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

nicola: yes please go.ahead

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

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

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)

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

*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

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

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

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/

> *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

singpolyma: says who? Not '440 at all

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

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

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

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

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

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

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

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

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

Most of them are on web.archive.org though

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

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

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

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

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

But they are not compatible with mailman3

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

correct

there is definitely a gap

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

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" ???