XSF Discussion - 2020-06-19

Wojtek: ^

vanitasvitae: Stork + Siskin IM

It's not implemented in none of our clients (Siskin, Beagle, Stork)

Wojtek: - https://github.com/tigase/stork/blob/master/app/src/main/res/xml/features.xml - https://github.com/tigase/siskin-im/blob/master/SiskinIM/settings/server_features_list.xml

as you can see, this is complete list of XEPs without indication whether it's implemented or not...

vanitasvitae, it's not implemented. there's many things to fix in that XEP :(

should xep156 .well-known lookups over http be allowed? rfc6415 says so, but I think this is an issue, as an attacker could redirect you to a websocket endpoint under his control

I guess the question is how wss: certificates are validated by xmpp clients

I seem to recall to have read something about that in the websocket rfc

but I think most websocket libraries will use the name in the websocket url, and not the xmpp service name

I think it says you MUST use https for the well known lookup

1. As described in Section 4 of this document, the method for discovering a connection endpoint does not use DNS SRV records as in the TCP binding but instead uses Web-host Metadata files retrieved via HTTPS from a URL at the XMPP service domain. From a security standpoint, this is functionally equivalent to resolution via DNS SRV records (and still relies on the DNS for resolution of the XMPP source domain).

https://tools.ietf.org/html/rfc7395#section-6

yeah, but if websocket libraries do not "correctly" verify the certificate, then this is not comperable to (unauthenticated) DNS SRV RRs ✏

So you could do something like the SRV/DNSSEC thing, ie not accept a pointer to something other than ws(s)://maindomain.example/* unless the .well-known lookup is over https

Zash, right, but not sure if I like the complexity of this

Presumably wss://this.example must present a cert for dns:this.example

sure, but what if my xmpp service address is example.org and well-known delegates to wss://websocket.example.org

or http-non-tls looked up well-known delegates to wss://evil.attacker.org

of course if wss://evil.attacker.org presents a cert with dns:example.org it should probably authenticate, but given that websocket is somehow related to http, i would not be surprised if a lot of websocket libraries simply authenticate if a valid certifcate for evil.attacker.org is presented

Same problem as with an insecure SRV record pointing to evil.attacker.example

not really, we do authenticate using SAN there

http-non-tls for well-known is forbidden as per websocket spec, we can ignore that

because of exactly that issue

so no problem then

jonas’, ok, I still would not ignore it, as I was unable to find it

it should probably be mentioned in xep156

jonas’, also ref to the part of the spec pls :)

flow, https://tools.ietf.org/html/rfc7395#section-4 step 1

> 1. Send a request over secure HTTP to the path

ahh I thought you where referring to the websocket rfc

not the xmpp websocket transport binding rfc

oh sorry, yeah, I meant the xmpp-over-websocket rfc

the websocket rfc obviously wouldn’t know anything about the xmpp-specific well-known things

i still wonder if we should, at least recommend, https only well-known lookups in xep156

that sounds reasonable

can never hurt

and why rfc7395 does not use a normative 'MUST' to state that well-known must only be retrieved via https

moparisthebest <-> vanitasvitae

(cue Teamspeak 1.x "Link engaged" sound)

😀

wiki.xmpp.org has 1661 pages

git cloning mediawiki? :o

try that with wikipedia.org ;)