Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMPP: Admin-in-the-middle

infosec-handbook.eu

Post reply on HN
Print view View original

51–59 of 59 posts

Re: XMPP: Admin-in-the-middle

#51

Post by infosechandbook »

MattJ100 wrote: post #28
rhn_mk1 wrote: post #26

Earlier quoted context omitted.

> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication. There are plenty of authentication protocols that don't send passwords in cleartext. WPA would b…

I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user…

> I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear).

The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password. It even clarifies that SCAM-SHA-1 won't help as hashing happens after cleartext password can be logged.

> loglevel: 5 (or “debug”) logs every single message and all activities mentioned above plus passwords in cleartext. Some XMPP proponents insisted that this isn’t true as XMPP servers use SCRAM-SHA-1 for password hashing. However, it doesn’t matter whether you enable or disable server-side password hashing as clients send new/changed passwords to XMPP servers in cleartext. The server logs the cleartext password before hashing it.

Re: XMPP: Admin-in-the-middle

#52

Post by zaik »

gefhfff wrote: post #42
zaik wrote: post #40

Earlier quoted context omitted.

Why should I use Matrix over XMPP? All the problems mentioned in this article also apply to Matrix.

Matrix has introduced some really neat innovations compared to XMPP: - decentralized conversations instead of centralized ones - MEGOLM - Cross Signing - monolithic protocol (i.e. one true way of doing things officially) - easy sync of (encrypted) history between sessions These are reasons why people use Matrix and not because of misinformation about how private it is Also: afaik not everything applies to Matrix, e.g…

MEGOLM seems to be encrypted group chat. OMEMO already provides that.

Cross signing OMEMO keys would be nice indeed.

Not sure what a session is or why it needs sync.

XMPP is decentralized, maybe even more than Matrix, since almost everyone uses the official server matrix.org.

I'm not sure if all of this is reason enough to switch to an non-standard protocol, fragmenting the small space of open IM protocols even further. It would be better to implement those features using existing Internet Standards.

Re: XMPP: Admin-in-the-middle

#53

Post by gefhfff »

zaik wrote: post #52
gefhfff wrote: post #42

Earlier quoted context omitted.

Matrix has introduced some really neat innovations compared to XMPP: - decentralized conversations instead of centralized ones - MEGOLM - Cross Signing - monolithic protocol (i.e. one true way of doing things officially) - easy sync of (encrypted) history between sessions These are reasons why people use Matrix and not because of misinformation about how private it is Also: afaik not everything applies to Matrix, e.g…

MEGOLM seems to be encrypted group chat. OMEMO already provides that. Cross signing OMEMO keys would be nice indeed. Not sure what a session is or why it needs sync. XMPP is decentralized, maybe even more than Matrix, since almost everyone uses the official server matrix.org. I'm not sure if all of this is reason enough to switch to an non-standard protocol, fragmenting the small space of open IM protocols even furth…

> MEGOLM seems to be encrypted group chat. OMEMO already provides that.

No, OMEMO is rather comparable to OLM. MEGOLM is a layer on top of that.

> Not sure what a session is or why it needs sync.

When you log in (on phone, browser, ...) you create a session

> XMPP is decentralized, maybe even more than Matrix,

Certainly not technology wise

> since almost everyone uses the official server matrix.org.

Less than a third

> It would be better to implement those features using existing Internet Standards

In your opinion. The success of Matrix today is enough for me to distance myself from purely idealistic views

Re: XMPP: Admin-in-the-middle

#54

Post by topdancing »

gefhfff wrote: post #41
topdancing wrote: post #20

Earlier quoted context omitted.

> Seriously, XMPP is still worse than AIM for actual day-to-day use Have you actually tried the modern clients like Conversations/Dino? I've been running a private XMPP server for friends for the past couple of years and the only way to describe it is rock-solid.

Have you actually tried any alternatives at all? Even Matrix with Element (which used to have quite a few issues with slowness and encryption), works way better these days Not to mention any widely used centralized messenger...

Yes, in addition to my private XMPP server, I have been running a Matrix server for one of my clients for about the same amount of time.

Element desktop is... slow and terrible in comparison with all of its confusing options, and regularly kicks just a single person off the server for no apparent reason when their session becomes corrupted. I really want to use fractal but it doesn't do E2EE.

Synapse was a horrible resource hog, but conduit actually seems pretty good. Still prefer ejabberd.

Re: XMPP: Admin-in-the-middle

#55

Post by Andrew_nenakhov »

megous wrote: post #45
Andrew_nenakhov wrote: post #39

Earlier quoted context omitted.

It is quite possible not to send presence information at all. I'll say more, we're working on an 'omnipresence' protocol that will advertise only the desired status to the external contacts, and will not leak per-device presences. This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).

Desktop is not always connected. People turn it off, or suspend it to save on electricity bills.

From the point of view of xmpp development, it is always connected. Thing is, xmpp session start is a very costly operation. Desktop generally does it once and has it easy from then on. iOS device connects every time a user opens an app. By the time it'll finish receiving presence information, a user will already close it, and the OS will terminate app process.

Re: XMPP: Admin-in-the-middle

#56

Post by ruslan »

I wonder why did they choose to investigate plain text connection to XMPP server instead of SSL or TLS ? As far as I recall there's "starttls" command on standard 5222 port, after that things get encrypted and all their tcpdump tricks fail. Almost none of the XMPP clients use plain text connection nowadays.

Re: XMPP: Admin-in-the-middle

#57

Post by ruslan »

ruslan wrote: post #56

I wonder why did they choose to investigate plain text connection to XMPP server instead of SSL or TLS ? As far as I recall there's "starttls" command on standard 5222 port, after that things get encrypted and all their tcpdump tricks fail. Almost none of the XMPP clients use plain text connection nowadays.

And, by the way, federated servers use SSL/TLS as well. Of course server admins can do verything, like peer into your traffic or grab passwords from database, because they are admins!

Re: XMPP: Admin-in-the-middle

#58

Post by lmm »

topdancing wrote: post #20
lmm wrote: post #10

Earlier quoted context omitted.

I think that bit of history shows what a false idol extensibility is. 20 years of extension and improvement has resulted in a chat system that is still staggeringly worse in practice than its competitors of 20 years ago. (Seriously, XMPP is still worse than AIM for actual day-to-day use). Look at XML vs JSON for another example. A simple standard that has no improvement path except completely replacing it turns out t…

> Seriously, XMPP is still worse than AIM for actual day-to-day use Have you actually tried the modern clients like Conversations/Dino? I've been running a private XMPP server for friends for the past couple of years and the only way to describe it is rock-solid.

I tried Conversations (admittedly a while ago) and found it a solid meh. Its features mostly worked, but it definitely felt clunkier than AIM.

Re: XMPP: Admin-in-the-middle

#59

Post by infosechandbook »

ruslan wrote: post #56

I wonder why did they choose to investigate plain text connection to XMPP server instead of SSL or TLS ? As far as I recall there's "starttls" command on standard 5222 port, after that things get encrypted and all their tcpdump tricks fail. Almost none of the XMPP clients use plain text connection nowadays.

> Almost none of the XMPP clients use plain text connection nowadays.

Everything shown in the article works with or without TLS enabled. It doesn't matter. The server-side party sees cleartext XMPP packets passing the server.

> all their tcpdump tricks fail

There are no "tricks" in the article. It is just capturing network traffic. The point here is that XMPP traffic isn't magically invisible to third parties that observe the network traffic as some people claim.

Post reply on HN