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

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

Post reply on HN
Print view View original

131–140 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#131

Post by topdancing »

tialaramex wrote: post #71
zaik wrote: post #62

Earlier quoted context omitted.

> Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?

It does know the recipient it doesn't know the sender . They call this "Sealed sender" and it is enabled by default for your friends (but you can change who gets this facility). So instead of a message from Steve to tialaramex, it's just a message to tialaramex. Well, duh, of course tialaramex gets messages, why else have message software? My Signal client prepared some "stamps" which are good for one message to me.…

Your Signal client is at this moment logged into a Signal account on the Signal server. Sealed sender does nothing to protect against this - Signal knows that tialaramex is at that IP address.

The server fully aware where Steve is logged in from, and sees a message come from there to tialaramex. On top of even that: you then reply back, server sees a message going to Steve, going straight back to the IP address where it already knows he's logged in from.

Another thing people don't consider is that Signal's core server infra is hosted at AWS... so Amazon can also peek into both this network traffic and also dump out that it's your Signal account (ie. phone number) tied to that IP from the EC2 instance's memory.

These folks showed that this sealed sender stuff is broken last year: https://www.ndss-symposium.org/ndss-paper/improving-signals-... (and there's an acknowledgment from the Signal team on page 3 of the PDF).

Re: XMPP: The secure communication protocol that respects privacy

#132

Post by snvzz »

ezst wrote: post #100
snvzz wrote: post #85

On XMPP, encryption is optional and not even the default. I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.

> I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it. Which are they? Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)? Federated and P2P networks are the only tr…

>Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)?

No. Matrix and Tox come to mind.

Re: XMPP: The secure communication protocol that respects privacy

#133

Post by infosechandbook »

Andrew_nenakhov wrote: post #120
infosechandbook wrote: post #93

Earlier quoted context omitted.

> Signal operators can also inject messages to people. Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community. > What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. What also holds true: O…

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins

Where is this 1-to-1 comparison you demand in the OP's original article?

Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Signal wins as these security features aren't optional but enforced and more mature.

Privacy: This section in OP's article addresses distinct things to then somehow claim XMPP is private. Let's compare them:

XMPP is an open standard -> Doesn't this apply to Signal, too? Some developers claim not to track users -> Same applies to Signal. OMEMO adds security -> explained above, already in Signal. Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy. Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number, and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal. Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature. Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups. User is the only one deciding about/controlling their account and personal data (how can this be ensured if this data is exposed to the server and other users) -> Again a vague statement without any explanation. So Signal users can also decide about their data.

Then, OP's article suddenly ends without going into any details. The article finishes with "phone numbers, centralization bad; username, decentralization good." This isn't balanced at all.

> Signal admins, who control the server and ship an app to you which you can't really verify.

If we write exactly the same about XMPP, people immediately state, "XMPP clients and servers are open source, everybody can look at their code." So let's apply the same logic to Signal. If you don't want to apply this logic, then yes, we can't also verify if we connect to a malicious/manipulated XMPP server even if its source code is open. The same applies to apps. And Reproducible builds don't come with this guarantee, too.

Re: XMPP: The secure communication protocol that respects privacy

#134

Post by zaik »

infosechandbook wrote: post #133
Andrew_nenakhov wrote: post #120

Earlier quoted context omitted.

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Sign…

> XMPP is an open standard -> Doesn't this apply to Signal, too?

The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body.

> Some developers claim not to track users.

With Signal you have to trust a single entity not to track you. With XMPP you have the freedom to choose that entity (including choosing yourself).

> if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number

This is just dishonest. It's a lot harder to obtain a non-identifiable phone number than to think of a random username.

Re: XMPP: The secure communication protocol that respects privacy

#135

Post by Andrew_nenakhov »

infosechandbook wrote: post #133
Andrew_nenakhov wrote: post #120

Earlier quoted context omitted.

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Sign…

I'm arguing with your comments, not the article. Comparing Signal with XMPP is silly. It's like saying 'Firefox is more secure than XML'.

Signal is a product, XMPP is a protocol. That said, XMPP can be potentially used to build communication products that are far more secure than Signal because of a simple virtue of being able to control all components of a service instead of relying on someone else to run a server for you.

And no, this is not the same as verifying the code of Signal, because with your custom XMPP deployment you need to verify your code once, and not worry about the server admin adversary, while on Signal you will have to verify updates every single time.

Re: XMPP: The secure communication protocol that respects privacy

#136

Post by Andrew_nenakhov »

snvzz wrote: post #85

On XMPP, encryption is optional and not even the default. I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.

It is very unlikely to recommend anyone products with default end to end encryption.

Few people really need that, as proven by Telegram: it became by far more popular and usable over their competition precisely because unlike whatsapp you can log in on any device and have your chat history right there, with all your endless pictures! And users love that.

You just can't do that on WhatsApp or Viber precisely because of end to end encryption and the necessity to drag the keys along everywhere and have problems adding new devices.

It's time to end this "E2EE must be everywhere" propaganda promoted by privacy-ticked nerds. Real encryption either greatly reduces UX, or it is a security theater. Security chats should be an option, when you need to have a really secret conversation. Most chats don't need that at all.

Re: XMPP: The secure communication protocol that respects privacy

#137

Post by infosechandbook »

Andrew_nenakhov wrote: post #135
infosechandbook wrote: post #133

Earlier quoted context omitted.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Sign…

I'm arguing with your comments, not the article. Comparing Signal with XMPP is silly. It's like saying 'Firefox is more secure than XML'. Signal is a product, XMPP is a protocol. That said, XMPP can be potentially used to build communication products that are far more secure than Signal because of a simple virtue of being able to control all components of a service instead of relying on someone else to run a server f…

> Comparing Signal with XMPP is silly.

Could you please add your statement to any other comments by XMPP proponents that state "XMPP is better than Signal because ..."?

Plus, could you also consider this for all of your own comparisons of XMPP and Signal?

> XMPP can be potentially used

Again, a lot of guessing and assumptions what could be in a perfect XMPP world, but nobody finds nowadays.

> with your custom XMPP deployment

This isn't a unique property of XMPP.

Re: XMPP: The secure communication protocol that respects privacy

#138

Post by infosechandbook »

zaik wrote: post #134
infosechandbook wrote: post #133

Earlier quoted context omitted.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Sign…

> XMPP is an open standard -> Doesn't this apply to Signal, too? The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body. > Some developers claim not to track users. With Signal you have to trust a single entity not to track you. With XMPP you have the freedom to choose that entity (including choosing yourself). > if we assume…

> The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body.

Who defines "open standard" in the first place? There is no global definition for this.

> With Signal ... With XMPP ...

Another person just claimed comparing both is silly. There are already other comments addressing the rest of your statement.

> non-identifiable phone number ... random username

You compare distinct properties in your own statement. "non-identifiable" isn't the same as "random". If you want to get a random phone number, you can just buy any SIM card. Is this nitpicking? Maybe, but nitpicking is also including in dozens of "XMPP is better than Signal" statements in the comment section. There are already other comments addressing the rest of your statement.

Re: XMPP: The secure communication protocol that respects privacy

#139

Post by m4lvin »

edhelas wrote: post #73
m4lvin wrote: post #27

Earlier quoted context omitted.

I wanted to try it out, but this is annoying: - registration happens on https://api.movim.eu/register and firefox provides me a way to generate a password and save it linked to that domain. - now I want to log in at https://mov.im/?login but firefox has no idea that it should use my api.movim.eu account for that.

Yes this is perfectly normal. The XMPP account (so movim.eu) is decorelated from the mov.im pod we deployed as a public instance to show up the project. You can connect on Movim (and mov.im, the official pod/instance) using any XMPP account. movim.eu is just one amongs all the others. You have to differenciate Movim as a project that particular instance deployed as mov.im and the Movim XMPP server that we deployed fr…

I have my own XMPP server ;-) and I understand the underlying problem here. I mostly wanted to point out that for a new person to quickly try out Movim this might be a stumbling block. As another comment suggested using something like OAuth to smooth this out might help.

Re: XMPP: The secure communication protocol that respects privacy

#140

Post by topdancing »

infosechandbook wrote: post #133
Andrew_nenakhov wrote: post #120

Earlier quoted context omitted.

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.

> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Sign…

> XMPP is an open standard -> Doesn't this apply to Signal, too?

Signal is the opposite of an open-standard, there's a single server implementation and basically three clients (Android, iOS, desktop) and they discourage people from using other clients. Best way to think about Signal is that it's just WhatsApp with some marketing on top.

Meanwhile, I can link a raspberry pi anywhere in the world to my XMPP server with a few lines of Python and some libraries.

> Some developers claim not to track users -> Same applies to Signal.

Both cannot be verified by the users, but as an admin, I can verify that my server isn't tracking users.

> Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy.

It does certainly help not to have all of your eggs in a centralized basket, both in terms of privacy and reliability.

> Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number

Do not know of a single XMPP client that requires a phone number - some random server out there, maybe.

> and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal.

You'll find most people will tell you that you need ID these days to get a SIM card. Creating a new XMPP account takes less than 5 seconds.

> Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature.

The user can disable these, personally I find them useful on my server and miss it sometimes when I use Signal.

> Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups.

Signal doesn't, all phone numbers of group members are visible to people within the group.

Post reply on HN