XSF Discussion - 2024-03-30

Do C or Dino support "jingle file requests"? I.e. senders='responder'

or does any client worth mentioning

or any client in the history of anything ever

If what you ask is https://xmpp.org/extensions/xep-0234.html#requesting then yes.

Yes for C and Dino?

Yes, you can use this tool to search for xeps in software https://xmpp.org/software/?platform=all-platforms It's not complete for all that exist, but very nice

Not parts of xeps...

?

The extensions table at https://xmpp.org/extensions/ now offers a filter for dormant XEPs in Experimental/Deferred. States are indicated by icons (with tooltips) as well. Feedback welcome!

cal0pteryx: looks excellent! Thanks!

Now this surfaces deferred XEPs that actually matter

flow could probably ask Council to issue a Last Call for 0440 (channel binding)

cal0pteryx, if there is a turtle icon, it might be more clear than the clock :)

kurisu: i think no, but I am planning to implement it

cal0pteryx, a suggestion: have the type filters as one dropdown, and "Views" as another; views can then be "All", "Consider Advancing", "Implementations Needed", etc, and further interesting views can be added as wanted

kurisu: it depends a lot on what you are trying to achieve. Requesting a file can be useful for resuming a file transfer

(and maybe a threshold of >=2 before advancement)

Daniel: does C do that?

I might implement it but considering how rarely jingle ft is used it doesn't have priority

kurisu: no

So I thought

Is there a place where we can see what's the state of SASL, and especially SCRAM mechanisms support in the clients and servers ?

No. I would absolutely love to have metrics for that. But my users would hate that sort of thing

Too bad. Movim is supporting SCRAM-SHA-1 and PLAIN, I might drop plain support and I can add a few others but I was wondering about the servers support.

I mean implementing other shas is really easy . Just go for it. Doesn't hurt ✏

Yeah sure.

Someday OPAQUE

Aside from Dino and C, does anyone support webrtc file transfer? Web clients perhaps?

Not yet.

It's very new

And I think no one supports the tcp xep yet

> Too bad. Movim is supporting SCRAM-SHA-1 and PLAIN, I might drop plain support and I can add a few others but I was wondering about the servers support. edhelas: don't drop plain, that's the best one ! seriously though it's useful for deployments where the password is stored with a good hash (like scrypt) and used across services ↺

The old Observatory had SASL stats

Doesn't matter, my password is CorrectHorseBatteryStaple in the end

According to a German newspaper Mb2.r5oHf-0t is the most secure password, so everybody should use it.

https://www.der-postillon.com/2014/04/sicherstes-passwort.html ✏

That's the combination to my luggage!

> Is there a place where we can see what's the state of SASL, and especially SCRAM mechanisms support in the clients and servers ? Maybe o.j.n could ask for opt-in to collect those informations? I would opt-in.

That's still only a part of the network but we could at least gather some numbers for servers. ✏

jonas’: ?

mdosch, no, the code isn't smart enough to query features like that.

Too bad. 🙃

well, SCRAM mechanisms are collected, actually, but no SASL2

Why would it matter? For MUCs it's not used, for signing up for a public server you don't care because you 100% need to use a random password unique to that server

Having login mechanism stats would be nice though. I'm strongly considering making channel binding quasi mandatory in a not too distant future

Perhaps it could be addded to CAAS?

Does channel binding work with PLAIN ?

No

moparisthebest: no. You need scram

That would break my XMPP setup then which would be sad

Am I missing something or does channel binding offer nothing over just pinning keys?

Mitm detection

Both catch mitm where the mitm gets a new valid cert, neither catch mitm where the mitm can read the server's disk

LE really doesn't want you to pin keys though

You can't pin certs, you can pin keys no problem

But yes I'm aware that PLAIN won't go away for certain deployments. But I'm ready to have them dig into some expert setting and disable the 'mitm protection checkbox'

How about also implement pinning keys and then require one or the other since they offer the same protection?

We got DANE for DNSSEC enabled domains and host-meta-2 for everyone

You can have channel binding with PLAIN if you switch to FAST afterwards, right?

> You can have channel binding with PLAIN if you switch to FAST afterwards, right? Yes. But then you can be downgraded to plain again I guess

The nice thing about channel binding is not that it's perfect but that it is really low hanging fruit for the vast majority of users that use scram anyway

you mean developers? i dont think any user cares about such details

they probably care after they get MITM'd

Sure, and the nice thing about pinning keys is it's out of band, you can cache it, and gives you extra assurance over just channel binding So why not both? :)

lovetox: yea users definitely prefer not to be MITM'd

moparisthebest, sure, go tell certbot to stop rotating private keys

I'm not against key pinning. Channel binding works on the first connect

And what Zash said

moparisthebest, yes i completely agree, but how do you follow from that, they actively *want* some very specific feature in a TLS connection, and how is it low hanging fruit for *them*

The likelihood of detecting something like the Jabber.ru attack gets drastically improved for virtually no cost

Zash: I assume certbot has a flag to not rotate keys? Regardless there are many good acme clients that don't

moparisthebest, you assume users (well, admins here) change defaults?

Isn't that the entire premise behind prosody? No one turns on a prosody and leaves defaults

No true scottish config file?

> moparisthebest, sure, go tell certbot to stop rotating private keys That's what I do already.

Adding a bunch of modules and your hostname isn't too far from telling certbot your hostname and accepting the defaults.

Since plain will not go away completely, it seems like anyone can still do what they want. So I don't understand the argument.

I disabled plain on my server and all clients continued to work, so YMMV.

moparisthebest, wait why aren't you excited about moving to OAuth 2.0 and OAUTHBEARER? then a web browser becomes required for authenticating and your real client never sees your password, that you type into a web <form>

Gross

> I disabled plain on my server and all clients continued to work, so YMMV. mdosch: clients aren't the problem it's that my XMPP server's usernames & passwords are shared with other systems, email, nextcloud, nginx etc ↺

> Both catch mitm where the mitm gets a new valid cert, neither catch mitm where the mitm can read the server's disk Wromg. Tls-exporter channel binding can catch the attacker even if they use the same cert and key as the legitimate server (and key pinning can not)

tmolitor: if you can read the disk of the server you are MITM'ing, you can get the TLS cert, key, and database of usernames and password hashes, and then do the entire tls-exporter between you and the client and then between you and the real server, right?

So I think channel binding can protect against nothing more than pinning keys can

Why not both ™

That's what I said :)

Operationally more effort to pin keys, rotating and recovery etc gets more complicated.

> tmolitor: if you can read the disk of the server you are MITM'ing, you can get the TLS cert, key, and database of usernames and password hashes, and then do the entire tls-exporter between you and the client and then between you and the real server, right? moparisthebest: No, TLS exporter uses the handshake between client and server and that is different even if the adversary uses the same key and cert....

> moparisthebest, wait why aren't you excited about moving to OAuth 2.0 and OAUTHBEARER? then a web browser becomes required for authenticating and your real client never sees your password, that you type into a web <form> You can do oauth without a web browser 🙂 but we've reinvented oauth now and call it fast instead ↺

Tls-exporter will detect a mitm as soon as there is more than one TLS connection on the path to the server (the definition of mitm)...the tls-server-end-point will not catch the mitm in the same-key scenario though, only tls-exporter will (but tls-server-end-point would have catched the jabber.ru attacker as key pinning would have)

singpolyma, but oauth is not about auth(entication) but auth(orization), FAST just gets you token authentication, no?

tmolitor, I think moparisthebest has constructed a scenario where it's arguably not MITM anmyore, but you authenticate to the attacker.

Zash: oauthbearer is authentication with a token, surely

singpolyma, true. how you get that token is more involved tho

Yeah. I mean you can get it however you like but there are some common and sometimes complex ways, i agree

and the ways that do not involve a web browser are all deprecated and considered insecure

>> tmolitor: if you can read the disk of the server you are MITM'ing, you can get the TLS cert, key, and database of usernames and password hashes, and then do the entire tls-exporter between you and the client and then between you and the real server, right? > moparisthebest: No, TLS exporter uses the handshake between client and server and that is different even if the adversary uses the same key and cert.... tmolitor: right, and if the attacker read your disk to get your cert and key and usernames and password hashes, you'll succeed in doing TLS exporter with the attacker's server, who can then succeed in doing it with the real server ↺

Is that really MITM anymore?

Yes?

> tmolitor, I think moparisthebest has constructed a scenario where it's arguably not MITM anmyore, but you authenticate to the attacker. Even then scram with channel-binding (in fact even without channel-binding is superior to key-pinning because scram contains a server proof that it knows the password (which the attacker won't know)...all of this is of course only true if the client does not fall back to PLIN, though)

moparisthebest: yes, knowing the password hashes enables the attacker to fake the server-proof of the password and the mitm will succeed...

tmolitor: in your scenario where the attacker reads the server disk to get the key, they do know the password, they know everything your server knows

Yes

So... Channel binding provides *no more* protection than key pinning...

Certainly a full box pwn is not defensible ✏

Congratulations on your irrefutible proof that security is impossible.

But that's not the typical mitm but a direct attack on the server followed by a mitm like impersonation...

> Congratulations on your irrefutible proof that security is impossible. Classic blue team ↺

tmolitor: I think the point is that without such a full pwn key pinning also is sufficient to defend

Better dust off my very smol screwdrivers and get back to repairing mechanical clocks.

Roughly you should always do key pinning if you can and always do channel binding if you can

Though I agree both is good

> So... Channel binding provides *no more* protection than key pinning... No, that's wrong...your claim is only true in the case that the attacker has access to the server's disk...then both of them offer the same security: exactly none

tmolitor: correct, how else would they get your private key though

Becasue we no longer care about all the more likely scenarios where the attacker isn't also your infa provider?

Maybe we need a flag for the server to instruct the client to pin the key

I mean that worked well for HTTP

> tmolitor: I think the point is that without such a full pwn key pinning also is sufficient to defend No it is not, key pinning does not detect if the mitm knows the servers TLS key but not the password hash...

> Maybe we need a flag for the server to instruct the client to pin the key Sure, it's called TLSA record ↺

> Maybe we need a flag for the server to instruct the client to pin the key > > I mean that worked well for HTTP It worked that well that they removed that feature from browsers :(

>> Maybe we need a flag for the server to instruct the client to pin the key > Sure, it's called TLSA record And host-meta-2 ↺

tmolitor: I think it's back again with http 3 maybe. But yes

> Sure, it's called TLSA record Surely in moparisthebest scenario, the attacker also owns the DNSSEC root keys and can issue any TLSA record they want! ↺

>> Sure, it's called TLSA record > And host-meta-2 Please no ↺

Yes, I'd love to see tlsa support in clients...

>> tmolitor: I think the point is that without such a full pwn key pinning also is sufficient to defend > No it is not, key pinning does not detect if the mitm knows the servers TLS key but not the password hash... I agree, now how could this possibly happen? I don't think it can ↺

tmolitor: I have it

>> Sure, it's called TLSA record > Surely in moparisthebest scenario, the attacker also owns the DNSSEC root keys and can issue any TLSA record they want! If your DNS server is also your xmpp server I guess so ↺

Great, my server has it too, even with rolling keys...

> Yes, I'd love to see tlsa support in clients... Dito

Daniel: I can send you a PR 😉

Now when are all the .im servers going to change domains? That's easy in XMPP right? 💀

moparisthebest: it can...the same cert and key are frequently used on different servers or services...attacking one of these servers/services will give you the key, but not the password hashes

moparisthebest: I have most of a workaround for that

singpolyma, bringing back lookaside-validation? :)

Even heartbleed would have given you the key but not the password...

Zash: either better or woreise depending hiw you feel but similar

tmolitor: people copy keys between servers? 😱

> Daniel: I can send you a PR 😉 I need to fix my DNSSEC implementation first

singpolyma: how do you work around it and is it better than host-meta-2 🤣

Daniel: i upgraded to latest of your DNS dependency and it's working well so far

moparisthebest: the .im service has to srv to a different tld and then I have a list of well known srvs to check against for that step, normal DNSSEC after

Works for yax.im

singpolyma: wait that sounds like you are enabling trivial MITM for it?

How?

What if evil DNS server responds with "use DNSSEC from evil.com to get the TLSA for yax.im" ?

Then it won't match my well known srv list so won't verify

Can you link to the code or a doc or something?

It's in both certwatch and cheogram-android. Its obviously not ideal because it only works for known services, but I still think that's better than nothing

singpolyma: but then server admins won't be able to change their srv entries to point to another domain...

tmolitor: right. They can change IPs and TLSA and stuff, but if srv changes it'll stop verifying.

> tmolitor: people copy keys between servers? 😱 Yes, some people do that. Or use the same cert for different services on the same host...

So its essentially srv pinning

Same cert for multiple services on the same box is fine though, that's what I do :P

singpolyma: is it one list or a list per host? Anyway still not a generic solution that works across clients/servers or for all services on .im like host-meta-2

Definitely not generic but a generic solution isn't possible

host-meta-2 can't be used for key pinning on .im either

How would you even fetch the host meta file safely?

host-meta-2 explicitly can be used to pin for .im and everything, you grab it over https

And how do you pin the https key?

With good domains, Dane/TLSA, with .im you don't, it's still a big improvement

So with .im it's identical to no key pinning. Like I said

Not at all

You get some sort of 'TOFU by LE

You're banking in what, an attacker who can mitm xmpp but not https?

None of this https stuff beats the jabber.ru hack ✏

Proper dane does, no?

MITM'ing your personal DNS right now: easy MITM'ing LE's DNS across multiple geographically and provider seperate systems months ago: very hard

> None of this https stuff beats the jabber.ru hack Zash: it does with long enough pinning times, actually even with 1 day people would have noticed day 1 their login stopped working ↺

MITMing HTTP-01 just in front of the machine: Easy, and then serving whatever pinned key you want over https is equally easy.

moparisthebest: if I can trust an LE cert then I dont need pinning at all. The whole pont is i cannot

HTTP-01 and then waiting a month doesn't make it harder

> MITMing HTTP-01 just in front of the machine: Easy, and then serving whatever pinned key you want over https is equally easy. This ↺

> MITMing HTTP-01 just in front of the machine: Easy, and then serving whatever pinned key you want over https is equally easy. Not possible when your caa record forbids http-01 ↺

Rure, if you want to trust LE that's fine but then pinning isn't needed

> moparisthebest: if I can trust an LE cert then I dont need pinning at all. The whole pont is i cannot singpolyma: trusting one *now* (from anywhere you might connect) is much different than trusting one you got weeks/months ago ↺

It would have prevented the jabber.ru one for example

How could it possibly?

There is no "perfect" here, it's all layers that make it slightly better

It would do nothing in the jabber.ru case

singpolyma: people who had already connected would have had the key pinned and not trusted the new key

What?

They check the host meta and see a new key there

So use new key

Or check host meta and see both the old and the new, possibly varying depending on targeting.

If DNS MITM is so easy, just do it to the CAA record. It's probably hosted on the same infra as the VM anyway.

singpolyma: you don't grab the host-meta after the mitm because you already have it cached (TTL) so you fail to connect

Until the ttl expires

Sure, but that's enough to instantly detect the MITM