Mandatory encryption on XMPP starts today

http://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/

by MattJ100 • 12 years ago

191 98 12 years ago

blog.prosody.im

zx2c45• 12 years ago

I'm hoping with the ousting of Vic Gundotra, Google will reenable XMPP federation with Hangouts...

For those unaware, for years GTalk supported using XMPP/Jabber to talk to other servers. A handle of whateverwhatever@gmail.com could speak through GTalk to someone using a different XMPP server with somethingelse@personaldomain.com.

With the introduction of Hangouts, this is no longer possible. In order to talk to GTalk users, you might be using a Google account.

Now before there's too much confusion: yes, Hangouts/GTalk users can still use XMPP clients, like Pidgin or Adium, to talk to other Hangouts/GTalk users. But such users can no longer talk to people using the global federated XMPP network of servers that are not Google.

For years I enjoyed being able to run my own XMPP server, do some interesting things with it, and still talk to my friends and family on GTalk. Now I'm forced to use Google to maintain this.

In other words, they took a well functioning standard that was successfully decentralized, federated, and working extremely well, and deliberately neutered the decentralized aspects. Now there is the nice decentralized XMPP, and Google's XMPP, separate, distinct, broken. It's a damn shame. Gtalk federation worked great for years, and it's only been with the G+era strangulation that it's disappeared.

darklajid2• 12 years ago

I don't share your hope, but oh yes. That'd be amazing. Currently it's a usability nightmare and entirely unclear who can reach you and who cannot.

As someone without Hangout or G+ people with a @gmail.com suffix might or might not be able to contact me, sometimes depending on the age of their mobile or whether they use GMail at this particular moment.

Their presence might or might not be accurate, because they are either away or use Hangout and stay 'away' forever (not offline, nooooo. They are away in G+ land..).

I hope you are right and I'm wrong.

zx2c45• 12 years ago

Currently it's a usability nightmare and entirely unclear who can reach you and who cannot.

Yes! Exactly this. I had started working on a Prosody server side plugin that would route messages for Hangouts users through a Google Account if they were on Hangouts instead of old-Gtalk, but the details of detection seemed flaky at best. When I have some time, I'll give it another look by examining the User-Agent the client sends. I'm not hopeful, but I guess there's a chance.

grinich• 12 years ago

What did the XMPP change have to do with Vic?

presootto• 12 years ago

Nothing at all; this was a decision made by the Hangouts team. The XMPP change has to do with the NIH syndrome a lot of Google engineers suffer from, combined with the incompetence of the Hangouts PM, Kate Cushing.

Disclaimer: I work for Google.

pjc50• 12 years ago

Presumably the defederalisation was to enforce chatting (a) such that google knew your real name and (b) such that you were subject to surveillance.

girvo2• 12 years ago

Know the worst part of Hangouts?

Using any client other than the crappy extension for Chrome, you can't do group text chats. Flamingo[0] is an amazing XMPP client for Hangouts, but is useless for work because we use group chats for everything.

Drives me crazy, and Google refuse to release an actual API for Hangouts, so it's not being fixed anytime soon. I'm trying to convince work to move to IRC or HipChat, or anything other than Hangouts (but my boss loves Google everything, so that's a losing battle).

[0] http://flamingo.im

joosters• 12 years ago

Yes! It's really frustrating because if you are using another chat client (e.g. Apple messages), everything seems to work except you won't see any sign of group chats. This has caused plenty confusion for me with friends wondering why I'm not responding to messages.

What's even worse is that Google's hangouts app is pretty much unusable. For some reason it doesn't list all of my contacts, won't show if anyone is available and gives no indication about who I could chat with.

gonehome• 12 years ago

I'd recommend checking out slack for your work - we started using it and it's the best chat/collaboration software I've ever used.

https://slack.com/

drdaeman5• 12 years ago

and Google refuse to release an actual API for Hangouts

In old good days we didn't ask for protocols. We just took the specs by force, by reverse engineering. Worked well with ICQ, AIM, MSN Messenger and loads of others, except for, possibly, Skype (which was reverse engineered, but late to the party)

And "alternative" messengers survived and even prospered (seriously outplaying the dysfunctional, overweight and ad-ridden "official" ones), even if they were actively fought by network owners. Given that official Hangouts "desktop" app is is nearly completely unusable - and even more for those who don't use Chrome - and even web messenging support is lacking (you just can't put a button "Contact me on Hangouts" on your site), I'm a bit curious why no one cared about Hangouts enough to play that game once again.

izacus• 12 years ago

That would be awesome, but I don't have high hopes - Google probably wants to have ability to modify protocol as they wish for new features. It seems they practically have no will to build a translation layer :/

ralphm2• 12 years ago

In short, it is very unlikely the reasons for abandoning federation, or dropping XMPP altogether with Google Voice, are technical in nature.

darklajid2• 12 years ago

That doesn't make a lot of sense though. There are already lots of places where that stuff is falling back to "Sorry, can't do this".

Ignoring hardware limitations (running hangout on a phone without a front facing camera maybe?) you already have the 'user runs a browser that needs a plugin to fullfil the request, but plugin is missing' case. Which is reported as a failure to both users (with a somewhat helpful message).

Using anything hangout-y over xmpp can fail for all I care. That's not the problem. The problem is that they broke the parts that _map well_. You cannot text me if you're using hangout (unless you're on gmail.com and use the 'gtalk' chat widget). I cannot see your presence.

There's a difference between 'not building a translation layer' (for oh-so-awesome new features) and deliberately breaking things that work since, like, forever.

I agree with the sibling: It's deliberate and just another Google 'Move to out platform and never get out' move.

(Other examples: »"Upgrade" your browser to Chrome.« »Install a "modern" browser to get automatic translation of websites.« - ignoring all the 'Join G+' nonsense)

Svip2• 12 years ago

I am confused. I use DuckDuckGo's Jabber/XMPP service (dukgo.com), and I can easily talk to Google Accounts through Bitlbee, even if they are using Pidgin, GMail's chat interface or whatever.

The only obstetrical I have encountered so far, is that it requires at least 3 or 4 tries to add a Google user. But afterwards, it's not a problem.

Edit: One of my friends using dukgo.com also confirms this behaviour.

zx2c45• 12 years ago

If they've switched to Hangouts, you will no longer be able to reach them. Google users using the old non-plus-ified gchat, which is being phased out, will still work as before, but for people who get upgraded to Hangouts, they'll be cut off. So this basically includes everyone on a smartphone, or everyone using video chat, and soon it will be just everyone entirely.

lnanek2• 12 years ago

I wish they would support open protocols too, but that just isn't Google any more. They are closing down lots of APIs besides XMPP compatibility after all.

shmerl4• 12 years ago

Google is totally messed up. Complete lack of communication of their plans, weird betrayal of XMPP efforts and etc. I gave up on them completely.

dunham• 12 years ago

One case I think you left out (although I may have misread what you wrote):

You can talk between GTalk and a federated XMPP server if the the GTalk user is logged in via XMPP. So if I send a message from my work XMPP server to my google address, it shows up in Adium, but not in the hangouts client.

It's almost as if Google's XMPP network is separate from hangouts, and they only allow messages directly to/from the Google XMPP to propagate between them.

Aloha• 12 years ago

For the past couple weeks I have been able to IM from inside the hangouts app to non-google XMPP users this includes the reverse, wherein I get notifications from them too.

wesley• 12 years ago

What happens to group chats? as far as I know encrypted group chat is still not supported yet?

pgeorgi3• 12 years ago

That's only for transport level security - messages can still be sent in the clear within the encrypted connection.

daveid• 12 years ago

That's only for end-to-end encryption, say, OTR. What this is about is connection encryption client-to-server and server-to-server.

MattJ1008• 12 years ago

It's possible to achieve quite secure group chats in XMPP, as long as you have a server that you trust (emphasis on that last part). You're probably talking about OTR though, which is quite tricky for multi-party situations.

This isn't XMPP's or OTR's fault - from a high level to have a secure multi-party discussion, every participant must individually verify every other participant. This creates a lot of overhead with large groups. What you can do instead is to delegate your trust to, say, a key member of the group - if they trust every member, so do you. This is the model that XMPP supports. Set up a server that only accepts encrypted and securely-authenticated connections (using whichever mechanism you have the most faith in) and only grant access to the room to trusted individuals.

drdaeman5• 12 years ago

I had heard TextSecure/WhisperPush (which uses OTR-like protocol with similar properties) has multiparty/group secure conversations. However I'm unaware of any attempts to apply those to XMPP MUCs, neither I've seen any vetted solution for end-to-end encrypted MUCs.

pgeorgi3• 12 years ago

Luckily they don't require "valid" certificates at this time - trying to get all XMPP server operators to agree on a set of CA providers they all trust will be a nightmare.

andreasvc4• 12 years ago

A nightmare? What gives you that idea? There's free as in beer certificates from StartCom, and free as in freedom certificates from CAcert. Agreeing on those would go a long way.

Zash4• 12 years ago

CAcert.org is no longer included by default in many major distributions. They were removed from Debian a while ago. And they also started using SHA-512 (?) signatures that don't work with some TLS stacks, notably GNU TLS.

pgeorgi3• 12 years ago

There are parties vested in _not_ supporting CAcert - so that won't happen. But I'm not even talking about those: CAs centralize trust and trust on the internet is a hot topic right now.

Right now there's a certain homogenity in which CAs are supported by vendors. And for those that aren't, it isn't much of an issue in the web browser because users can manually click through.

Now consider the talk about "Why is CNNIC/TurkTrust/Symantec in my list?" that's raised by various parties recently (concerned about the influence the governments of China, Turkey and the USA respectively can exert), what happens when XMPP servers decide not to trust CNNIC (to pick one)?

Users will only notice in that they can't talk to peers. They won't know which server is responsible (or if maybe the GFW is kicking in) and there's nothing they can do about it.

From the point of server operators, with mandantory CA signatures they have to decide if they're rather willing to drop perfectly fine connections or if they're accepting "secure" connections subverted by parties they weren't willing to trust in the first place.

pdkl954• 12 years ago

Still wish I had an option for encryption. - certs cost money, which I (and many other people I know) CANNOT[1] afford. StartSSL won't give me a cert (they did previously, but want $$$ now).

This problem affects more people than you probably realize. Remember that 15% of the population (48 million people people)[2] in the USA are below the poverty line. The internet has already been a powerful tool, accessible in various ways even at this end of the income spectrum. Despite that, the PKI system is serving as a barrier-to-entry if you want to encrypt.

So I ask again: what is a FREE option for SSL. TCP, HTTP, DNS and most other protocols work fine once you can send packets, and do not require an extra regular fee. SSL does.

Or is the intent to have secure communication only for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed" by the SSL servers of the rich and middle class? Or are we supposed to only use the internet as if it was TV, and be forced to trust our plaintext with some 3rd party?

sigh - I suspect the answer will instead be "[-1] Don't want to be reminded of the hard issues."

[1] I realize that the idea of not having an extra $15 doesn't make sense to those of you with salaried jobs. Well, lets see you come up with that extra $15 on a tiny SSDI check. Domain (3rd level) is free. Internet is very cheap and flat-rate. An extra $15 would be some new(-ish) clothes, not a SSL cert.

[2] https://www.census.gov/hhes/www/poverty/about/overview/

MattJ1008• 12 years ago

A self-signed certificate is free, you don't need a CA-issued certificate just to use encryption.

Most XMPP servers on the internet today are forgiving of certificates they don't trust - they will encrypt the connection and then use "dialback" to authenticate you based on DNS.

Obviously falling back to DNS is not as secure, and as mentioned in the blog post - there are people working on ways to allow people to use any certificate (including self-signed) securely.

pdkl954• 12 years ago

Most XMPP servers on the internet today are forgiving of certificates they don't trust...

I was not aware of that - I'll certainly investigate that possibility.

Obviously falling back to DNS is not as secure

Of course, but it's still better than "plaintext".

scrollaway2• 12 years ago

FWIW, if you get a domain with gandi.net, your first year of SSL cert is free, subsequent years are no more expensive than the domain itself. This is only for the basic single-domain cert though.

th0br0• 12 years ago

Why not use CA Cert? Sure, they're not included on Windows by default or (I believe) OS X but at least there's some level of trust.

pdkl954• 12 years ago

There service seemed... confusing. As you say, though, their cert is not included in win/osx, which makes it kind of useless re: client logins.

(always trying to convert friends to a saner OS - with some success - but that's a slow process :/ )

ibotty• 12 years ago

hopefully dane fixes that.

dspillett5• 12 years ago

StartSSL won't give me a cert (they did previously, but want $$$ now)

Do you have reference for that? I've been using their free certs for a few things for a while and a recent renewal was free. I'll be paying for one shortly, but that is only because I want a wildcard for one of my domains in order to save some faf.

I suspect your problem is the "third level domain" thing: they would effectively need to have permission from the over of the next level up to sign a cert on your behalf for one of their names (or you would need your domain provider to take part in the validation process).

for those that can afford it - the rest of us doomed to plaintext or rejected as "self signed"

That certainly isn't the intention of the security community, but until a method is found that allows certificates to be freely produced without the security risks involved with self-signed certs that is what we (well, those in the poverty trap) are stuck with.

How StartSSL arrange their business model seems to be one solution, your current problem above not withstanding. If the depth of your free domain is the issue then perhaps the solution lies with the domain registrant taking the cost of a wildcard certificate (~$30/yr with startssl, ~$60/yr elsewhere) and so their subscribers can use it for SSL. They would have to proxy web requests to you though (with something like nginx in a reverse proxy configuration), so it would not be a zero admin option and would cost them in extra bandwidth requirements too unless they already host your content (rather than just responding to DNS requests for content hosted elsewhere), otherwise the only way you could use the cert is for you to know the private key which breaks the assurance model completely. Perhaps you could convince a provider of third level domains that taking these steps could give them with a competitive advantage over similar providers who do not.

igravious2• 12 years ago

Slightly off-topic but, in your opinion, how does StartSSL compare to CAcert? I'm about to jump and would like to know where I'm landing.

pdkl954• 12 years ago

I suspect your problem is the "third level domain"

That's one of the problems for me at the moment. A friend in a similar situation (but with regular .net domain) triggered one of their "must pay now" criteria (ref: the StartSSL business model).

They have worked in the past, and are sometimes an option, but a "second source" is unfortunately necessary.

That certainly isn't the intention of the security community

I don't really intend to make any accusations - take any harsh tone in my post to be a general annoyance at the current situation.

I appreciate the ideas about technical workarounds. They are similar to some things I've considered already, and might yet try.

I'm more concerned about a general solution to this PKI/cert problem - XMPP and HTTP simply being the common examples. In reference to the manifesto linked at the top of this thread, the time to encrypt everything is "now". This is a great idea, but it can't happen everywhere until the money-issue needs to be solved.

vfclists• 12 years ago

Is there something about a chain of trust people don't understand? A chain of trust doesn't mean a commercial body, as that implies that being commercial makes it more trustworthy.

It means any individuals or groups you can trust, not those your browser maker or software developer includes in their software in the belief that they are trustworthy. Why should relationships with faceless commercial entities whose employees you have no personal acquaintance with take precedence over people known to you believe you can trust?

Why shouldn't individuals be capable of forming the same trust networks that companies do, and what methods do companies use in forming their chains of trust that individuals can't emulate, as companies themselves depend on individual human beings to create their systems?

Did you overlook the last paragraph in the article?

The way the browser vendors, Mozilla being one of the bad guys, notify users about untrusted certificates is a major culprit. They state that the certificate is not trusted, or something to that effect, when in fact they mean that the certificate is not recognized in their trust network.

makomk4• 12 years ago

StartSSL-issued free certificates don't work reliably for XMPP in my experience anyway - some clients insist that the CN must be set to the top-level domain name and StartSSL won't issue free certificates with that configuration. I wouldn't be surprised if some XMPP servers had the same issue too.

Zash4• 12 years ago

Then those clients are broken and should get fixed.

mmastrac• 12 years ago

Are the StartSSL free certs limited to something.example.tld? I've been using the inexpensive company-validated ones ($120 for two years) with a wildcart cert personally and haven't had that issue, so I'm unfamiliar with their free offering.

zokier2• 12 years ago

The best option for you currently would be to pool some money from friends/family to buy SSL cert collectively. It probably makes sense anyways to share the server instead of everyone hosting their own.

ape4• 12 years ago

How about switching away from XML!

claudius2• 12 years ago

Why?

What potential gain could possibly justify breaking the entire protocol and extension-ecosystem?

andreasvc4• 12 years ago

XML has a large amount of overhead, both in bandwidth and parsing (have a look at the amount of XML that is exchanged just for logging in with XMPP). For low powered devices and low bandwidth connections such as with mobile devices, there is an undeniable gain.

It's not necessary to break anything, just as TLS and compression are optional features of the connection, something like switching to ASN.1 would be possible, given a mapping of a pre-defined subset of the main XMPP protocol and commonly used extensions.

shmerl4• 12 years ago

What to? XMP provides a powerful way to manage extensions to the protocol (with namespaces). What else do you propose to use?

ultramancool• 12 years ago

You're still trusting the server. This is only a gain if you were already the one running the XMPP server with everyone you talk to.

Use a real end-to-end solution to this problem: OTR.

MattJ1008• 12 years ago

OTR only protects the text content of your messages. It doesn't protect the metadata, or many of the other features XMPP provides from status to file transfers and voice/video calls.

shmerl4• 12 years ago

For media calls there is ZRTP.

makomk4• 12 years ago

Well, looks like this kills off my personal XMPP server - I don't think the software I'm using (djabberd) supports encryption for s2s connections and it's not really developed anymore. That's annoying.

Zash4• 12 years ago

Considered migrating to some other XMPP server software?

makomk4• 12 years ago

Most of the XMPP server software out there is neither lightweight nor easy to configure and there's no real migration paths between them. I probably don't even have enough system resources on my personal server to run some of the more well-known servers anyway; they tend to be oriented towards deployment on large multi-user systems.

robn_fastmail• 12 years ago

For historical reasons we still run DJabberd at FastMail so I had to add support for this myself. You might try this patch:

https://github.com/fastmail/DJabberd/commit/144c4431f36e5ea3...

Its been running for a few hours now without any obvious problem. I might have made some stupid error that makes the crypto entirely useless but considering yesterday it was all in cleartext anyway I think I can live with it ;)

shmerl4• 12 years ago

Looks like things started moving for OTR support in Telepathy: https://bugs.freedesktop.org/show_bug.cgi?id=16891

ZRTP however is still stalled: https://bugs.freedesktop.org/show_bug.cgi?id=29904

imaginator• 12 years ago

One of the big problems with XMPP security was testing the server's connection. It's worth pointing out that much of this move has been supported by @xnyhps project: xmpp.net. This lets you stick in an XMPP enabled site and see the results. For example: Google - https://xmpp.net/result.php?domain=gmail.com&type=server (nothing) and prosody.im: https://xmpp.net/result.php?domain=prosody.im&type=server

X4• 12 years ago

XMPP is an awful protocol [1] [2] .

[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber

[2] https://news.ycombinator.com/item?id=2069810

MattJ1008• 12 years ago

Two clearly unbiased and factual analyses there :)

It would take quite some time to sit down and address all the points gathered on the PSYC page. That page has been around a long time, and used to be a lot more aggressive than it reads now. At one point it even contained a quote from a mailing list post of mine, snipped to remove just the right amount of context. I'm glad to see they've cleaned it up a bit, to at least make it appear somewhat more objective, even if they still think it's objective to make technical statements like "XMPP isn't proper XML".

One of its main points is of performance and scalability. Well I'm afraid that horse bolted - for nearly a decade Google have been successfully running (one of?) the world's largest IM services using XMPP.

Regarding your second link, well, that seems to be set on comparing XMPP to IRC:

A protocol that, despite an immense range of features, can easily be typed by a human on a telnet prompt, in real time.

Making a protocol that could be typed over telnet obviously wasn't the goal of XMPP. For what it did set out to do - create an open standard IM protocol to give normal people a path to freedom from the old IM silos that were around 10 years ago - I'd say it has been pretty successful. Maybe not as successful as one might have hoped, those silos are still around, but for political and commercial reasons rather than technical ones.

Mandatory encryption on XMPP starts today

Related Stories