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

71–80 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#71

Post by tialaramex »

zaik wrote: post #62
tialaramex wrote: post #55

Earlier quoted context omitted.

But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that? The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than…

> 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. It gave Steve (and all my friends, or maybe only Steve, or maybe everybody except one troll, Signal can't tell and doesn't want to know) some of the stamps when sending them other things, and so Signal just sees the message has a stamp on it, no need to know who sent it.

Re: XMPP: The secure communication protocol that respects privacy

#72

Post by MattJ100 »

infosechandbook wrote: post #60
MattJ100 wrote: post #51

Earlier quoted context omitted.

I already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983 I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files. It's much more important to me that I know where my da…

> I already responded to your "admin in the middle" article here And we already responded here: https://news.ycombinator.com/item?id=29106376 , and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/ , and somewhere on Reddit. > I run my own XMPP server (Snikket) for my family Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP…

> Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server?

Yes. The majority of people cannot, and will not ever, run their own server. However my ideal is that the remaining "10%" of people who can, do so. Just as I do for my non-technical family members. I believe that there should be a trust relationship between service operators and their users, whatever form that takes. I work daily to try and make self-hosting XMPP easy and accessible to more people, so we can increase this "10%" fraction.

For a similar perspective see: https://staltz.com/some-people-want-to-run-their-own-servers...

Of course using public XMPP services anonymously (burner accounts, randomly-generated username, connect via Tor/VPN, etc.) is a thing that many people also do, but I think that's a minority use-case (that should still be supported). Tools such as Briar also cover many such use-cases adequately or better.

Re: XMPP: The secure communication protocol that respects privacy

#73

Post by edhelas »

m4lvin wrote: post #27
edhelas wrote: post #2

Hi! Glad to see XMPP on the HN first page this morning :) I'm working on a social-network and IM web platform (for 12 years already!), fully built on XMPP https://movim.eu/ . Thanks to its extensibility and the PubSub XMPP standard (see https://xmpp.org/extensions/xep-0060.html ) you can easily build social-network like features. The standard is pretty simple, it's Atom 1.0 transport within PubSub (see https://xmpp.o…

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 from the project. I know it might be a bit confusing so if you have some ideas to clarify things up do not hesitate :)

Re: XMPP: The secure communication protocol that respects privacy

#74

Post by rakoo »

zaik wrote: post #61
infosechandbook wrote: post #54

Earlier quoted context omitted.

> Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"? And how about looking…

> It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number? > XMPP servers are a gold mine when it comes to metadata. Then even more so for Signal, since metadata for all users can be c…

> Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place.

I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter

Re: XMPP: The secure communication protocol that respects privacy

#75

Post by southerntofu »

infosechandbook wrote: post #48
southerntofu wrote: post #40

Earlier quoted context omitted.

What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ ) but "admin in the middle" is not exactly a bug but a property of federated systems. If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my…

> What would be your alternative? A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem. Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side…

No post body was provided.

Re: XMPP: The secure communication protocol that respects privacy

#76

Post by southerntofu »

tialaramex wrote: post #47
southerntofu wrote: post #38

Earlier quoted context omitted.

If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation. Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you tho…

Pidgin is not listed as supporting OMEMO [0] and is not recommended for newcomers on joinjabber.org [1]. There may be reasons you want to use Pidgin and i don't want to block you: also pidgin is not exactly abandoned so there's hope it will continue to improve.

When a web browser fails to display a certain page, would you recommend the site operator to block it? Maybe we could allowlist specific clients and send a warning message to others just in case they're not aware they're using something niche.

[0] https://omemo.top/

[1] https://joinjabber.org/

Re: XMPP: The secure communication protocol that respects privacy

#77

Post by southerntofu »

f1refly wrote: post #65
tialaramex wrote: post #47

Earlier quoted context omitted.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation. Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you tho…

Since there is nothing one can do to identify a specific client, you cannot just block them. If they violate the spec that should be reason enough to consider them not real clients. I personally have no experience with pidgin and xmpp, but I can recommend https://dino.im for linux. It uses omemo by default and works like a charm.

Of course you can identify clients (although they could lie, it's just a user-agent string). You can even have nice graphs on some servers about it: https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&refr...

Re: XMPP: The secure communication protocol that respects privacy

#78

Post by southerntofu »

MattJ100 wrote: post #46
southerntofu wrote: post #41

Earlier quoted context omitted.

This is already possible! https://xmpp.org/extensions/xep-0070.html

That's slightly different. XEP-0070 is about allowing someone to verify that you own a given XMPP address. That is indeed often all you need for a "Log in with XMPP" functionality. Just how many sites allow you to log in with an email + verification link today. However it does not grant someone the ability to connect to your account and perform any actions. Movim is an XMPP client. It interacts with the XMPP network…

Oh i was not aware you're working on proper authorization/delegation for XMPP. That's really cool! Can't wait to see your blogpost on this topic on HN front page :)

Re: XMPP: The secure communication protocol that respects privacy

#79

Post by infosechandbook »

southerntofu wrote: post #75
infosechandbook wrote: post #48

Earlier quoted context omitted.

> What would be your alternative? A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem. Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side…

Quoted post unavailable.

> Have you read the joinjabber.org security FAQ i linked?

Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ.

> we were tired of FUD spread by articles like yours

Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way.

> Reality is more complex than a binary "is it secure?"

Indeed. Unfortunately, the vast majority of people assume security is binary. Back to OP's article where they look at some isolated properties to then declare a protocol secure.

Re: XMPP: The secure communication protocol that respects privacy

#80

Post by gkdr »

southerntofu wrote: post #76
tialaramex wrote: post #47

Earlier quoted context omitted.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation. Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you tho…

Pidgin is not listed as supporting OMEMO [0] and is not recommended for newcomers on joinjabber.org [1]. There may be reasons you want to use Pidgin and i don't want to block you: also pidgin is not exactly abandoned so there's hope it will continue to improve. When a web browser fails to display a certain page, would you recommend the site operator to block it? Maybe we could allowlist specific clients and send a wa…

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base.

i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgin anyway and i am not sure if it's even worth continuing.) i am very thankful for all the contributions so far, especially the help with packaging it. sorry if someone feels let down.

i feel like this is the right moment to ask: if anyone reading has an idea how to improve the state of things, i'd be happy about some suggestions. the project page is https://github.com/gkdr/lurch

Post reply on HN