XSF Discussion - 2021-06-17

https://infosec-handbook.eu/blog/xmpp-aitm/

Did XSF members try to fix these issues ???

Chan Shen, you can use end-to-end encryption (e.g. OMEMO) to avoid the admin reading your messages.

many servers support the SCRAM authentication, which avoids cleartext passwords (ejabberd disables it by default for reasons™ I think)

test 1/2 show just data which exists in all server-based communication systems

> jonas’ wrote: > Chan Shen, you can use end-to-end encryption (e.g. OMEMO) to avoid the admin reading your messages. It doesn't fix all of these issues

(established connections alongside with state and public data)

all over all, this article documents a lot of things which are kind of obvious when you look at the design decisions of XMPP (and many other protocols). it is a server-based federated chat protocol, which means that things like "injecting (unauthenticated) messages on the server side" is just how things work; if authentication of messages is needed, E2EE (such as OMEMO) needs to be employed to thwart that.

likewise, the server is used to share data between clients on the same account (such as the roster), which implicitly gives the server some power over the roster…

(and other such data)

> jonas’ wrote: > all over all, this article documents a lot of things which are kind of obvious when you look at the design decisions of XMPP (and many other protocols). it is a server-based federated chat protocol, which means that things like "injecting (unauthenticated) messages on the server side" is just how things work; if authentication of messages is needed, E2EE (such as OMEMO) needs to be employed to thwart that. > likewise, the server is used to share data between clients on the same account (such as the roster), which implicitly gives the server some power over the roster… > (and other such data) How about matrix ???

I am no Matrix expert.

but I am sure if you ask their marketing, they’ll tell you it’s all fine there.

I am certain that you can see for instance client connections with public IPs on a matrix server though, that’s just how it works.

no idea how their contact list stuff works, so I can’t comment on that. I’d be surprised if it was considerably different from what XMPP has in that regard though.

> jonas’ wrote: > I am certain that you can see for instance client connections with public IPs on a matrix server though, that’s just how it works. https://serpentsec.1337.cx/matrix

on a privacy side i think we could get rid off metadata by suppressing the servers and using peer to peer which i believe is possible in xmpp (correct me if i'm wrong) but i guess all parties must be connected in order to talk to each others and need their ip addresses, routers could still theorically get infos but if the communication is encrypted it should be fine

server-less messaging is only specified for LAN use cases

not for WAN

(it relies on mdns, which is not generally routed) ✏

wouldn't it work with something like i2p?

and you cannot have multi-user chats in the specs as written

i see

I have no idea how i2p works and how XMPP plays into that

(and I don’t know of any spec)

(when I say "it doesn’t work" or "does not exist", I talk about specs as written)

yeah right

but if you drop the servers from the scheme, it’s not really XMPP anymore. you can go with briar or tox or whatever then :)

XMPP is a federated, not a peer-to-peer system, by design and choice

s2s is p2p, after a fashion

if every individual runs a server, yes

that's what p2p is. everyone running servers. have fun with those trade-offs on mobile

i see, it is possible somehow to prove that we don't collect any meta data except hashed password and email on a server?

xutaxkamay, no, because that’s not true

well i guess giving ssh access

... and email?

but probably not a good idea

ops

how would you prove that the ssh access is really accessing the server, and not a chroot/jail which just *looks* like the server with all the important data stripped out? :)

i meant address

what the federated client-server model gives you is choice. choice in who you trust to run your server and who has access to your metadata.

there is things, i guess but yep technically you could do anything

i see, well i guess the best is to run your own server in that case then

xutaxkamay, well, a server will generally also store an archive of messages, the roster, things published via PEP, ..., so "hash of password + address" does not quite cover it, at all.

it can also remain online while you're out of range of wifi or cell networks, which simplifies things.

> jonas’ wrote: > xutaxkamay, well, a server will generally also store an archive of messages, the roster, things published via PEP, ..., so "hash of password + address" does not quite cover it, at all. if the config is done correctly it should be okay, but yeah i was just saying self-host at home only for your only user and join others servers with it and theorically customize the server so it leaks less as possible informations but it does take indeed time

I may be (too) late yoday

Today, too

You can minimize collectable metadata by never talking to anyone. Doesn't seem ideal to me, though.

Arrange a face-to-face meeting in the woods. Leave your phones at home.

What if someone is watching?

Deeper into the woods!

Make sure the foliage gives enough coverage to hide you from the satellites!

But how do we arrange the meeting securely without someone else hearing?

I mean, obviously we arrange a meeting in the woods to arrange a meeting in the woods, but that has some obvious flaws.

It's meetings in the woods all the way back!

DWRoX - Deep Woods Rendezvous over XMPP is the clear solution here

Do we have Board members here? arc / MattJ / ralphm ?

Here

Two member does not a Board make.

Sorry guys. Also arc has connection issues with his server. I think it is a DNS server not responding.

Are messages deleted from the server after a certain day

şişio, up to each server admin to decide ✏

> Zash wrote: > şişio, up to each server admin to decide How?

Does it change from server to server

Yes, local policy

I want it to be user policy, but I (and nobody else) has written the XEP yet...

That would be great.

> ralphm wrote: > Yes, local policy 👍

Instead of mam"=yes/no/contacts that would be good indeed.

Yes, I want to deprecate that configuration in favour of retention configuration

(within bounds set by the server operator)

I also want this instead of persistent=yes|no for MUC

That one I think can just go entirely, to be replaced by operator config. If the owner wants a MUC destroyed sooner, they can do so. Likely there is an upper bound that an operator would want for an empty room, might as well just use that as the TTL

Even simpler!