XSF Discussion - 2018-02-14

Flow, there was the argument that identities may be localized.

I changed my email address. Does anyone know who should I get in touch with to subscribe myself with my new email address, please?

Seve, to all lists but members@, you can manage that yourself

I’m not sure if you can change your email address for members@ yourself

you could try checking the options at https://mail.jabber.org/mailman/options/members/your.old@email.address

Ohh

(note the email address in the URL)

Sorry!

I forgot to mention that I want to subscribe to members@, yes.

ha ok

I don’t know who’s responsible for this, but somebody from iteam will do

the two I have in mind aren’t here right now though

I'd like to propose a new marketing slogan: *XMPP - as popular as the Metric system in the USA*

:<

jonasw: it could be worse, e.g. "XMPP - as popular as the Measles"

:<

oh my god

I’m just reading XEP-0013

why did it seem like a good idea to use disco#info for the number of messages?

-13 is pretty old, we've got a lot of best-practice knowledge that's built up since then.

Kev: I'll remember that.

-13

jonasw: pretty old, we've got a lot of best-practice knowledge that's built up since then.

What the smeg?

hah!

:D

jonasw, ok, so why an extra hash for localized identities?

Flow, separating them so that entities can profit from their cache for features and forms

(also, there are precedents for quickly-changing forms)

(e.g. the number of users in a MUC in its disco#info)

What does "localized" in this context mean? "translated"?

in such a quickly-changing-form-case it would be profitable if entities could opt-out of the forms hash to indicate that it is quickly changing and must always be considered stale.

that sounds like an argument for an extra hash for forms

yes

question is if separation of identities makes sense, too.

but I still don't see the advantage of an extra hash for localized identities

given that the identities will not frequently change

I don’t see it either, necessarily

SaltyBones, yep, usually it's about the xml:lang attribute

are there many other popular precedents for quickly changing forms?

Flow, I don’t know, honestly

that’s why I *wish* there was more feedback on this on-list

I was going to write yesterday, but then figured that I possibly don't know what it is really about

so I need to make it clearer?

jonasw, dunno, it appears you also don't know an example where extra hashes for identities, feature and/or forms are beneficial

for forms, the MUC case is rather beneficial; the current workaround which is used is that the form wtih the numebr of users is not included when answering disco#info for a caps node

besides when protocols come into play that put dynamic information into e.g. features

which is bad

and in many cases, entities might not be interested in the form data, which is almost alwyas supplementary

thus making them miss the cache because of uninteresting form data is not totally great

(for example, entities which put OS version into the disco#info data; you’d then build a cache where each release of every operating system on which the client runs is held, which is kind of not very useful to have in the first place)

I’m not sure there’s a strong argument for separating identities, but separating forms seems appealing to me

I hoped that zinid would comment on this since he told me about the MUC forms use case.

hmm I see/saw caps mostly as an instrument to discover the caps of a remote "client". I can't even tell from the top of my head if caps works with xep45: Do you get a presence from the MUCs bare JID?

If ecaps2 is missing something, then it is possibly a mechanism for clients to annouce their features even if they are offline (e.g. via PEP)

XEPs should mandate a list of intended use-cases.

SaltyBones, don't they?

Flow, recent developments make you get a presence from the bare MUC jid on join, yes

that’s a result of summit

jonasw, is that xep45 change live already?

it is being developed and evaluated against client implementations

jonasw, ok, i guess it's part of the multi nick sharing initiative

Flow, no, it’s part of the avatars for MUCs initiative :)

and knowing the disco#info of a MUC is probably useful

from what I know till now, I don't feel that it is worth separating the hashes. Instead we should consider adding a best practice to xep30 that disco#info results are supposed to be not short-living

Flow, how are you suggesting to fix the xep45 use-case then?

also, short-living isn’t the same as high-cardinality, whihc is also an issue

(as in the OS Version case)

jonasw, the os version case is not xep92?

but yes, you are right, it's not the same, i'm not sure if high-cardinality is an issue and if it needs fixing

softwareinfo

same is true for xep45, I possibly could live with an cold caps cache every time an occupant leaves or joins

hm, we could test that, we have a huge repository of caps data

I think I’ll do that :)

jonasw, sorry, softwareinfo?

https://xmpp.org/extensions/xep-0232.html

that one

I had to google the namespace myself

uh, i forgot that we have an update to xep92, would be great if there where a pointer from xep92 to it's possible successor

Flow, the issue is that caps cache should be persistable; defeating that because we’re spamming the databases with pointless updates/minor differences is kinda sad.

but sure, I’ll run a test on the capsdb

jonasw, but is it an issue?

it’s a bit dated, but probably a good source of a first estimate

Flow, that’s what I’m going to find out

hmm not sure if xep232 is really an improvement over xep92

Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim

marc: I'm keeping the Intent and re-firing its handler after account creation

what does that mean? you can add people who don't have an account??

Ge0rG: what if multiple activities are involved before you can re-fire it? Do you pass it to all the activities?

SaltyBones, XEP-0401

-xep-0401

> Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim Conversations does that as well

marc: the only flow allowed is "main activity [optional: prefs activity ->] main activity"

SaltyBones, -xep 0401

SaltyBones, {xep 0401}

SaltyBones: Easy User Onboarding (Standards Track, Experimental, 2018-01-25) See: https://xmpp.org/extensions/xep-0401.html

there we go

daniel: really? What version?

Not with the entire uri though. Just the jid. But that could be changed

marc: dunno. Maybe 1.23.0

Bunneh is b0rked

Ah okay, because I need the full URI

yeah changing that is probably fairly easy

Okay, I'll take a look

marc, did you write this XEP?

Anyway, good stuff.

And of course as always thanks to Ge0rG for all his efforts in this direction!

SaltyBones, Ge0rG also did lots of stuff

SaltyBones: yes

SaltyBones: 🙇

So I've installed kaidan, and it is _very_ basic

it is

seems to be a pattern

The CADT pattern.

Oh, I've installed 0.2.3 from their repo, github has 0.3.2

Well, it is relatively new, so...

https://github.com/KaidanIM/packages/issues/1 :|

Seve: 0.3 was a significant change

also half a year of development between the releases.

So Kaidan reflects the general status of XMPP very well.

6 months between releases is not long, or what are you saying? :)

MattJ: I'm saying that having 6 months old DEBs on their own repo is really bad.

You can deploy QT to iOS?

Some Qt pars, yes

Qt Quick GUIs you can

Does GTK have something similar?

no clue

Tobias, this https://doc.qt.io/qt-5/qtquick-index.html ?

yes...that stuff works across desktop and ios/android platforms

huh...nice

"works"

oh...

it lacks quite a few things/controls, it is a pain to use with C++ and I think you’ve got to do accessibility quite all by yourself

but I haven’t looked deeply into the last part

Gosh, Gloox. There's a blast from the past.

Indeed

jonasw: I think the impact from http upload might be comparable to dns rebinding attacks

Ge0rG, the local servers thing is a point

so I’d suggest to add a reference to CWE-918 in the security considerations and write that clients need to treat themselves as HTTP Proxies w.r.t. security considerations

maybe we can find HTTP documents which elaborate on those

jonasw: with newlines, the attacker can forge any payload to the http post

daniel, ^

Ge0rG, but we agreed to reject newlines.

jonasw: I'm not saying it's impossible without newlines

Yes the newline thing doesn't need debating anymore

daniel: good luck finding out what is "on the LAN"

Ge0rG: any of the reserved IP ranges I mean

Gets you into trouble in enterprise deployments

Ge0rG, "unless the server is in a LAN"

that’s by the way similar to the application boundary enforcement NoScript does by default…

nightmare

jonasw: yay for complex filtering rules!

Ge0rG, that wasn’t my idea

Ge0rG, do you have a better solution, considering that some services will need headers for authn?

(and authz)

and we can’t predict the header names reasonably?

By the way the exploiting your plastic router scenario is kinda independent of the header discussion

Those are usually exploited by get parameters anyway

daniel: indeed. Having PUT instead of POST does us a favor here.

daniel: besides, it's easier to exploit things via POST than via GET, but most browsers block cross-origin-POST

And then, the HTTPS certificate requirement should effectively protect typical LAN routers.

Ge0rG, why is PUT different from POST in this case?

Ge0rG, assuming your $10 router distinguishes between the different methods :-)

but those are all mitigations

daniel: touché

"Let's use HTTP because it's simple"

Flow: most HTTP appliances use POST for form submission, not PUT

yeah, XMPP is way simpler

Ge0rG, browsers don’t block cross-origin post unconditionally; I know that you can cross-origin POST with a <form/> for example

stop it now! I'm just reading Jingle-FT and it's gruesome.

jonasw: good point. Does that make all HTTP POST endpoints exploitable?

Ge0rG, that’s why we have CSRF tokens

I love those.

Let's add an CSRF token to HTTP-Upload.

I whish we had a magic marker which tells us when ge0rg is serious nor not

Flow: I wish I had such a marker myself.

what is the original document you guys are discussing?

SaltyBones: XEP-0363

-{XEP 0363}

-xep363

SaltyBones: also https://mail.jabber.org/pipermail/standards/2017-November/033936.html

hmm

-xep-0363

-xep 363

MattJ: HTTP File Upload (Standards Track, Proposed, 2017-12-03) See: https://xmpp.org/extensions/xep-0363.html

Ge0rG, what's your issue with Jingle FT?

Tobias: it's an overengineered horrible mess

Tobias: I can only hope that all of the complexity comes from the domain and not from Jingle-FT itself.

Ge0rG, in what way? what bit is in there that's not needed to get peer-to-peer file transfer working in all cases

the complexity likely comes from the problem domain

WebRTC is similarly complex

Tobias: except WebRTC also has proper NAT traversal and e2ee ;)

I think both Jingle and WebRTC have room for improvement when it comes to reducing the complexity. But I doubt that it's going to happen, because their deployment reached the critical mass

Ge0rG, Jingle has E2EE too (not sure what the current state of the xep is)

"Experimental"

Flow: "horrrible"

WebRTC has decent e2ee? I thought it's e2ee was MITM-able

or maybe "abandoned"

It has E2EE if the signaling channel is protected

marc: ITYM if the server is trusted.

Maybe this is controversial but I think 0363 should NOT allow "unlimited other headers" at most it should allow one or two specific ones but imho none would be more appropriate.

SaltyBones, but there are services which require headers

integration with those services was the goal of the update which introduced headers

Why doesn't the server just take the data and the put it wherever it belongs?

HTTP-Upload headers are the XHTML-IM of this year's compliance suite.

SaltyBones: because traffic and scalability

Ge0rG, you’re exaggerating

Ge0rG, what's your opinion on XEP-0385?

For once I disagree about the complexity. The trade off seems justified here, without the headers you can't have auth or signed URLs

Ge0rG: not exactly, you could use OMEMO to protect the credentials

So, why doesn't the server simply communicate the URL it passed to the client to whoever actually gets the data?

SamWhited: I'm only slightly serious, but I'd like to hear your input on how a malicious server could abuse http-upload to wreak havoc

a malicious xmpp server

I want to make sure that a client can't upload unlimited stuff, but the http server is on another host and knows nothing about the xmpp server. How can I do that without some way for the client to also communicate with the http server? I could maybe shove one or two things in the path, but that's going to get ugly quick

mostly I just want to use s3 directly though, which requires auth headers.

SamWhited: so instead you opt for making the client a generic protocol proxy?

(a generic XMPP->HTTP proxy)

It's nothing close to that, it has to support http to do a post anyways, so you're just telling it how to structure its request

SamWhited, this is exactly what proxying is

I was flabbergasted when Ge0rG said that first, but I think he’s right.

in the end what the client is here is a proxy supporting PUT with arbitrary headers to an arbitrary HTTP(S) host with an arbitrary URL

the only thing the server can’t control is Content-* and the body

this sounds dangerously close to a semantic argument, so sure, it's a simple proxy without the complex body bits. that seems fine.

SamWhited: I'd argue that we have a whitelist of HTTP headers that the module is allowed to override/set.

SamWhited, isn't that impossible? The client has to request a slot from the XMPP server and must include the filesize and the receiving host must validate that filesize. They have to communicate, right?

SaltyBones: they don't *have to*, the HTTP server can be independent

SamWhited, SaltyBones, mod_http_upload_external for prosody essentially includes an HMAC of the content size and file name into the PUT URL query which is verified by the peer.

but other, already existing things require HTTP headers to do that ✏

Ge0rG: what benefit would a white list provide?

SamWhited: we would severely limit what a malicious server can do via the client-proxy.

SaltyBones: upload servers often need things at point of upload, eg a bearer token.

Ge0rG: I see, that seems fair.

SamWhited: have a look at http://blog.portswigger.net/2017/07/cracking-lens-targeting-https-hidden.html#host for how to abuse an HTTP proxy to access non-HTTP protocols

Seems like nobody is reading my emails :>

I'm reasonably sure this isn't actually a problem here, but I'd be interested in trying to come up with a POC. Will read that when I get to my desk

SamWhited: tl;dr: if you can inject raw multi-line text into requests to custom ports, you can own many text-based protocols.

oh, well yah, headers have to be sanitized

I'm pretty sure that SMTP looks sufficiently close to HTTP to be able to send an email just by passing a long list of custom headers ;)

I’m not so sure

or does SMTP use colons everywhere?

jonasw: MAIL FROM: foo RCPT TO: bar

ew

but can you add spaces to HTTP header names?

jonasw: it depends™

Ge0rG: but you can't pass a data and a dot

As mentioned earlier

it also uses mime like headers, yah. But that's an easy fix.

That being said, I agree it's going to be a problem.

Actually, no I don't. I need to be at my desk to test this, but I'd be suprised if most http libraries allowed invalid requests that way.

The attack vector here relies on the users server or a component being malicios too, but part of xmpps security model is that you have to trust your server, so it botheers me less, though if we can mitigate it without too much trouble that seems fine.

/thinking-out-loud

spling is herd

SamWhited: I tend to agree with what you say, but having such a reverse proxy in a corporate network will surely ring some compliance bells.

I doubt it, but I'lk ask our compliance person when I get to the office

Who are these people who want to put their http upload data on a different machine but cannot be bothered to give it an interface which can check urls with HMACs and why should we care about them? :p

SamWhited: I'm also not sure that all http libraries properly sanitize headers.

SaltyBones: amazon cloud was called out

We didn't use it at HipChat for this reason if you need a real world example.

Also S3 gives you 5 gigs of free storage or something, but the bandwidth to proxy it is not free.

Well, in all fairness I'm not sure that it would fit HipChats use case anyways, but it was immediately discounted because there was no control over requests

and they wanted total control or would some kind of "provide this token" have been sufficient?

SaltyBones, headers, obviously, because the server had full control over the URL all the time

We needed the ability to set auth headers, I think. Can't remember if we needed other stuff for signing or not, seems like that didn't end up making it to the final thing.

SamWhited: so can we agree on a whitelist of "Authorization" and "Cookie"?

and _maybe_ "X-*"

Ge0rG, also, what is the issue we’re seeing here by the way?

the only real issue is with network boundaries, isn’t it?

and the possibility for the malicious XMPP server to disguise itself behind the HTTP upload-ing clients

otherwise the XMPP server could carry out the attacks themselves

and with much more precision

jonasw: yes.

maybe… if it's not actually a problem a white list seems like it will just be ignored by half of clients and end up causing interoperability problems. We should try to prove that it is, or is not, a problem first in my mind.

so if there is stuff which breaks from unauthenticated plaintext being sent, I’d be inclined to argue that the stuff which breaks is at fault

+1 SamWhited

I still think trusting the server is okay too.

that too

(even though the server might be in an entirely different trust domain than the network the client is on)

SamWhited: if we make it a closed whitelist, we can just provide according xmpp elements for each header name

SamWhited: so that clients can't make dumb errors.

Ge0rG, for all X-* headers? ;-)

(blanket-allowing X-* is a bad idea though, IMO)

jonasw: this is why I wrote "closed" :P

jonasw: yes, blanket-allowing X-* is bad. But less bad than blanket-allowing *.

A whitelist makes the feature next to pointless, if the point was to allow arbitrary 3rd-party upload protocols

that

Agreed.

Ge0rG, I’d argue that an overly-open whitelist is worse than "*"

A blacklist is worthless as well, due to the complexities and lack of standardization of HTTP.

Also agree.

If we're really worried, we can solve it by just ("just") having the client enforce the same same-origin policies a browser would

MattJ, you mean "none"?

MattJ: awesome idea. because same-origin works so well on HTTP already?

POST/PUT can be sent cross-domain

Ge0rG, imagine a world without it

jonasw, since when?

MattJ, at least with <form/>

MattJ: a world without cross-origin scripting? It would be great!

jonasw, ah, but you can't send custom headers that way, at least

so we need to disable custom headers in 0363. QED.

MattJ, true

for not-same-origin?

not-same-origin will ~always be the case with s3, won’t it?

CNAME

does that work?

with Host header etc.?

.oO(CNAME and set Host header. bazinga)

Yes, you can serve any domain from S3 with the right configuration and DNS records

the problem with CNAME will be one of HTTPS certificate validation

Amazon handles this for you, not an issue

MattJ, amazon maybe, but $non-amazon-cloud-provider object storage?

do we want to pin people to amazon with that rule?

I'm in no way an expert on the matter but https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy clearly says "Cross-origin writes are typically allowed" and https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest has a function "XMLHttpRequest.setRequestHeader()"

You're not pinning them to Amazon - any provider can use Let's Encrypt for example, if you point a CNAME at them

MattJ, yes, but I bet not many do

jonasw, this is not a protocol problem

MattJ, yes, but .....

Delegating to a third-party is something people (rightly) want to do. It can be done.

do we need to make it harder for people?

So it seems to me, like what we are trying to prevent, can be accomplished with JS in a w ebsite...

They don't have to do this, it's optional

hmm, this seems sensible at first glance. It does limit what you can do with the upload, but it does seem desirable from a security standpoint and the drawbacks aren't that severe. It moves the place you define trust to DNS, which is how xmpp does things anyways.

but same origin doesn't protect you if your own server is bad

hmm

they could just point a cname to 192.168. something

you have to trust your own server anyways

SamWhited, in that case the whole discussion is moot and we can just allow arbitrary headers!

daniel, +1

SamWhited, the entire debate is about not trusting your server

Can somebody tell me why what we are trying to prevent is NOT something that JS on websites can do?

In other words, something that is "somebody elses problem".

daniel: pointing a cname to 192.168.x.x won't give you a valid certificate.

SaltyBones: modern browsers will use CORS to prevent cross-origin POST/PUT

SaltyBones: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS > Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method

Ge0rG, CORS is a way so circumvent the SOP and the SOP is what I quoted above as not protecting you against cross origin writes...where is the error?

SaltyBones, because you read "typically" as "always"?

jonasw, but this is enforced in the browser not per site, right?

SaltyBones, https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests > In particular, a request is preflighted if any of the following conditions is true: > * If the request uses any of the following methods: > * PUT

It's enforced in the browser. In our discussion, the XMPP client is in the place of the browser

I think that is pretty clear

so SaltyBones, if e.g. your plastic router instructs the browser to reject cross-origin POST requests, it would be safe with modern browsers.

but it would not be safe against HTTP-Upload

MattJ: so we need to mandate the XMPP client do an HTTP OPTIONS call to the server and to check CORS

Ge0rG, noooooooooooooooooo

> 13:19:49 MattJ> "Let's use HTTP because it's simple"

I'll -1 the XEP until this is mandated, or until I'm kicked out of Council.

I think that’s the right course of action anyways.

MattJ: you are not.

303 Pull the other one

Ge0rG, what about my "if a thing breaks by unauthenticated plaintext, it is that things fault"?

jonasw: talk to a BigCorp CSO and explain that to them, and how their "trusted core network consisting of the datacenter and the office network" must be fixed yesterday.

SamWhited, my feeling is that "trust your serevr" is not applicable here, because this is a different level of privilegue. I trust my XMPP server to handle my IM, but I wouldn’t trust it with remote code execution on my client. Likewise, I’m not sure I’d trust it with "arbitrary" network access.

Ge0rG, why the hell would you allow people to run XMPP clients in your trusted core network?

or any not thoroughly audited software for that matter

if it’s so crucial to your operations and there’s no additional layer of authentication except being in that network.

jonasw: because Gajim portable and Direct-TLS on :443

don’t allow removable drives?

don't allow The Internet?

on the same note, why would you allow people to accsss the intenet at all from that network. you’re doing it very wrong in that case.

yeah

You're alreadytrusting that by virtue of connecting to a thing in an srv record.

SamWhited, but it can’t control what contents I send there, except for its domain name

and even that it can’t really controll

while HTTP Upload does let it control a substantial part of the content I send

fair

so, strawman proposal: what about we make a disco#info form or something which tells the client which headers will be used by a given upload service. They can then decide whether to use that service at all (before showing in the UI that an upload would be possible, thus improving UX in the "no, that’s not okay" use case). And then clients can keep their own whitelist, while we recommend a whitelist in the XEP which contains Authentication, Cookie, Cookie2 (maybe?), and whatever S3 needs

jonasw: please don't.

mention the trade-offs clearly in the security considerations, too

Ge0rG, why not?

jonasw: the client can't decide that, and the user even less so.

how can we decide what the client can’t decide?

jonasw: the client can't decide anything.

Ge0rG, it's hard to follow your arguments when you don't provide an explaination

I’m fine with allowing any header then, I think. Most havoc can be wreaked (on the web side, which is why we have CORS etc.) due to cookies

and existing sessions

which isn’t applicable here

Flow: which argument do you want explained?

Ge0rG, why can't the client decide which headers to use or not?

Flow: because client developers are already incapable to securely implement IQs, Carbons and XHTML-IM. I'm a full-time IT security consultant and I have a hard time figuring out which HTTP headers might have malicious side-effects.

Flow: a client doesn't know if it runs in a "secure network" of some sort

got it, thanks

Ge0rG, could you name one header that can cause bad side effects? (something that couldn't be done with the URL)

(assuming the headers are stripped of \n which I already agreed to)

daniel: sending a mismatching `Host` header will confuse middleboxes.

a `Connection` header might at least confuse the server, causing a small DoS

a middle box that mitm https?

daniel: yes, that's a common setup at BigCorps

We could also require an Origin header to be set to the HTTP-Upload component name, cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Origin

But this is less strong than any enforced filtering

Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself"

Let me jump in an propose a jingle-ft component on the server to counter http-upload :-°

both Connection and Host would typically be set by the client (one due to how the lib works, one from the URL)

pep., do it

jonasw: "typically"

> Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself" that by the way i'm fine with and i'm actually implemting this in Conversations right now

jonasw: do you know from memory which HTTP headers are set by your favorite http client library? And which of those can't be overridden?

jonasw, I wish I had the knowledge and time for it, but yeah I've heard ideas here and there about this already

jonasw, daniel: so what you are doing is the blacklist approach.

in that case yes

although it is not a fixed blacklist

Proposal: We ditch alls this in favor of something that ONLY supports what amazon s3 does

Which hopefully should be easy to tighten...

This gives people the option to 1. Use S3 2. Use their XMPP server 3. Emulate one of two API

Except that I wanted to experiment with using Dropbox/NextCloud/etc. as upload services

and neither mimic S3

MattJ, maybe do your expirments and see what headers they require? probably most of them will just use authorize anyway?

in which case instead of allowing header we could just allow authorize or something

I really want to try Joyents blob file storage with the Content-MD5 header.

Also allowing the server to set the durability-level header which indicates the number of backups in different regions that are required.

SamWhited: that sounds like a _very special_ special case.

SamWhited, that sounds a bit dangerous to give the client control over that?

daniel, I don't know about Dropbox, but NextCloud is either basic auth (if you don't mind sharing credentials with your server) or cookies

Not especially; they could cost me a tiny bit more money by having the max replication factor all the time, or not have backups of their own files

But yah, fair enough, that's a special case.

MattJ, then maybe authorize and cookie

FWIW, being able to set an X-ejabberd-something header would be very useful for me.

daniel: I could live with `Authorization` and `Cookie` being the only whitelisted headers.

(Or without the "X-", IIRC today's youth dislikes that?)

Holger: what for?

Ge0rG: Mapping the HTTP request to a virtual host (configuration).

Dropbox is also Authorization it seems

the thing is that i wasn't the one who wanted headers in there in the first place

Holger: you are doing it wrong.

so it's hard for me to argue for either one side

Ge0rG: How to do it right?

Holger: use the Host header to route to virtual hosts? :P

No.

Or well.

I mean if we white list only cookie and auth you could set a cookie Holger

Holger: on your own infrastructure you could also `PUT https://yourserver.com/yourxmppdomain/random/random.jpg`

If you don't want to use the vhost

Ge0rG: That works if you have an 1:1 mapping between HTTP 'Host' and virtual hosts of course, but admins will spam your tracker if you impose such restrictions.

Or what Ge0rG said

Yes I suggest such things in the docs.

Still tracker spam :-)

I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires.

daniel: Yes I could probably abuse Auth/Cookie headers.

And if we're really worried about invalid headers from a malicious server, having any headers at all is a problem (though as I said, I'm not convinced we should be worried about that)

I'm just saying that I doubt we'll come up with all possible use cases in here.

> I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires. Can you find out what exactly it requires?

Yah, just a moment, I hate looking at the S3 docs (which are terrible) so I was being lazy and looked up Joyents instead.

So the idea now is to cope with a few services that are popular today and just hope for the best that the next one will use the same headers?

a bunch of x-amz- headers, otherwise I'm having trouble finding info.

But what Holger said.

So it's ["Cookie", "Authorization", "X-*"]

...

I'm still not sure what problem we think we're solving with this.

Amazon also does Host and User-Agent at least, I think

Although User-Agent makes no sense to me, so maybe this is wrong

SamWhited, the user agent has to be set to something specific?

I'm reading this page, and being confused: https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

SamWhited, the problem we are trying to solve is that we are currently giving the server the possibility to trigger arbitrary HTTP requests from the client.

oh signed

i get it

SaltyBones: that is not a problem description. Why is that bad?

I know we've been through this, but I'm just not sure that it's actually a problem and am trying to figure out if it would really cause any security issue.

SamWhited, I'm not convinced that it is but Ge0rG's link does suggest otherwise.

SamWhited: that signature needs to contain the content md5. I can't see how you can make a client generate that header.

[[ 20 minutes until Council, BTW ]]

Does it? I know I've made amazon work before, but yah that doesn't seem like it can be supported easily without additional modifications

SaltyBones: his link was about malicious invalid headers, right? (I lost it, sorry, no search in any of my clients) This doesn't solve that (again, if it's actually a problem in our case)

SamWhited: the signature also depends on YourSecretAccessKeyID, which I'm sure you don't want to leak to the client.

https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth

SamWhited: so either the xmpp server needs to have the MD5 in advance or you are doomed.

Ge0rG: that's fine, you can generate one per request

But yah, MD5 is a problem. It might not always be required though, because I know I've made this work before

SamWhited, I think it's optional, in that I think if you don't provide the header you just put an empty string in the string-to-sign

By the way, if anyone wants to take some minutes for the Council meeting (in a few minutes from now), that'd be tremendously useful.

SamWhited, and at this point... it looks like S3 allows putting everything into the query string? :)

That's useful, I didn't realize that. I would prefer not to put auth in the query string either way though.

Why?

Because it's generally accepted best practice that you don't. Things log URLs and it's acceptable to do so, they don't generally log headers (because that's generally where you put things you don't want logged like this)

[[ Council time over in council@muc.xmpp.org ]]

pep.: I have a server side jingle-ft component

goffi, !

Is it in a working state

I'm currently working on it, but it's already working yes

Also, there's no XEP for that right? Or how much is it covered by the current XEP?

the XEP is jingle FT

instead of sending to an other client, I send to the component

nothing else to do

and then the server offers it via httpupload or again jingle?

Sure but then you can do things with your component you can't do with clients

You can use your component to proxy the transfer, to retry when the other contact is back online etc.

Or just serve the file

I'm not complaining just trying to figure out what's happening. :)

SaltyBones: I'm on this part currently, implementing XEP-0329, but I'm not happy with it, I plan to write a feedback on standard@ about that

SaltyBones, jingle

I hope

I don't see the point of http-upload here

It's not unfeasible though, the component could serve via http as well

I'm saying that since HTTP upload is on the table. The only interest is has, is that it's easy to implement when jingle is not yet implemented in a library

but once you have jingle, it's more easy to do this way.

and with namespace delegation, you can even send fileto your bare jid, you don't even need to find the component. I've not done it yet, but it's in my TODO

message-id question: why can't we use a counter

I have heard: 1. State keeping is impossible, 2. Attacks based on guessing the id but I'm not convinced that either is a real thing.

State keeping is very difficult if you have a cluster. Your counter has to be centralized and atomic, which rather defeats the purpose of having a cluster.

can I PM you for discussion? I don't want to spam this channel all the time :)

Message me directly please (sam@samwhited.com); none of my clients handle PMs well.

Though this is probably good discussion and I don't think you'd be spamming this channel :)

yeah

I’d prefer such discussions here too

most of the time they’re insightful

SaltyBones, state keeping client side is impossible too

see: vm snapshots

(server side also)

We could also discuss why MUC-PMs are still broken in some clients :>

They're just broken in general whichever model you take for them. There are tradeoffs both ways.

They are broken in poezio, but it seems that once you explain to a reasonable developer how to implement them, they magically start working.

At least it's a problem that's easier to solve than MUC reflection matching

Ge0rG: are they more broken than UI's not being aware to check if PMs are permitted in the room?

Guus: you either have what Conversations / Mcabber do where they're mixed in with room traffic and you constantly accidentally send things you meant to be a PM to the room, or they're separate conversations in which case they look like 1:1's except a lot of stuff you'd expect to work just doesn't because they're actually MUCs.

Also if they're mixed in with the room it's just hard to follow a conversation by PMs if there's also room chatter going on.

Guus: that should be solved by properly augmenting outgoing messages with their error bounces

SamWhited: I think that daniel's take at integrating PMs into the MUC is a conscious effort to make them unusable ;)

Besides of not working when you are not in the room, and most clients getting MUC-PM Carbons wrong, my experience is that they work just like normal messages, except you don't know the actual JID of the receiver.

Ge0rG: as opposed to having them being separate conversations? That's almost as unusable, just for different reasons. Especially since if the person changes their nickname it immediately breaks everything and makes the world a confusing place.

> Besides of not working when you are not in the room, or the recipient. but yes not working messages. pretty minor

SamWhited: a smart client would probably implement nick change tracking, but that doesn't work well for history.

SamWhited: but as opposed to nickname wars from the IRC days, people have pretty constant nicknames today.

it's almost perfect. expect. you know. messages don't work if the recipient drives through a tunnel

Right; MUC PMs in general are just a bad experience, no matter how you slice it.

I don't know. My experience with them has been better than with some MUCs, and even better than with direct messages in some corner cases

and yes. making the UX bad in Conversations and 'hiding' it behind a long press is an attempt to guide people to send regular messages

daniel: except people botch it all the time and send private things in public by accident

daniel: it's okay to hide them, but please don't make them easy to mis-use

I think that with always on clients and some self-presence checking code they can be made to work pretty well. Bonus points if you keep outgoing PMs stored until the nickname comes back online

Lol sure. But why?

Ge0rG, so I can steal that nicknames PMs?

sweet

The serve no purpose besides annoying me when people think that I help them faster if they pm me

jonasw: how do you know that I'm me?

Ge0rG, I could’ve established that during the conversation.

(besides of the obvious one, me being the only person who cares about PMs)

> Bonus points if you keep outgoing PMs stored until the nickname comes back online Until you are both online at the same time

jonasw: I could have left the conversation and been replaced by Mallory at any moment in time during our dialog

daniel: you can't see their presence if you are offline 😛

Pretty cool feature these PMs

Ge0rG, not with a client which reasonably checks identity

i.e. either uses the real JID if available or assumes the worst :>

daniel: so you are annoyed because your client is popular? Note taken.

And I could even have four conversations with four different Ge0rGs in four different mucs

And I wouldn't even know if it's the same Ge0rG

Pretty fucking awesome

Plus the regular conversation with the real Ge0rG if have

I like what pidgin does (yes, really)

jonasw: daniel: now you are arguing against anonymous MUCs

if it knows the real JID, it’ll just make a conversation with that

jonasw: execute code remotely?

completely circumventing the MUC. and your privacy if real JIDs are only visible to mods, I guess.

daniel, hah.

jonasw [21:11]: > I like what pidgin does (yes, really) Who are you and what have you done to jonasw?

> now you are arguing against anonymous MUCs Go go go!

Once we ditched anon MUCs, there's clearly no point anymore in keeping MUC PMs, is there?

we might need to solve the SPIM issue first.

or also ditch public MUCs in general. and even then I’m not convinced that this is a good idea.

Solve you say?

maybe we need a small protocol where you can ask someone for their real jid . or give them your real jid. sort of like an invite to chat 1:1. and the other person can accept or decline

Zash, yes.

Holger: tell that to the people who created MIX proxy JIDs.

jonasw: Yes my suggestion is ditching public MUCs.

Holger, hm.

so clients could render that as Ge0rG (georg@domain.tld) wants to talk to. is that cool?

Holger, what IM system would you propose as support channel for, say, prosody, then?

jonasw: Or keep them the half-broken way we have them now. That's good enough for the few of us who use them.

jonasw: IRC.

ugh

Ok, Matrix :-)

Holger, okay, if we agree on that, we could "just" solve that with UX

Maybe we ditch anonymous mucs, and then if you need to be anonymous your server could issue you with some sort of temporary JID that you could use. Some sort of "burner" jid, maybe. (actually, there were reasons this wasn't ideal, but I forget what they were every time this conversation happens)

SamWhited: didn't you even write a strawman xep for that?

BTW, was MIX even mentioned at the summit?

Heh..

Or just register an anon JID manually if you need that.

-xep 0383

SamWhited: Burner JIDs (Standards Track, Deferred, 2017-01-28) See: https://xmpp.org/extensions/xep-0383.html

Like email users do.

Or has everybody sane finally reached the conclusion that MIX is dead?

Holger, right, because our multi-account story does work so well ;)

-xep 0389

SamWhited: Extensible In-Band Registration (Standards Track, Experimental, 2017-03-16) See: https://xmpp.org/extensions/xep-0389.html

jonasw: Rather than investing time in fixing PMs we should fix that multi-account story!

SamWhited: the only problem with burner JIDs is that they are free and nobody can block them

Holger, I tend to agree

So all we need to do is a PoW attached to creating them!

I’ll... just ... stop following that discussion at this point.

Ge0rG: yah, there needs to be some better policy or access control around them, but there didn't seem to be enough interest for that to be developed.

Do I hear blockchain m

But it's no different than people running their own server that they could add tons of JIDs on really, and public servers can certainly rate limit since it requires authentication to get a burner JID

Servers could even say that burner JIDs aren't allowed to federate, so they could only be used for MUCs on that server (in which case you could also allow them with SASL-ANONYMOUS)

SamWhited: now this is a really useful idea. I'm running a non federated anonymous server for support MUC purposes on my domain.

Ge0rG: yah, I do the same, that could be a burner JID service as well and just don't allow burner JIDs to send to stuff on other domains to prevent spam.

daniel, IIRC, when zinid announced that he was working on the MUC bare-presence thing, you asked whether it’d include disco#info caps. Why did you ask for that? Which part of a MUCs disco#info do you need?

SamWhited: I'd say your last proposal is sufficient to kick all that proxy JID stuff from MIX.

Ge0rG: there was some reason that it wasn't that I think I ended up being convinced by, but I can't remember what it was.

But I would love it if we just ignored anonymous MUC and that was handled out of band, by my proposal or something else.

Anonymous identities are useful for more than just chat rooms, so it doesn't make much sense to me that it should be part of the groupchat spec and only useable there.

jonasw: mhhh I guess I don't really *need* it. I think I always query the muc anyway to get a response and avoid server not found et al. But I do work with the non anonymous, members only feature

And the form field that tells me if users are allowed to write pms and set the subject

daniel, okay, so you essentially need the Form :/

Which currently doesn't provide the information I need anyway on ejabberd...

daniel: you should write an xep (or a new section for 45) on how to properly create a private MUC

jonasw: yes. I'm aware of ejabberd putting in the member count though... Which makes that difficult...

daniel, so that use-case wouldn’t profit from splitting the caps hash into identities+features and forms

pity

Other than that a lot of my conferences are configured the same. And having a caps hash would actually minimize the traffic a bit

daniel, but only if the occupant count isn’t in there

Yes

and if it isn’t, it probably doesn’t matter a lot if we split the hashes because MUCs generally don’t have a very diverse feature set I assume

I'm displaying the occupant count in MUC invitations... 🤔

Is there not a way to set a MUC to show everyones full JID?

jjrh: yes

"yes there is a way" ✏

https://upload.yax.im/upload/7Cr3yYVohs6RrCxg/1518640458381643013676.jpg

Because this issue is more of a annoyance in 'trusted' places - aka internal chat where there is no reason I shouldn't know you're JID and when I click your name in group chat (as a lazy way to send a PM vs going to my roster) it should do the right thing.

jonasw: fwiw the split of what muc puts into features and the form is pretty weird and confusing anyway

And the naming of the features as well

I quite like that burner jid thing

what were the downsides again SamWhited ? (or whoever)

I wish someone would remind me, but I do remember being convinced that it wouldn't work for MIX ¯\_(ツ)_/¯

beh i'm dumb, I didn't know showing jids was a option in room configuration that probably solves /my/ issue at least.

SamWhited, oh, because burner JIDs aren't shared across devices?

which basically means multi-device can't work

so what if you essentially just solved the alias problem while you are at it?

a XEP that gives 'burner JIDs', except rather than being extra logins, the server just delivers all messages to that JID to your account, and you can also send things as that JID, same connection

it would be a bit complicated, but would solve the alias problem *and* the anonymous muc/mix/future mux/whatever problem

if multi-device doesn’t work, I’d be pretty unhappy wtih that

yah, that's probably it; multidevice seems like a must. I actually had it that way originally before someone reminded me that SASL provides an authorization identity; mixing the two streams felt *really* dangerous to me though.

The server could always issue the same burner JID to all of your devices though.

Burner could work as a jabber transport as well.

Ge0rG: I didn't understand that?

SamWhited: implement it as an xmpp 2 xmpp transport...

Would give us roster control and the ability to unsubscribe and obtain a new identity

I don't think a second JID would help you with that, you still need the client and server to speak the protocol. I suspect I'm missing something though

oh, not 'xmpp2 to xmpp transport'

I am still not sure how it helps or what use an xmpp to xmpp transport is though

Different identities in your roster I'll grant, although merging rosters is weird UI wise

I postulate that all of this is caused by people wanting to use the same software for private chats and anonymous public chats. There is surprisingly little overlap in terms of both functionality and UI.

I tend to agree

Also, people don't understand how any of this works anyway. If we completey drop anonymous JIDs it will be strictly better because nobody even understand what the benefits are or when they apply so they cannot make use of them. :p

More or less public chats are what we use XMPP for ourselves. Don't underestimate that use case.

Zash, what do you mean by more or less public chats?

SaltyBones: This very room for example.

This room could have JIDs of everybody and nobody would care...

I would, I'm not entirely comfortable with random people being able to contact me out of band just becasue I join a room.

Not that my JID is secret

That's imho a matter of spam handling