-
Neustradamus
Wojtek: ^
-
Neustradamus
vanitasvitae: Stork + Siskin IM
-
Wojtek
It's not implemented in none of our clients (Siskin, Beagle, Stork)
-
Neustradamus
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
-
Wojtek
as you can see, this is complete list of XEPs without indication whether it's implemented or not...
-
pep.
vanitasvitae, it's not implemented. there's many things to fix in that XEP :(
-
flow
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
-
flow
I guess the question is how wss: certificates are validated by xmpp clients
-
jonas’
I seem to recall to have read something about that in the websocket rfc
-
flow
but I think most websocket libraries will use the name in the websocket url, and not the xmpp service name
-
jonas’
I think it says you MUST use https for the well known lookup
-
jonas’
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).
-
jonas’
https://tools.ietf.org/html/rfc7395#section-6
-
flow
yeah, but if websocket libraries do not correctly verify the certificate, then this is not comperable to (unauthenticated) DNS SRV RRs✎ -
flow
yeah, but if websocket libraries do not "correctly" verify the certificate, then this is not comperable to (unauthenticated) DNS SRV RRs ✏
-
Zash
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
-
flow
Zash, right, but not sure if I like the complexity of this
-
Zash
Presumably wss://this.example must present a cert for dns:this.example
-
flow
sure, but what if my xmpp service address is example.org and well-known delegates to wss://websocket.example.org
-
flow
or http-non-tls looked up well-known delegates to wss://evil.attacker.org
-
flow
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
-
Zash
Same problem as with an insecure SRV record pointing to evil.attacker.example
-
flow
not really, we do authenticate using SAN there
-
jonas’
http-non-tls for well-known is forbidden as per websocket spec, we can ignore that
-
jonas’
because of exactly that issue
-
Zash
so no problem then
-
flow
jonas’, ok, I still would not ignore it, as I was unable to find it
-
flow
it should probably be mentioned in xep156
-
flow
jonas’, also ref to the part of the spec pls :)
-
jonas’
flow, https://tools.ietf.org/html/rfc7395#section-4 step 1
-
jonas’
> 1. Send a request over secure HTTP to the path
-
flow
ahh I thought you where referring to the websocket rfc
-
flow
not the xmpp websocket transport binding rfc
-
jonas’
oh sorry, yeah, I meant the xmpp-over-websocket rfc
-
jonas’
the websocket rfc obviously wouldn’t know anything about the xmpp-specific well-known things
-
flow
i still wonder if we should, at least recommend, https only well-known lookups in xep156
-
jonas’
that sounds reasonable
-
jonas’
can never hurt
-
flow
and why rfc7395 does not use a normative 'MUST' to state that well-known must only be retrieved via https
-
jonas’
moparisthebest <-> vanitasvitae
-
jonas’
(cue Teamspeak 1.x "Link engaged" sound)
-
vanitasvitae
😀
-
flow
wiki.xmpp.org has 1661 pages
- flow is currently git cloning wiki.xmpp.org
-
pep.
git cloning mediawiki? :o
-
flow
try that with wikipedia.org ;)