Mandatory encryption on XMPP starts today
blog.prosody.im
blog.prosody.im
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.
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.
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.
Disclaimer: I work for Google.
Basically all of the issues, perceived flaws or missing features attributed to XMPP in the old implementation of Hangouts were either misinformed or have seen development or new specifications in the XSF. Google never contributed to such discussions, with the exception of individual Googlers helping with Domain Name Associations (DNA, http://tools.ietf.org/html/draft-ietf-xmpp-dna-05).
Thanks for the pointer to here. Letter writing campaign to Kate Cushing worthwhile?
FWIW, they could “easily” build a mobile client that connects to Google via some nonstandard protocol which preserves energy on the phone while being mapped to the standard XMPP protocol from Google onwards.
Originally Android included an XMPP API that applications could use to connect to Google and other XMPP services. This got replaced by a Google Talk-specific API at the same time they switched to a proprietary protocol.
E.g. http://blog.kosmokaryote.org/2008/02/google-cannot-be-my-cha...
Some links:
- http://xmpp.org/extensions/xep-0286.html
- http://xmpp.org/extensions/xep-0273.html
- http://xmpp.org/extensions/xep-0198.html
XEP-0198 is currently gaining adoption quite nicely for example, it allows for reliable streams (resume them without message loss or the need to re-sync everything if you get disconnected).
Every Android device with the Google services installed actually has an XMPP connection open the whole time (albeit with some protocol changes); it's how push notifications work on Android.
BUT this can be solved easily, when you control the server and the client. And this was already solved by google for years with gtalk. So this is not an excuse to stop federation.
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).
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.
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.
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.
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.
In the good old days we wrote standard protocols and submitted them as RFCs (eg RFC 1459)
The point is, they had an idea, hacked the software (without any standards, at that point, as I understand, this was the case with IRC which had RFCed only 10 years after the birth), then willingly shared the knowledge.
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)
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.
Because while in the past, my primary reason for installing Pidgin was connecting to Google's excellent XMPP service, I now only have it hooked up to my Facebook account. I don't see any value in Hangouts. That's right. As creepy and closed as Facebook is, I still find it a much higher value service than Hangouts. Plus it actually lets me connect to people I know reliably.
Hangouts is the perfect example of taking a good service and throwing it in the shitters. I can barely use the official Android-client. It's just gone completely downhill.
It may not be too late for Google to recover from the terrible slope they've taken on ever since the persisted, user-hostile G+ fiasco, but I can't imagine the tarnish their brand has taken to ever have been worth it.
So I basically can confirm that Google did not turn off XMPP federation for their XMPP service. It appears that there is simply no UI to add users from federated servers over hangouts, but it works with standard XMPP clients. So you could say that "Google dropped support for XMPP in their UIs". But you can still use your Google account as plain XMPP service (which doesn't mean that I would encourage it or think that it's a good idea).
But I can't rule out that e.g. some servers can't federate with Google, for example because of policy restrictions.
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.
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.
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.
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".
(always trying to convert friends to a saner OS - with some success - but that's a slow process :/ )
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.
Please don't suggest that cacert is much less secure than trusting a handful of government CAs by default (or even much less secure than certain commercial CAs).
Cacert isn't perfect, but it is an interesting and important project. It's a pity Debian ended up stripping cacert IMNHO. Anyway, it is healthy to be sceptical, for some more info, see eg:
StartSSL's certificates are accepted by all major platforms (including all Windows desktop variants from XP upwards since ~2009), though there are gaps in this coverage. The stock browser and mail client in at least some relatively recent variants of Windows Phone didn't like them last time I tried. They should be trusted by Android since 2.2, though I believe there are issues with some builds of 2.2/2.3.x (I've not heard of trouble with later versions).
StartSSL's interface can be quite clunky but I've never had it fail. Certificates usually come through in good time (often faster than certain paid certificates I could mention). The "non commercial use" clause added to the terms for the free certificates in recent times may be a problem for some. As I've not really used CACert I can't comment on how they compare on these matters.
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.
One thing that surprises some who have been using SlartSSL for a some time is that a while ago a "non commercial use only" clause was added to the free certificates. I don't know how they police that if they do at all, but if your friend's site was taking money for services that may explain the change from his/her account's PoV. I've stopped using the free certificates for a couple of sites I administer for that reason. This doesn't apply to any of the other certificates they offer (though for a single domain it is cheaper to buy elsewhere).
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.
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.
Correct, but it does mean entities that are qualified to be trusted on the matter. I don't trust a lot of my contacts (both personal or commercial) to be good people for judging what is safe/legit/secure.
How many times I've heard an otherwise technically competent individual complain at being laughed at for using "but <other_person> give me the link I assumed it was OK" as part of their defence when taken the mick out of for getting infected by malware from some ropey website/app/whatever is something it would scare me to count.
> Why shouldn't individuals be capable of forming the same trust networks that companies do
You can. The current system does allow this, though I'll admit not at all intuitively for the general public. Create your own CA keys, have contacts include them in their trust stores. Build a web of trust by signing each others keys (or passing them between each other and new contacts via secure channels).
> 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.
From their PoV those two thing are the same. Things I have no reason to trust are not things I can guarantee are trustworthy. In security there is unfortunately no room for granting the "benefit of the doubt".
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.
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. :)
[1] http://blog.fastmail.fm/2011/08/24/new-xmppjabber-server/
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 ;)
ZRTP however is still stalled: https://bugs.freedesktop.org/show_bug.cgi?id=29904
--
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.
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.
Use a real end-to-end solution to this problem: OTR.
And again, your metadata and signalling would still be exposed without encryption - along with your IP addresses (ICE candidates), etc.
What potential gain could possibly justify breaking the entire protocol and extension-ecosystem?
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.
Just please don't mention ASN.1 again :)