as you can see, this is complete list of XEPs without indication whether it's implemented or not...
bearhas joined
neshtaxmpphas left
neshtaxmpphas joined
Wojtekhas left
moparisthebesthas left
moparisthebesthas joined
neshtaxmpphas left
neshtaxmpphas joined
andrey.ghas left
mukt2has joined
Yagizahas joined
mukt2has left
stpeterhas joined
stpeterhas left
andyhas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
murabitohas left
mimi89999has left
mukt2has joined
mimi89999has joined
murabitohas joined
mukt2has left
mukt2has joined
alexishas left
waqashas joined
mukt2has left
mukt2has joined
lovetoxhas joined
alexishas joined
archas left
archas joined
lovetoxhas left
emushas joined
stpeterhas joined
neshtaxmpphas left
werdanhas joined
lorddavidiiihas joined
wurstsalathas joined
werdanhas left
winfriedhas left
winfriedhas joined
jcbrandhas joined
winfriedhas left
winfriedhas joined
stpeterhas left
paulhas joined
pep.
vanitasvitae, it's not implemented. there's many things to fix in that XEP :(
mukt2has left
mukt2has joined
citizenzibbhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
Guushas left
Guushas joined
winfriedhas joined
archas left
archas joined
sonnyhas left
sonnyhas joined
Alexhas joined
Mikaelahas joined
j.rhas left
j.rhas joined
sonnyhas left
sonnyhas joined
waqashas left
karoshihas joined
marchas left
karoshihas left
karoshihas joined
stpeterhas joined
mukt2has left
sonnyhas left
sonnyhas joined
j.rhas left
karoshihas left
karoshihas joined
karoshihas left
karoshihas joined
karoshihas left
mukt2has joined
robertooohas joined
archas left
archas joined
sonnyhas left
sonnyhas joined
archas left
archas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
j.rhas joined
stpeterhas left
karoshihas joined
Steve Killehas joined
archas left
archas joined
karoshihas left
Mikaelahas left
Mikaelahas joined
govanifyhas left
govanifyhas joined
karoshihas joined
archas left
archas joined
mukt2has left
mukt2has joined
debaclehas joined
debaclehas left
debaclehas joined
karoshihas left
lskdjfhas joined
karoshihas joined
sonnyhas left
sonnyhas joined
karoshihas left
Abbehas joined
karoshihas joined
Shellhas joined
Dele Olajidehas joined
karoshihas left
karoshihas joined
Nekithas left
Nekithas joined
Shellhas left
Shellhas joined
marchas joined
Nekithas left
archas left
archas joined
Nekithas joined
archas left
archas joined
Shellhas left
Shellhas joined
archas left
archas joined
mukt2has left
archas left
archas joined
mukt2has joined
karoshihas left
karoshihas joined
Dele Olajidehas left
Shellhas left
Shellhas joined
stpeterhas joined
karoshihas left
karoshihas joined
Shellhas left
Shellhas joined
stpeterhas left
Nekithas left
karoshihas left
karoshihas joined
emushas left
emushas joined
mukt2has left
Nekithas joined
karoshihas left
karoshihas joined
mukt2has joined
andrey.ghas joined
andrey.ghas left
karoshihas left
Nekithas left
bearhas left
mukt2has left
Nekithas joined
karoshihas joined
Nekithas left
thorstenhas left
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
Nekithas joined
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
thorstenhas joined
mukt2has joined
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
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
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