-
prezident
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
-
prezident
while it might not be helpful to just change current implementations i was just wondering how to interpret the rfc
-
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.
-
prezident
i am on the other side ;)
-
Link Mauve
You should tell your users to move to a non-abandonned library then. ^^
-
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
-
Zash
Why would it? What does it matter?
-
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
-
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 :|
-
Zash
> <message ... id="07d1636f-0e7e-4700-a6b5-edb12ff2ee6d-50B"><body>unicode thing?</body></message>
-
jonas’
ah yes
-
Zash
Is that ... poezio adding the id?
-
jonas’
yes, poezio does that
-
jonas’
or rather, sli x✎ -
jonas’
or rather, slixmpp ✏
-
jonas’
for reasons which are unclear to me
-
prezident
to identify the message...
-
jonas’
prezident, on *received* messages? ;-)
-
jonas’
that doesn’t make sense
-
prezident
yes, when reentering the room the client needs to know which messages it already showed to the user
-
prezident
which or what? whatever...
-
Zash
That doesn't make sense
-
prezident
it does
-
jonas’
I think we’re misunderstanding each other
-
prezident
or the client will save the same message again in its history
-
jonas’
slixmpp is adding IDs to messages it has received
-
jonas’
random IDs
-
prezident
and will display it one time more on every entering of the chatroom...
-
jonas’
since the IDs are added by the *receiving* client and independent of the content, there is no way this can be used for deduplication
-
prezident
oh sorry
-
jonas’
to make deduplication work, you have to add IDs on the sending client
-
jonas’
or the MUC service
-
Zash
Or somehow magically generate the same ID for the duplicate message again
-
jonas’
speaking of which, I’d like MUC services to add IDs to messages if the sending client didn’t.
-
Zash
Didn't we just add "server doesn't touch ids" as a feature?
-
prezident
jonas: mam adds an archive id to messages which fullfils this requirement
-
jonas’
Zash, yeah, but non-existent IDs aren’t IDs :)
-
Link Mauve
jonas’, +1, we should add that to MUC.
-
jonas’
prezident, requires the MUC to support MAM though, just for simple deduplication
-
Zash
Do it
-
Zash
Do it now
-
prezident
jonas’: of course a workaround only
-
jonas’
Zash, where do I get random IDs from again in prosody?
-
Zash
jonas’: util.id
-
prezident
but as this is only important for channels with history, isnt mam the right way to go anyway?
-
jonas’
you said that the other day, but I forgot
-
jonas’
thanks
-
prezident
"right" in the sense of best practice
-
Zash
jonas’: I'm wondering if the "medium" one should be closer to uuidv4 in entropy
-
jonas’
Zash, sounds reasonable
-
jonas’
Zash, https://paste.debian.net/hidden/69c1e82e/ ;-)
-
Zash
:)
-
jonas’
ah, it ate the tabs again
-
Half-Shot
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
-
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.
-
flow
1
-
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.
-
lnj
https://github.com/qxmpp-project/qxmpp/pull/174 https://github.com/qxmpp-project/qxmpp/pull/175 https://github.com/xsf/xeps/pull/730
-
oli
lnj: nice!
-
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.
-
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
-
Zash
Oh, it mentions SRP
-
Zash
Could do stuff with anonmous ciphers and sending some verifier in-band too.
-
Zash
pep.: I imagine the objection is that it's not perfect and you need to trust the server
-
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
-
Zash
Back when we had working Jingle VoIP and video chat
-
Zash
On phones!!!!1
- Zash shakes his N900
-
pep.
:D
-
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
-
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
-
pep.
Zash, thanks for volonteering!✎ -
pep.
Zash, thanks for volunteering! ✏
-
Zash
pep.: done. prosody already supports this ;)
-
pep.
You mean 247 + encrypted session?
-
Zash
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?
-
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?
-
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
-
pep.
Either that or I watch it again and quote it for you :/
-
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
-
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