Mandatory encryption on XMPP starts today(blog.prosody.im)
blog.prosody.im
Mandatory encryption on XMPP starts today
http://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/
10 comments
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.
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.
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.
That is not my observation. It is also not clear what you mean with "get upgraded to Hangouts". I use Hangouts extensively, but I use also Gajim as client for my Google account and still I'm able to add XMPP contacts from non Google XMPP servers to my Google roster.
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.
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.
Well that's certainly interesting, but me too, I haven't really noticed that.
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.
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.
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.
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.
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.
> 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.
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.
What did the XMPP change have to do with Vic?
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.
Disclaimer: I work for Google.
It is my understanding that XMPP also presents a problem with regards to mobile due to inefficient design from a power usage point of view. I could certainly see how that would be reason to look into fixing or outright replacing XMPP but not opening the replacement protocol is just shameful.
They are still supporting XMPP for c2s connections, though; i.e. if you are on a phone, you can use XMPP to connect to Google. What they don’t support is s2s, which – unless you somehow run your own XMPP server on your phone – has nothing whatsoever to do with mobile :)
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.
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.
Funnily enough, that's exactly what they did do, back in 2008 :)
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...
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...
Naive implementations of XMPP on mobile can indeed get quite power hungry, but it doesn't have to be that way. Thankfully I've seen quite a bit of interest lately from mobile clients who wish to improve on this - all the resources are out there.
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).
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).
Yes, XMPP is power inefficent as the server can send presence notifications at anytime to the client even though the mobile user is probably not interested in notifications about who of his 200 contacts just went away or came back. Unless he looks at the roster.
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.
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.
I don't think XMPP is necessarily power-inefficient.
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.
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.
Indeed. Take a look at this insightful blogpost:
http://op-co.de/blog/posts/mobile_xmpp_in_2014/
http://op-co.de/blog/posts/mobile_xmpp_in_2014/
But google invented Jingle, and in the XMPP space I can't imagine they didn't have a dominate authority. And you can add whatever extensions you want to XMPP, standard or not.
Google did start Jingle and large part of their work ended up in the Jingle standards at the XMPP Standards Foundation. However, Google Talk and the old Hangouts took quite a while to move to the standardized version, and were never fully compliant. Also, in other areas, Google never quite interacted with the community and left major issues unresolved.
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).
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).
> the incompetence of the Hangouts PM, Kate Cushing
Thanks for the pointer to here. Letter writing campaign to Kate Cushing worthwhile?
Thanks for the pointer to here. Letter writing campaign to Kate Cushing worthwhile?
Remind me to never be a PM for Google.
I've dropped her a message (kcushing at google dot com) and I suggest you do the same.
So far as I can see, the Hangouts implementation still uses XMPP, and even sends some federated messages to other servers. It looks like there has been some kind of code added to specifically block the functionality for which code already exists.
Presumably the defederalisation was to enforce chatting (a) such that google knew your real name and (b) such that you were subject to surveillance.
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
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
> 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.
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.
> 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.
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.
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.
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 old good days we didn't ask for protocols. We just took the specs by force, by reverse engineering
In the good old days we wrote standard protocols and submitted them as RFCs (eg RFC 1459)
In the good old days we wrote standard protocols and submitted them as RFCs (eg RFC 1459)
Uh... I'm too young for that, unfortunately. But as I get it that first they wrote the implementation(s), then - seeing it's reasonably good - documented the results for everyone to discuss and use.
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.
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.
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.
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.
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/
https://slack.com/
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 :/
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)
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)
In short, it is very unlikely the reasons for abandoning federation, or dropping XMPP altogether with Google Voice, are technical in nature.
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.
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.
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.
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.
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/
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/
> 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.
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.
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.
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.
> A chain of trust doesn't mean a commercial body
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".
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".
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.
I've not used CACert since investigating a few years ago. At that time it was the case that their CA certs were not trusted by many platforms (i.e. most Windows users) so if you have users on those platforms their certificates are no better than self-signed ones for those users - this made them unacceptable for what I was doing at the time. If http://en.wikipedia.org/wiki/CAcert.org is up-to-date then this has not changed.
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.
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.
The CAcert root cert is trusted almost nowhere, so they are not comparable. StartSSL certs are trusted by almost all major OSs and browsers.
Thank you kind sir, good to know - hope this helps someone. I had the impression that CAcert were fairly legit.
They are, but they're not included in various browsers for various reasons -- so they are "legit", but they are not easy to use for use-cases where you don't have a modicum of control over clients (can install, or ask clients to install, cacert root keys).
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:
http://lwn.net/Articles/590879/
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:
http://lwn.net/Articles/590879/
> 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.
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.
> 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.
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.
> A friend in a similar situation (but with regular .net domain) triggered one of their "must pay now" criteria (ref: the StartSSL business model).
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).
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).
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.
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.
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.
> 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".
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".
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.
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.
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 :/ )
(always trying to convert friends to a saner OS - with some success - but that's a slow process :/ )
hopefully dane fixes that.
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.
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.
As of 2013, if you get a free cert for something.example.tld, it also includes a subjectAltName for example.tld (which is usually desirable if something is "www" but undesirable if it's something else).
Then those clients are broken and should get fixed.
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.
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.
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.
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.
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.
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.
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
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.
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 ;)
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 ;)
Considered migrating to some other XMPP server software?
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.
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. :)
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. :)
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/
[1] http://blog.fastmail.fm/2011/08/24/new-xmppjabber-server/
I wouldn't worry about system resources; if anything, I'd say that a high-level dynamic language adds most to the overhead. I can recommend http://ejabberd.im
I've knocked up an ejabberd install within a half hour. Really simple, really lightweight, and in the debian repos (IIRC.)
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
ZRTP however is still stalled: https://bugs.freedesktop.org/show_bug.cgi?id=29904
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
--
[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber
[2] https://news.ycombinator.com/item?id=2069810
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.
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.
What happens to group chats? as far as I know encrypted group chat is still not supported yet?
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.
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.
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.
That's only for end-to-end encryption, say, OTR. What this is about is connection encryption client-to-server and server-to-server.
That's only for transport level security - messages can still be sent in the clear within the encrypted connection.
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.
Use a real end-to-end solution to this problem: OTR.
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.
For media calls there is ZRTP.
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.
And again, your metadata and signalling would still be exposed without encryption - along with your IP addresses (ICE candidates), etc.
How about switching away from XML!
Why?
What potential gain could possibly justify breaking the entire protocol and extension-ecosystem?
What potential gain could possibly justify breaking the entire protocol and extension-ecosystem?
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.
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.
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 :)
Just please don't mention ASN.1 again :)
What to? XMP provides a powerful way to manage extensions to the protocol (with namespaces). What else do you propose to use?
For those unaware, for years GTalk supported using XMPP/Jabber to talk to other servers. A handle of [email protected] could speak through GTalk to someone using a different XMPP server with [email protected].
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.