prezidenthi, 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>...
ZashLol
Zashprezident: You're supposed to ignore everything you don't understand.
Link Mauveprezident, most implementations don’t reject invalid attributes or children, but you shouldn’t rely on that.
prezidentwell, the rfc only states <starttls/> on client side
prezidentdoes that leave room for interpretation?
prezidentejabberd does reject a lot of invalid xml, but not that for example
frainzhas left
prezidentwhile it might not be helpful to just change current implementations i was just wondering how to interpret the rfc
frainzhas joined
Link Mauveprezident, it’s definitely helpful to fix this library to only send what the RFC is asking.
Link MauveNote that SleekXMPP is kinda abandonned, and you should migrate to slixmpp at some point.
winfriedhas joined
prezidenti am on the other side ;)
Link MauveYou should tell your users to move to a non-abandonned library then. ^^
!xsf_Martinhas joined
Holgerhas left
prezidentmight be fixed already, who knows
prezidentthe library wasnt my main focus really
prezidenti was more like wondering why no server rejects that
ZashIn the case of Prosody, it just doesn't really look that closely
Tobiashas joined
ZashWhy would it? What does it matter?
frainzhas left
frainzhas joined
neshtaxmpphas joined
prezidenti did not take into account that unknown child elements are not to be parsed
prezidentbut at that stage, there really never are any children
KevWell, they're to be parsed, but unknown stuff is usually ignored.
KevAlthough technically that's meant to be stuff in unknown namespaces.
ZashThe code in question doesn't even inspect the payload. It gets triggered by the name and xmlns combo and does its thing
frainzhas joined
KevA 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-ShotHmm, I can't see prezident's messages.
Link Mauveprezident, please write something.
prezidentkev: its a matter of how the parser is implemented
Link MauveHalf-Shot, nothing should hide his messages from you, they are well-formed.
prezidentunicode thing?
Zashmessage id attr?
prezidentmiranda does not generate ids for groupchat messages
prezidentthat could be it
Kevprezident: All XML needs to be parsed, because malformed XML must be rejected.
jonas’you also can’t really not-parse parts of the XML
prezidentkev: no i meant how you walk through the elements
jonas’if you want to see what’s behind it
Half-ShotLink Mauve: Okay, could also be a bug in xmpp.js :|
Half-ShotAh, 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-ShotI'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.
ZashWell, 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
ZashSkype bridge thing from back in the day had a magic user called "Skype" that was that primary user
ZashProbably more correct to forward each message only to the occupant they're destined for
jonas’that, too
ZashPotential 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
flow1
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
lnjI 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.
pep.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.
ZashAnd todays XMPP archeology subject is ...
Zash> We assume that all XMPP entities will have X.509 certificates
hnnnm
ZashI do wonder if something like SPK or SRP would work
Half-ShotXhas left
ZashOh, it mentions SRP
UsLhas joined
ZashCould do stuff with anonmous ciphers and sending some verifier in-band too.
labdsfhas joined
Zashpep.: 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 :)
Zashhttps://mail.jabber.org/pipermail/standards/2009-January/020877.html is the only relevant thing I find from 2009
Zashpep.: "I could plausibly have MITMed your Jingle" ;)
pep.I know..
ZashIs there even encryption for Jingle today?
ZashIn use?
pep.I assume XTLS was an attempt at that, maybe the only one(?)
pep.Anybody ever used ESessions?
ZashThere'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
ZashMaybe one time in 2008
frainzhas left
frainzhas joined
ZashBack when we had working Jingle VoIP and video chat
ZashOn 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
ZashYeah, that's kinda meh
ZashYou can do TLS without certs
pep.But then what do you trust
ZashYou trust that the NSA is too lazy to MITM your cat pictures
frainzhas joined
ZashSend some hash through the XMPP channel to the other party and verify it that way
ZashEg like the channel binding hash used in SCRAM-PLUS
pep.https://www.youtube.com/watch?v=AsXKS8Nyu8Q
ZashThen you get a channel should be about as secure as the XMPP path
pep.Zash, thanks for volonteering!
pep.Zash, thanks for volunteering!
Half-ShotXhas left
Half-ShotXhas joined
Zashpep.: done. prosody already supports this ;)
pep.You mean 247 + encrypted session?
Zashsince 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
ZashOne does not simply solve the key problem
ZashIf 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*
ZashThere'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?
ZashEven 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
ZashEverything 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
Zashjonas’: 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
XSF Discussion - 2019-01-05