jdev - 2023-10-22

the channel binding thing that was mentioned, only works of course if the client is save against downgrading attacks

not exactly sure how that needs to be done, tell the user once the server does not offer scram+ anymore?

and then let him decide?

Someone mentionned https://xmpp.org/extensions/xep-0474.html which lists various options (and introduces some new ones, but even without that part is an interesting read)

btw, does this mean if i implement this, my client will not operate anymore in company networks that do this kind of proxy mitm stuff?

so, actually one would need to make this optional and user would need to activate it

this XEP outlines a few attacks, but i dont really see the benefit of trying to do more on the protocol side

i simply pin the mechanism, and inform the user if it changes

should be fine, and much easier to implement ?

that's the "Case 4" in that xep, you can decide if the possible problems listed there are acceptable or not (if your first connexion is compromised/degraded, you now notice a problem only when you connect to the correct server ; and, if the server is updated to introduce new, stronger types, you won't use them and will keep using the older pinned one)

lovetox, yeah, there are definitely situations where channel binding would be expected to fail - some corporate/educational networks for example, and the user may prefer being able to communicate with an acknowledged MITM than not being able to communicate at all

Such situations would likely be where the network has a custom certificate already installed on the device trust store

MattJ, currently Gajim does not support channel binding

is this XEP-0440: SASL Channel-Binding Type Capability

widley supported?

and can i assume that every server supports tls-unique?

there is also this server-end-point thing

somewhere i read server must support tls-unique

so no need as a client to implement server-end-point, right?

so i can i simply implement tls-unique for TLS 1.2 and exporter for TLS 1.3?

do i really need to parse the type capabilities of the server ?

lovetox, tls-unique is only for use with TLS 1.2, which is not common these days. If you have the choice, only support tls-exporter for future-proof code

server-end-point is compatible with both, and may be used by some deployments that have intentional "MITM" devices such as load balancers

Less common setup, but they will exist

The problem is that SCRAM doesn't tell you which one the server is using, and if the client and server pick different ones, it will fail

It's a flaw in SCRAM really, but XEP-0440 fixes it

The HT token mechanisms we use in FAST encode the channel binding method in the mechanism name

Zash: the dane srv rfc suggests that "sni or equivalent" (and explicitly mentions xmpp stream to) be set to the target name not the service name. Since this would mean the server actually has no idea what service you're talking about i assume you just ... Don't do this?

The testing tool I'm forking seems to use target name for actual sni and service name for stream to. So it can work for at least startssl but probably breaks direct tls...

singpolyma, yeah that part is weird

singpolyma: in the case of DNSSEC validated records you basically need to try connecting twice for each SRV record, once for each SNI name...

That sounds annoying

It is, but it's all I've got :)

There's no "right" choice when it comes to SRV records, no way to signal which SNI to use, and non-dnssec clients can only use 1

My solution for this is to abandon srv records for a well-known https GET which does have what-to-send for SNI defined :'(

I mean, the only choice that can possibly work is service name. That's just unfortunately the opposite of what the rfc suggests

The server doesn't serve any services at the hostname so using that for SNI would just return an error

SNI is for picking certificates, something else is for picking services, in HTTP that's the Host: header

You can have two ways sure, though the rfc intentionally tries to include them rll by saying "or sni like thengs such as XMPP stream to"

But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service

Also given what we recently had confirmed about the fragility of TLS CA trust I'm even less ok with https based discovery than i used to be

Move over to SVCB?

It's extensible so we can jam *everything* into it. A+AAAA+DANE+port numbers etc

That's the problem though, in theory yes, in practice we'd need to define our own type (like https did) and then try to get DNS hosts to support it and it'd never happen

> But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service Really? Strange, I just have one wildcard cert per server ↺

> Really? Strange, I just have one wildcard cert per server That'll come in handy if that cert is ever compromised, it'll be useful for so many attacks on all kinds of services! ↺

> Also given what we recently had confirmed about the fragility of TLS CA trust I'm even less ok with https based discovery than i used to be It's ok because the HTTPS connection is protected by DANE and/or HPKP ↺

>> But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service > Really? Strange, I just have one wildcard cert per server I have dozens of domains on my server though ↺

> You can combine multiple hostnames into a single certificate, up to a limit of 100 Names per Certificate. I had to look this up, anyway that's enough for 50 domains in 1 cert

Anyway, I think it's mostly up to the protocol and so we can just do it right. It's just awkward that the rfc uses us as an example

I added my server fqdn to all my certs as part of this, and then I see the rfc says to ignore the name on the cert 😂 ah well, it's not bad to have in case someone else misses that part

MattJ, that means server-end-point works on TLS 1.3? ✏

ah you already said that

lovetox, it works on anything, but you basically need XEP-0440 to know that the server supports it

tls-unique is mandatory to implement, but "not defined" for TLS 1.3, which is awkward

The new rfc makes tls-exporter the new mandatory I think

Hey Guus, does Openfire / the Java TLS stack you use support either of those channel binding methods?

IIRC tls-server-end-point is the only one feasible in many environments due to limited access to the bits needed for the others

I haven't read about server-end-point yet .. is there a chance i could do it from web? Heh (i assume still no, but who knows)

It's a hash of the certificate

singpolyma, https://stackoverflow.com/a/50484642 suggests you could do it from an extension...

> servers MUST and clients are RECOMMENDED to at least implement the channel-binding type tls-server-end-point Hrm, Prosody does not, never finished that :/

To date, Openfire does not support any kind of channel binding. I've raised an issue for that earlier today: https://igniterealtime.atlassian.net/browse/OF-2694

tls-server-end-point is so awkward, you don't only need the certificate, you need to know what signature algorithm the certificate uses

plus certificates are replaced more often these days

Isn't the algo recorded in the certificate?

Yes

So just access to the PEM/DER blob is insufficient, you need to parse it.

This wasn't originally available to Prosody

And now Prosody supports tls-server-end-point ... I hope

damn, implemented whole channel binding stuff

Congrats :)

and then when i call in GLib get_channel_binding_data()

it simply secfaults :D

Sounds about right :)