XSF Discussion - 2018-03-23

Sigh. How one should not design XMPP clients: https://github.com/KaidanIM/Kaidan/issues/220

Swift autoaccepts requests too, but only for bidirectional

(If you send a subscription request to someone, it'll approve the one they send back)

that makes sense

> (If you send a subscription request to someone, it'll approve the one they send back) Conversations does that too.

Even though that's actually what pre-approval is for

it makes sense in a world where subscription shouldn't consist of directed graphs

Or pre Auth

except pre-approval is not guaranteed

What ever that was called

yaxim will do both

But Swift doesn't talk about subscription requests, it just talks about Add Contact.

Did ejabberd start announcing that stream feature?

Because at some point it had support but didn't announce the feature which doesn't make sense this the RFC tells clients to only use it if the feature is announced

I wonder how many of my Swift issues got fixed for 4.0.

daniel: I'm using it anyway.

Ge0rG, you do know that prosody doesn’t support it?

jonasw: I know.

jonasw: but what's the worst thing that can happen if I send a pre-approval to a non-supporting server?

<malformed-request/> stream error.

Stream error

😂

ah, <invalid-xml/>

but it is valid xml. It just comes at the wrong time

Ge0rG, invalid XML is for things which do not pass schema validation

she-what? :P

granted, I’d argue that such a server would be pretty weirdly designed to begin with ✏

jonasw: auto-generated by the schema-to-code thing we talked about yesternight.

fg

Bad memory access (SIGBUS)

in attic there is missing version 3.0 and 3.1 of httpupload https://xmpp.org/extensions/xep-0363.html

there is no 3.0

or 3.1

do you mean 0.3.0 and 0.3.1?

(which are also missing, indeed)

I’ll regenerate them

yes i meant those

will be up shortly

thanks

spoiler: 0.3.1 is only a typo fix ;)

lovetox, will be available within the next five minutes

what funny attack can you do if you have newline chars in a header value

talking about httpupload

lovetox, escape from the header, depending on the brokenness of implementations involved

the authorizartion value is base64 encoded

this means i execute on that value .strip('\n')

not decode it and execute it on that

Correct

kk thanks

lovetox, that’s not sufficient

The client is not expected to understand what the headers are

.replace("\n", "") is safer

or if "\n" in header_value: raise RuntimeError("gtfo")

thats indeed better

i should just not upload to a service providing xep violating stuff

probably

ups strip is only for beginn and end, indeed that would not be enough

t

Http upload is a small security nightmare.

BTW, was there a change already restricting the legal header values?

> Requesting entities MUST ensure that only the headers that are explicitly allowed by this XEP (Authorization, Cookie, Expires) are copied from the slot response to the HTTP request. Ah, yes. But it's still not enforced at protocol level

I've applied this restriction to Psi

> MUST strip any newline characters I wonder whether "newline characters" is too vague, as it's implementation defined

has anyone tried (ab)using SOCKS5 Bytestreams https://xmpp.org/extensions/xep-0065.html to poke at internal network stuff?

there aren't any security considerations about it

Do you mean sending something w/o opening filetransfer session of something?

of traffic encryption

moparisthebest: but both parties connect to the server, the server doesn't initiate anything outbound

moparisthebest: you might be able to trick remote clients into such things tho

like, the server has access to a 10.X.X.X private subnet external users do not have access to, can an external client do bad things

yea that's another way to do it

You'd have to trick the client to connect to a "proxy" you defined

I forget the details, but doesn't one party pick the proxies, the other responds with one it can connect to.

I never knew the details, so...

interesting reading: https://irisate.com/crdt-for-real-time-collaborative-apps/

It feels like only yesterday when Operation Transformation was the best thing ever

You've gotten old.

*Operational

:(

Don't feel bad, I'll catch up soon.

i found this in gajim code

when creating TLS connection we pass a cipher list

'HIGH:!aNULL:RC4-SHA'

it this up to date?!

i have no clue about ciphers :/

If it's using a modern OpenSSL then I don't think you need to worry.

Only 'HIGH' seems to matter. Removing ciphers without authentication (aNULL) from the set of "highly secure" ciphers (HIGH) does nothing.

And RC4 doesn't seem to exist anymore.

Still, that doesn't seem like a good sign…

Zash: Unless things changed recently, HIGH does include aNULL ciphers.

Oh

Indeed

Hidden among all the various auth mechanisms that aren't used either

I'm more concerned that they would try to select RC4, regardless of whether it still exists in openssl or not.

$ diff -u <(openssl ciphers -v HIGH) <(openssl ciphers -v 'HIGH:!aNULL')|q https://q.zash.se/324a465c00bf.txt

on Debian Stable with OpenSSL 1.1.0f

SamWhited: It's pretty good compared to cipher lists like this: https://q.zash.se/da0ffe1f3f82.txt

What's that from?

Oooooooooold Jitsi

Possibly from 2013

https://blog.thijsalkema.de/blog/2013/09/02/the-state-of-tls-on-xmpp-3/

From those days

fun… Java things always seem to be behind.

huh, apparently RC4 was considered broken later than I thought

Defaults were pretty bad back then in most things.

Still though, if you're still recomnending it today that's a pretty big red flag for gajim…

Hasn't RC4 been considered "icky but let's not worry too much about it" since forever?

I was thinking it was late 2013, but apparently it was 2015 that the IETF stopped telling people to use it in TLS.

Comparing the current situation with that post would probably be interesting.