
Mandatory encryption on XMPP starts today - MattJ100
http://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/
======
zx2c4
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.

~~~
girvo
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](http://flamingo.im)

~~~
drdaeman
> 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.

~~~
josteink
> I'm a bit curious why no one cared about Hangouts enough to play that game
> once again.

Maybe because Hangouts was created as an unwelcome product eating a completely
functional service people liked.

Nobody wants to invest in a service which just told you to fuck off.

~~~
drdaeman
Well, anger may lead to various possibilities. I had reverse engineered
certain cloud storage service client protocol when I was told there won't be
any cake (properly functioning GNU/Linux client software customers were
promised for a long time) for me and I have to fuck off. And I had not
published it only because RE laws in my country seem to be totally messed up -
they literally say I can't publish my findings. Wish I'd live somewhere saner.

Still, as I believe, quite a lot of people use Hangouts. Sure, there must be a
hacker somewhere who's upset enough to mess with the software.

------
pdkl95
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/](https://www.census.gov/hhes/www/poverty/about/overview/)

~~~
dspillett
_> 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.

~~~
pdkl95
> 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.

~~~
dspillett
_> I don't really intend to make any accusations_

Your tone was actually fine, I put that there as a preface to the next
statement (which was essentially "but that is the way things sometimes work
out").

 _> I appreciate the ideas about technical workarounds._

Another suggestion you might try if you know enough reliable people in a
similar position as you find yourself in (happy to have a third level domain
but needing a certificate potentially for commercial use) who you trust enough
to do business with: club together, and rent a normal domain and wildcard
certificate with it.

Of course someone will have to take responsability handling the money, for
technical admin, and for enforcing certain rules such as "nothing illegal
otherwise we are all at risk" (this person will need to be trusted by the
other parties, it goes without saying), and if a two-or-three $ per year is
the maximum you can stretch to each then you would need a small number of tens
of people in (more if you can each spare less) (domain + wildcard from
StartSSL ~= $75/2yr ~= $2/year each for 20 people, still not free but an order
of magnitude closer), and there is the support "risk" of not particulary
technically minded peopel joining and needing hekp to setup/maintain things,
so the idea might be completely impractical but nonetheless there is a chance
it might be worth considering.

------
pgeorgi
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.

~~~
andreasvc
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.

~~~
pgeorgi
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.

~~~
andreasvc
Yes there is a lot of red tape surrounding certificates, but I was
specifically suggesting that the authors of XMPP clients and servers could
agree on these 2 alternative CAs.

------
imaginator
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](https://xmpp.net/result.php?domain=gmail.com&type=server)
(nothing) and prosody.im:
[https://xmpp.net/result.php?domain=prosody.im&type=server](https://xmpp.net/result.php?domain=prosody.im&type=server)

------
makomk
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.

~~~
Zash
Considered migrating to some other XMPP server software?

~~~
makomk
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.

~~~
Zash
[http://prosody.im/](http://prosody.im/) is pretty light weight and easy to
configure. (I'm one of the devs)

I don't know how easy it is to move data out of djabberd but I'm sure we can
help you with that if you can provide schemas or example data. :)

~~~
makomk
Yeah, was looking at Prosody. It's probably relatively simple in my case since
I'm using the standard SQLite backends for roster storage etc. (Large-scale
djabberd deployments likely aren't so lucky - djabberd was designed to make it
easy for people to write code hooking in to their existing systems and many
did. The only example I can find took a couple of months[1])

[1] [http://blog.fastmail.fm/2011/08/24/new-xmppjabber-
server/](http://blog.fastmail.fm/2011/08/24/new-xmppjabber-server/)

------
shmerl
Looks like things started moving for OTR support in Telepathy:
[https://bugs.freedesktop.org/show_bug.cgi?id=16891](https://bugs.freedesktop.org/show_bug.cgi?id=16891)

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

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

\--

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

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

~~~
MattJ100
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.

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

~~~
MattJ100
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.

~~~
drdaeman
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.

------
ultramancool
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.

~~~
MattJ100
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.

~~~
shmerl
For media calls there is ZRTP.

~~~
MattJ100
I'm not an expert in this field, but as far as I know ZRTP trust is
bootstrapped from the signalling channel (in this case your XMPP connection).
So a MITM there could also MITM your voice/video.

And again, your metadata and signalling would still be exposed without
encryption - along with your IP addresses (ICE candidates), etc.

------
ape4
How about switching away from XML!

~~~
claudius
Why?

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

~~~
andreasvc
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.

~~~
MattJ100
[http://xmpp.org/extensions/xep-0322.html](http://xmpp.org/extensions/xep-0322.html)
(originating from the IoT community, where XMPP is commonly, and successfully,
used on embedded devices like you describe).

Just please don't mention ASN.1 again :)

