XSF Discussion - 2020-06-19


  1. Neustradamus

    Wojtek: ^

  2. Neustradamus

    vanitasvitae: Stork + Siskin IM

  3. Wojtek

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

  4. 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

  5. Wojtek

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

  6. pep.

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

  7. 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

  8. flow

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

  9. jonas’

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

  10. flow

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

  11. jonas’

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

  12. 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).

  13. jonas’

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

  14. flow

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

  15. flow

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

  16. 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

  17. flow

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

  18. Zash

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

  19. flow

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

  20. flow

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

  21. 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

  22. Zash

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

  23. flow

    not really, we do authenticate using SAN there

  24. jonas’

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

  25. jonas’

    because of exactly that issue

  26. Zash

    so no problem then

  27. flow

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

  28. flow

    it should probably be mentioned in xep156

  29. flow

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

  30. jonas’

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

  31. jonas’

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

  32. flow

    ahh I thought you where referring to the websocket rfc

  33. flow

    not the xmpp websocket transport binding rfc

  34. jonas’

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

  35. jonas’

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

  36. flow

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

  37. jonas’

    that sounds reasonable

  38. jonas’

    can never hurt

  39. flow

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

  40. jonas’

    moparisthebest <-> vanitasvitae

  41. jonas’

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

  42. vanitasvitae

    😀

  43. flow

    wiki.xmpp.org has 1661 pages

  44. flow is currently git cloning wiki.xmpp.org

  45. pep.

    git cloning mediawiki? :o

  46. flow

    try that with wikipedia.org ;)