XSF Discussion - 2022-02-09

am I missing it somewhere or does the DNS method here have a giant security hole https://xmpp.org/extensions/xep-0156.html ?

you want to connect to example.org , _xmppconnect.example.org tells you to connect to wss://evil.com/xmpp , is that ok?

if you grab host-meta from https://example.org/ that doesn't have the same problem, also if you have DNSSEC on example.org you have no issue, but it doesn't mention either

Doesn't evil.com still have to present a cert valid for example.org like with normal SRV records?

that would be trustworthy, but XEP-0156 doesn't mention that as far as I see ?

and which domain do you send in SNI ?

I'm also unsure if XEP-0368 is correct in relation to SNI, if example.org 's SRV DNS response is DNSSEC signed and it says xmpp.example.org is the target, which name do you include in SNI ?

Is this the stuff in RFC7712?

moparisthebest, it's the same situation with unauthenticated DNS SRV RRs, isn't it? ✏

so you perform the authentication of the XMPP service the same way as you would if it was an unauthenticated DNS SRV RR that pointed you to wss://evil.com/xmpp

that is, check if the presented x509 certificate authenticates example.org

The only question is: do the available web clients do it correctly...

I wouldn't restrict that question to web clients, websockets are used by others too

never!

That said, we do a terrible job documenting best practices regarding authentication and authorization in XMPP

it appears, as moparisthebest already found, that the related information is scattered around multiple places

If I've time, I'll try to mitm conversejs later this day...

Converse.js doesn't do DNS TXT lookups

Was already doubting if it does, thanks for the info..

Hey Board, if one if you wants to be invited as Org Admin too just let me know

flow: with the additional wrinkle of SNI

Isn't SNI deprecated in favor of ALPN or so?

but in any case, SNI or ALPN, I don't see where the problem is?

What web server let's you configure the domain "evil.com" to be served when you send "example.org" in sni ?

No, both are used

so client wants to connecto to example.org, via some opaque mechanisms, he is told to connecto to foo.hosting.org via websocket

so without SNI/ALPN he would just check that foo.hosting.org presents a valid cert for example.org (assuming no DNSSEC was involed in the endpoint discovery) ✏

I don't remeber the details of SNI/ALPN, but isn't it like the client requests to talk to example.org when connectiong to foo.hosting.org? and the server at foo.hosting.org tries to present the correct cert with that information send by the client?

Right, but he has to request the right cert with sni, it's basically "give me the certificate valid for domain X"

Which if we pick the secure way, there is no webserver in the world that implements that

ok, but that's a common theme that most TLS thingies that aren't used by HTTP are not widely available in libraries

Doesn't alpn negotiate a protocol to be used over the encrypted connection, while SNI defines a target?

Yes

You use both today

Congratulations on giving OpenSSL responsibility of virtualhost and application dispatching

moparisthebest, FWIW this is an issue I've known about for a long time, and I thought it was just listed in the security considerations

I thought there had been previous discussion about it, but I can only find a lonely post from 2011 on the standards list, so... I don't know

the "issue" here is that websocket delegation is problemeatic because websocket servers are likely unable to hand out the correct certificate?

What libraries let you connect to https://xmpp.example.com/bosh and expect a certificate for 'example.net' ?

the libraries aren't as much of an issue as the servers, what server lets you host https://xmpp.example.com/bosh providing a certificate for example.net via SNI ? I'm fairly confident the answer is "none"

Wasn't this one of the things preventing proper SRV support in Thunderbird? NSS just couldn't have a different identity

we can handwave and put in some security considerations telling people to do what we know 0 servers are capable of but... :'(

sending a different name in SNI and Host: has a name, it's called domain-fronting, and apparantly XMPP invented it first :)

One name in SNI, a different name in Host:, a third name in <stream to=...>

(also google+amazon ban it from being used on their infrastructure, so anyone in AWS for instance)

so a related but different question, when you get XEP-0368 records over DNSSEC and can therefore allow *either of two* domains in the cert, which single domain do you send in SNI? :/

and if you send SNI: A, do you allow <stream to=B> ?

not specified !

moparisthebest, isn't that mentioned in DANE or DNA or somesuch?

hmm, will see

`SNI: xmpp.example.com._or_.example.com` :evil:

oh, one more thing about websocket, *if* we say send "example.org" in SNI instead of "evil.com", that means you have to have *different* websocket endpoints for DNS advertisement vs host-meta, because a web client certainly can't do that

Can't we just go full DANE, with raw public keys instead of certificates?

Zash, please !!!!

that would solve all problems forever

that's crazy talk!

anyway if someone wants to check if you can MITM gajim with a bad _xmppconnect record pointing to the wrong cert before I get to it let me know :) my guess is you can

badxmpp.eu?

but then, BOSH is specified as a proxy which in turn connects to the actual XMPP server, so you'd authenticate the proxy...?

yea I've been focusing on websocket but bosh has the same problem(s)

oh right, ws has an rfc

the RFC get around this by not specifying the DNS method, other than "look at XEP-0156"

> but the identity to be authenticated is the connection endpoint address instead of the XMPP service domain https://www.rfc-editor.org/rfc/rfc7395.html#section-6

utterly off-topic, but does someone know of a nice DIFF tool (maybe as a website) that is useful to compare two very long lines?

RIP the DNS method (unless DNSSEC) then?

Guus, `wdiff` ?

*because*: > delegation from the XMPP service domain to the connection endpoint address (if any) is accomplished via the discovery method described in Section 4. which only specifies host-meta and is secure delegation when https is used

yes, I unfortunately think the only answer is "_xmppconnect is insecure and cannot be used unless DNSSEC"

"or the host happens to have a single certificate and ignores SNI in which case go for it"

Guus: http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.3.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.8.3.html

But there are missing XEP-XXXX versions on xmpp.org

Guus: Example which works, here: http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.3.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.4.0.html

After several recalls, to have the following, I have done a ticket here about missing XEP-XXXX versions: https://github.com/xsf/xep-attic/issues/3 :) About the Diff tool: https://github.com/xsf/xmpp.org/issues/412, originally posted on the very old-dead tracker.xmpp.org JIRA issue tracker, I think 10yo.

Thanks Zash. Neustradamus, I have no clue what missing XEPs have to do with my request. It feels to me that you're trying to re-purpose my question to push forward your own agenda - exactly that what I asked you to stop doing.

Guus: The original is the diff website :) You must to compare XEP versions, and by extension, I speak about it

I didn't ask about comparing XEP versions at all.

You can compare RFCs, or all others too, it is very easy, I use often for many years.

That's nice. It is not what I asked for.

Guus: Sometimes I like a glass of water.

I'm going to get one myself...

☕️

other than gajim and pidgin, anyone aware of other clients using _xmppconnect ?

maybe I'll ask in jdev...

Tbh I was never really sure why we even have the DNS method in the first place. From a web client perspective it always seemed more natural to just do it over http

and if you have a client capable of doing DNS + TLS, well then it can also do https ?

There are other things than web clients

Which of those things can do DNSSEC but not HTTPS?

(oh, and you need HTTPS for BOSH anyway, so... it's pretty much certain you support it)

nothing can do DNS+TLS and *not* HTTPS, since that is just DNS+TLS

> (oh, and you need HTTPS for BOSH anyway, so... it's pretty much certain you support it) This

so I'm inclined to put a PR @ '156 to just remove the DNS method, with a note marking it existed, but was impossible to use securely

So why was it TXT only in the beginning?

Who has a time machine to go back to 2005 and ask?

IIRC it also had a fallback SRV alternative originally?

> so I'm inclined to put a PR @ '156 to just remove the DNS method, with a note marking it existed, but was impossible to use securely Well DNSSEC could become a thing one day. You know right after we roll out ipv6

But yes I'm in favor of removing it

So it was probably not expected to be used solely by web clients, and also CORS and such didn't exist at that point (flXHR was still cool)

yes, it's *only* possible to use securely with DNSSEC, which I'm a big fan of, but that pesky "in practice" thing

When was XHR even invented?

I think reducing the number of mechanisms in 156 is beneficial anyway

moparisthebest, removing a method completely, just because the ecosystem of implementations does not support it, seems a bit harsh. But given that it has a security implication, and that we suspect that there are already vulnerable implementations out there, it sure would be a good idea to mention that in the XEP

well author-wise I think we could probably reach 2 of them

It's already too much that it supports both XML and JSON encodings

Daniel, maybe if you make Conversations stop preferring IPv4 it won't look like nobody uses IPv6

MattJ, I was thinking that too but thought it might be too much :)

Currently we have a random selection of (DNS, JSON, XML) for every XMPP service

Some do all, some do some, some do none

So it's not like a client can just implement one method and just work

<strike>Dunno, I see the point in support both XML and JSON</strike> or maybe not ✏

and it's not like an operator can only advertise via one method and expect it to just work

Interoperability is decreased by having so many options, with little to be gained

let's recap, to make an XMPP connection, you must: 1. lookup 2 sets of SRV records 2. lookup 1 TXT record with DNSSEC 3. Grab+parse both a JSON and XML file over HTTPS 4. Grab+parse a JSON file over HTTPS for POSH 5. look up TLSA records over DNSSEC

I might have missed something...

Very possible :)

You forgot the other JSON file for POSH

oh right, POSH supports 2 different types of redirects right ?

🤷️

http redirects and also "url in the json file" redirects

and therefore 2 layers of TTL

https://www.moparisthebest.com/images/fine.gif

Wait, did you edit in POSH or were there too many lines for me to see the POSH in?

Hey let's throw DANE in there

no edit, I swear on the XML

I mentioned dane too, TLSA records :)

moparisthebest: Weren't you the one who pushed for the extra set of SRV records???!

and I'm about to push for another !

DANG IT

it's highly tempting to push for 1 connection discovery method that replaces all of these, but that's clearly XKCD territory

oh til that there is mod_posh for prosody

https://xkcd.com/927/

and I think there's aproximately 1 server in the whole universe that it can be used to authenticate ✏

99% of POSH deployments only have the client file

there is a server file?

shocked emoji

I've got c2s and s2s working over both QUIC and WebSocket by the way, that's what brought all this up

I really don't want 2 new methods to discover each but eh, it's hairy

could always resurrect https://xmpp.org/extensions/inbox/hacx.html as the One True Way (tm)

then add 3 more

moparisthebest, maybe for QUIC require advertisement through SVCB (wait, bear with me!) - and state that if SVCB records are present, don't do anything else??

what if your enterprise/university firewall block UDP port 443?

MattJ, yep, and SVCB could also advertise at least starttls and direct tls too

*maybe* websocket

Exactly

So a SVCB spec that combines as many of the existing steps as possible, and we keep '156/HTTPS for web stuff

yea I think that's the way to go for sure, downsides are SVCB is so new support lags behind, upsides are https needs it so that'll accelerate adoption :'(

https has its own variant, HTTPS

As a cynic I have to bet that HTTPS will become widely supported very quickly, while nothing will support SVCB

Zash, so obviously everything will only suppo... right

it's been too long since I looked at those, need to refresh

my current impl is using _xmppq._udp records like '368 but I really really don't want to spec that out in a XEP if it can be avoided at all

MattJ, but that's all right because you can get those records from Google / Cloudflare with DNS over HTTPS!!!111!!!

HTTPS all the way down 😭️

DNS is HTTPS, TCP is replaced by HTTPS, will the come for IP next?

also WebSocket is not coming to http3, it's being replaced by the new hotness, WebTransport

so obviously we'll need a XMPP-over-WebTransport also

also seen rumblings that WebTransport will replace WebRTC so that'll also be fun

https://w3c.github.io/webtransport/ https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

STAHP

update about _xmppconnect TXT record, a lot more things than I suspected use this, and so far, all of them are vulnerable to trivial MITM by DNS spoofing

modulo how trivial DNS spoofing really is

pretty trivial no ?

but https://datatracker.ietf.org/doc/html/rfc7395#section-4 defines a single way to grab an XML host-meta file, so I think I'll propose littering '156 with warnings and obsoleting it, I'll also create a summary on standards and will be filling 9000 github issues with links to it for the vulnerable projects

well whenever the mailing list gets back to me I'll respond with: https://github.com/processone/docs.ejabberd.im/issues/113 https://github.com/JustOxlamon/TwoRatChat/issues/2 https://github.com/poVoq/converse_wp/issues/2 https://github.com/BombusMod/BombusMod/issues/130 https://github.com/hesa2020/Twitch-To-League-by-Hesa/issues/1 https://github.com/xmppjs/xmpp.js/issues/933 https://github.com/tigase/tigase-http-api/issues/8 https://github.com/tigase/tigase-extras/issues/3