hi, i am having a question regarding the correct use of starttls. i noticed that sleekxmpp just copies the response from the server, and the servers seem to accept that.
this leads to the following: s: <starttls><required/></starttls> c: <starttls><required/></starttls> s: <proceed>
is this the correct usage, or should child elements be disallowed at this stage?
current implementation also allows sending of arbitrary elements like <starttls><penis-required/></starttls>...
Zash
Lol
Zash
prezident: You're supposed to ignore everything you don't understand.
Link Mauve
prezident, most implementations don’t reject invalid attributes or children, but you shouldn’t rely on that.
prezident
well, the rfc only states <starttls/> on client side
prezident
does that leave room for interpretation?
prezident
ejabberd does reject a lot of invalid xml, but not that for example
frainzhas left
prezident
while it might not be helpful to just change current implementations i was just wondering how to interpret the rfc
frainzhas joined
Link Mauve
prezident, it’s definitely helpful to fix this library to only send what the RFC is asking.
Link Mauve
Note that SleekXMPP is kinda abandonned, and you should migrate to slixmpp at some point.
winfriedhas joined
prezident
i am on the other side ;)
Link Mauve
You should tell your users to move to a non-abandonned library then. ^^
!xsf_Martinhas joined
Holgerhas left
prezident
might be fixed already, who knows
prezident
the library wasnt my main focus really
prezident
i was more like wondering why no server rejects that
Zash
In the case of Prosody, it just doesn't really look that closely
Tobiashas joined
Zash
Why would it? What does it matter?
frainzhas left
frainzhas joined
neshtaxmpphas joined
prezident
i did not take into account that unknown child elements are not to be parsed
prezident
but at that stage, there really never are any children
Kev
Well, they're to be parsed, but unknown stuff is usually ignored.
Kev
Although technically that's meant to be stuff in unknown namespaces.
Zash
The code in question doesn't even inspect the payload. It gets triggered by the name and xmlns combo and does its thing
frainzhas joined
Kev
A server would be in its rights to reject that, because it's shoving stuff into a namespace it shouldn't be - but I'd be surprised to find many entities that did so, there's just no value.
Half-Shot
Hmm, I can't see prezident's messages.
Link Mauve
prezident, please write something.
prezident
kev: its a matter of how the parser is implemented
Link Mauve
Half-Shot, nothing should hide his messages from you, they are well-formed.
prezident
unicode thing?
Zash
message id attr?
prezident
miranda does not generate ids for groupchat messages
prezident
that could be it
Kev
prezident: All XML needs to be parsed, because malformed XML must be rejected.
jonas’
you also can’t really not-parse parts of the XML
prezident
kev: no i meant how you walk through the elements
jonas’
if you want to see what’s behind it
Half-Shot
Link Mauve: Okay, could also be a bug in xmpp.js :|
Ah, so I couldn't see `prezidents` message because the ID wasn't there/ wasn't unique and the bridge dedupes messages across it's users using the ID.
jonas’
it should not do that with live messages
jonas’
only with history messages
jonas’
(if at all)
Half-Shot
I'll stick on debug logging to be sure, but I'm certain I've seen the same message arrive for all the participants connected via the bridge.
Zash
Well, of course, each participant gets a copy of the message.
jonas’
you could pick a primary participant whose message view you treat as authoritative
mimi89999has joined
Zash
Skype bridge thing from back in the day had a magic user called "Skype" that was that primary user
Zash
Probably more correct to forward each message only to the occupant they're destined for
jonas’
that, too
Zash
Potential security issue if the MUC does things like security label based filtering.
Half-ShotXhas left
Half-ShotXhas left
j.rhas joined
404.cityhas joined
404.cityhas left
moparisthebesthas joined
moparisthebesthas joined
vanitasvitaehas left
vanitasvitaehas joined
Half-ShotXhas left
Half-ShotXhas left
Half-Shot_has left
APachhas left
intosihas left
Half-ShotXhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Half-ShotXhas left
andrey.ghas left
Half-ShotXhas joined
andrey.ghas joined
mimi89999has left
Half-ShotXhas left
Half-ShotXhas joined
lnjhas joined
Half-ShotXhas left
Half-ShotXhas left
flow
1
APachhas left
lskdjfhas left
lskdjfhas joined
neshtaxmpphas left
neshtaxmpphas left
Half-ShotXhas joined
alacerhas left
neshtaxmpphas joined
alacerhas joined
ThibGhas left
ThibGhas joined
Half-ShotXhas left
Half-ShotXhas left
alacerhas left
Half-ShotXhas joined
Half-ShotXhas left
Half-ShotXhas left
lnj
I was told to advertise this a bit, so also in this MUC: My MIX implementation in QXmpp has working parsing/serialization of most of what's in XEP-0369 and XEP-0405.
TIL https://xmpp.org/extensions/xep-0247.html, which seems like a cool idea. It references http://xmpp.org/extensions/inbox/jingle-xtls.html though, as in it references an /inbox/ XEP. Any idea what happened about it? Why it was not accepted etc.
Zash
And todays XMPP archeology subject is ...
Zash
> We assume that all XMPP entities will have X.509 certificates
hnnnm
Zash
I do wonder if something like SPK or SRP would work
Half-ShotXhas left
Zash
Oh, it mentions SRP
UsLhas joined
Zash
Could do stuff with anonmous ciphers and sending some verifier in-band too.
labdsfhas joined
Zash
pep.: I imagine the objection is that it's not perfect and you need to trust the server
frainzhas left
frainzhas joined
Half-ShotXhas joined
pep.
As a server admin, I would very much like to benefit from plausible deniability, if that can ever be a thing :)
Zash
https://mail.jabber.org/pipermail/standards/2009-January/020877.html is the only relevant thing I find from 2009
Zash
pep.: "I could plausibly have MITMed your Jingle" ;)
pep.
I know..
Zash
Is there even encryption for Jingle today?
Zash
In use?
pep.
I assume XTLS was an attempt at that, maybe the only one(?)
pep.
Anybody ever used ESessions?
Zash
There's https://xmpp.org/extensions/xep-0396.html but it's pretty new and I haven't heard about anything using it
pep.
https://xmpp.org/extensions/xep-0218.html
Zash
Maybe one time in 2008
frainzhas left
frainzhas joined
Zash
Back when we had working Jingle VoIP and video chat
Zash
On phones!!!!1
Zashshakes his N900
pep.
:D
labdsfhas left
labdsfhas joined
pep.
So yeah reading about XTLS and the first condition being to have an x509 cert, that's going to be meh
pep.
"typically self-signed and automatically generated by an XMPP client", and we come back to the same issues we have with verifying fingerprints
Zash
Yeah, that's kinda meh
Zash
You can do TLS without certs
pep.
But then what do you trust
Zash
You trust that the NSA is too lazy to MITM your cat pictures
frainzhas joined
Zash
Send some hash through the XMPP channel to the other party and verify it that way
Zash
Eg like the channel binding hash used in SCRAM-PLUS
pep.
https://www.youtube.com/watch?v=AsXKS8Nyu8Q
Zash
Then you get a channel should be about as secure as the XMPP path
since jingle is purely a client thing and all the server needs is to route iq stanzas :)
pep.
That's all client stuff right
pep.
pff
pep.
I knew there was a trick
jonas’
:D
Zash
One does not simply solve the key problem
Zash
If OMEMO or some other E2EE had full stanza encryption you could have bootstrapped secure XTLS over that
pep.
The thing here with clients negociating encrypted sessions is that we can't even use DANE-like things right?
labdsfhas left
jonas’
yes
pep.
Zash, then you trust that you OMEMO sessions is "Secure"
jonas’
you have to trust something
pep.
yes
pep.
Trust, a complicated story.
pep.
session*
Zash
There's DANE for S/MIME so it's not entirely irrelevant
pep.
I hear you should not use S/MIME anymore for emails at least, (following the efail things. https://media.ccc.de/v/35c3-9463-attacking_end-to-end_email_encryption)
jonas’
aren’t all the efail things broken cilents which will be fixed eventually?
Zash
Even if you manage to convince E2EE enthusiasts to trust DNSSEC...
jonas’
or is there something conceptually kaputt with S/MIME?
frainzhas joined
pep.
jonas’, I think there's a bit more to it, as in it doesn't include checksum or sth? Don't quote me on this, watch the talk if you have time
Zash
Everything is broken
jonas’
I don’t like "{watch,read,…} $thing" replies
labdsfhas joined
pep.
Either that or I watch it again and quote it for you :/
frainzhas joined
jonas’
hm
pep.
let me find the specific parts
Zash
jonas’: I looked at your message but I did not understand it
jonas’
pep., I’m going to be busy for the remainder of the day anyways
frainzhas joined
genofirehas left
genofirehas joined
frainzhas left
erkanfileshas joined
frainzhas joined
frainzhas left
frainzhas joined
labdsfhas left
labdsfhas joined
pep.
> S/MIME doesn't have a MAC (Message Authentication Code), which means it cannot detect by standards wether a message was changed or not
And apparently the Efail-related changes to S/MIME are:
> It is therefore recommended that mail systems migrate to using AES-GCM as quickly as possible
^ Efail CBC Gadget attack, and for direct exfiltration attack:
> Clients SHOULD treat each of the different pieces of the multipart/mixed construct as being of different origins.
So yes that's a client issue, but the guy says "You can just try to convince your email client not to do any external connection. [..] for a cryptographer, this means _broken_"
pep.
Apparently OpenPGP is a bit better in a way that it has MDC, Modification Detection Code, but not all keys do this. It was added as info on the key directly for backwards compatibility. And lots of keys don't. Also the standard was not entirely clear what to do with MDC errors, and would still pass the payload to clients