WebOS: the other Linux-based mobile platform

Posted Jun 14, 2011 20:02 UTC (Tue) by bcombee (subscriber, #40068)
Parent article: WebOS: the other Linux-based mobile platform

Thanks for the review. The device communication tool is actualy novacom, not novocom.

webOS 2.1 has text correction in editor fields. In the Preferences page of the launcher, go to Text Assist and you'll see all the settings.

The IMAP self-signed certificate issue is one that could use better UI. We've redesigned the accounts system and email application in webOS 3.0, but I don't think this particular issue has been addressed. It looks like the method of manually installing a certificate using the Certificate Manager UI will still work, but it's not as easy as a "accept this cert" dialog in the accounts UI.

And this is actually a good thing...

Posted Jun 15, 2011 6:48 UTC (Wed) by khim (subscriber, #9252) [Link] (18 responses)

Only on LWN you can see Your editor, who created that certificate, trusts it just fine; it should be possible to impress that trust upon a phone in a review. This shows such a fundamental disconnect it's not even funny.

The standard phrase applies: you don't exist. The number of people who can create and use certificate without outside help is so minuscule it's stupid to even think about them. If you'll add easy option to add certificate then people will go and happily accept certificates from all kinds of phishing sites.

In case of IMAP it's clearly task for the techsupport of your company (or ISP), not for end user - and instructions look good enough for such use case.

And this is actually a good thing...

Posted Jun 15, 2011 8:04 UTC (Wed) by jku (subscriber, #42379) [Link] (17 responses)

Your advice is good and describes well how things should work. Unfortunately that's not always what happens in the real world: self-signed certs do get used in intranets ("it's inside the VPN, why bother?") that can be accessed by devices that do not recognise the certs, proper certificates get forgotten and are no longer valid, etc.

Your advice to device manufacturers is "just leave these people without the service: you didn't do anything wrong, their IT support is to blame". In a way this is sound advice but it also means these real customers could be a bit annoyed when you first deny them service and then doubt their existence :) .

Why it's there in the first place, then?

Posted Jun 15, 2011 8:30 UTC (Wed) by khim (subscriber, #9252) [Link] (16 responses)

Unfortunately that's not always what happens in the real world: self-signed certs do get used in intranets ("it's inside the VPN, why bother?") that can be accessed by devices that do not recognise the certs, proper certificates get forgotten and are no longer valid, etc.

Right. And the advice is simple for such cases: remove the SSL, it'll be more honest. And simpler to setup for everyone involved.

Your advice to device manufacturers is "just leave these people without the service: you didn't do anything wrong, their IT support is to blame".

Actually it's advice mostly to the government (which will ignore it till few real tragedies will strike and billions will be lost). Manufacturers have little choice: the "easiest to use" platform wins. Classic tragedy of commons: companies drop security safeguards to win marketshare then people are complaining that their systems are infected by all kinds of malware, their private data is sent to god knows where and their money is transferred to Congo.

In a way this is sound advice but it also means these real customers could be a bit annoyed when you first deny them service and then doubt their existence :)

Right. That's why I expect that HP will eventually make it simple to add self-signed certificate with just one click. They are not Google, they are not market leader, they must please customer in any way they can. The fact that later this same customer will be outraged when his private mail will be published in web is irrelevant as Facebook success shows.

We'll see how bad it'll be before some mandatory security requirements will be imposed by law.

Why it's there in the first place, then?

Posted Jun 15, 2011 10:54 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

WTF?

Self-signed certs are WAY more secure than plain-text passwords. You can't passively eavesdrop on communications, you need to be able to perform active attacks.

It's only partially true

Posted Jun 15, 2011 13:06 UTC (Wed) by khim (subscriber, #9252) [Link] (9 responses)

This is only true when you explicitly install them. I said as much before.

But if it's easy to accept them with a single click then you are training people to ignore security warnings. The net effect on security is strictly negative: the fact that now you need active attack is more then compensated by the fact that users are now ignoring security messages.

It's only partially true

Posted Jun 15, 2011 14:28 UTC (Wed) by marcH (subscriber, #57642) [Link]

What makes you think people who self-sign their certificates care about educating the masses?

Actually... what makes you think anyone anywhere still cares about educating the masses?

Sorry to be cynical - I am just trying to be realistic.

SSH?

Posted Jun 19, 2011 2:48 UTC (Sun) by djao (guest, #4263) [Link] (5 responses)

It's instructive to compare SSL to SSH before you go off overblowing the importance of certificates.

SSH doesn't use certificates at all, self-signed or otherwise. In SSH, almost every real-world user (more or less) automatically responds "yes, trust this public key" whenever connecting to a server for the first time. The procedure is equivalent in both user experience and security to your proverbial one-click acceptance of self-signed certificates.

Are you therefore claiming that the net effect of SSH on security is strictly negative? If so, that's a very surprising, almost ludicrous, assertion. I can imagine someone making some sort of argument that SSH does not provide as much security as a hypothetical optimal variant that used certificates, but to claim that SSH is even worse than telnet is a stance that has no credibility.

Moreover, there is ample objective evidence that SSH in fact achieves better real-world security than SSL. When was the last time you heard of a man-in-the-middle attack against SSH? Have there been any reports of successful SSH key forgeries? Which of SSH or SSL has the greater market share? (Hint: you can't argue that SSH is a less attractive target on the basis of its market share.) Which of the two userbases (SSH or SSL) would you say has better-trained users? (Is this a pre-existing effect, or is it possible, just maybe, that ease-of-use has a positive effect on user training?)

You might want to think carefully about how SSH managed to reach 99% market share without using any certificates or PKI authentication. The easy option is not always insecure. Sometimes it's exactly what's needed.

SSH?

Posted Jun 20, 2011 22:13 UTC (Mon) by elanthis (guest, #6227) [Link] (4 responses)

SHH is hacked all the time. It's trivial to do so because the lack of a central key authority puts the onus of verifying the remote host's authenticity on the user, almost every single one of which just says "yes add this host key" without even thinking of checking the key's fingerprint.

That you don't _hear_ about these is irrelevant. SSH is far less prevalent amongst the masses and hence is far less newsworthy. There are papers and CVEs publisheds on it all the time nonetheless.

SSH?

Posted Jun 21, 2011 0:23 UTC (Tue) by djao (guest, #4263) [Link] (3 responses)

That you don't _hear_ about these is irrelevant. SSH is far less prevalent amongst the masses and hence is far less newsworthy. There are papers and CVEs publisheds on it all the time nonetheless.

1. Could you cite any such papers or CVEs?

2. If you consider the big picture (total number or proportion of security incidents against browsers as opposed to login shells), I'm sure the number and proportion of unreported browser attacks far exceeds the number of unreported attacks against login programs. Many of these browser attacks (phishing etc.) have nothing to do with SSL, but that's my point: A security protocol, such as SSL, which fails to achieve widespread mandatory use, is by definition incapable of preventing most attacks.

The best security protocol in the world is of no use whatsoever if an attacker can simply trick unsuspecting users into not using it. This happens all the time with SSL. Failure to achieve market share is in and of itself disastrous for security, and I believe this shortcoming of SSL outweighs all its other achievements.

SSH?

Posted Jun 21, 2011 0:46 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

there are definantly CVEs with SSH itself, and there are papers that show problems with how SSH is used. There have been a number of well publicised cases where someone's laptop/desktop was compromised and their SSH keys were then used to go login to other systems and continue the attack from there.

but that's not the same as a man-in-the-middle attack, which is the particular issue that was being discussed here.

SSH?

Posted Jun 21, 2011 1:48 UTC (Tue) by djao (guest, #4263) [Link] (1 responses)

You keep mentioning the type of attacks where "someone's laptop/desktop was compromised and their SSH keys were then used to go login to other systems." This is not a fair comparison. The reason SSH keys are attacked in this way is because SSH keys are actually used. Believe it or not, SSL also supports client-side keys for authentication. The reason why you never hear about this feature getting attacked in SSL is because, I believe, the number of people in the world who use this feature in SSL is approximately zero. If they were actually used, then the same attack would also work against SSL.

My whole point all along is that SSL's failure to achieve marketplace acceptance is the one thing that above all else renders SSL useless as a security protocol. It hardly seems fair to attack SSH on this basis. A security protocol or protocol feature, such as SSL client-side keys, which nobody uses is certainly invulnerable to attack, but it also does not contribute to security in the slightest.

SSH?

Posted Jun 21, 2011 3:26 UTC (Tue) by dlang (guest, #313) [Link]

you are misunderstanding me.

I am not attacking ssh because of the cases where the client certs have been compromised, I am mentioning them and saying that such attacks do not count as SSH vulnerabilities (they count as bad deployment decisions on how to use SSH, relying solely on the possession of the client side cert, not requiring anything else)

another poster claimed that SSL without CA validation is meaningless, someone else pointed out that that basically matched what SSH does, and that SSH is therefor vulnerable to the same types of attacks as SSL without CA validation. So the question I am raising is, given that there is far more extensive use of SSH, can anyone show attacks against this supposed severe mitm vulnerability?

programming bugs in SSH don't count (which is what most CVE things are)

attacks that involve compromising the client key don't count as they aren't mitm attacks.

It's only partially true

Posted Jun 19, 2011 21:52 UTC (Sun) by kleptog (subscriber, #1183) [Link]

IMHO the big mistake with SSL was conflating the encryption with authentication. Sometimes indeed you trust the network enough (local LAN) enough not to misroute your packets, but you just don't want the bits to go unencrypted over the wire. With SSL the only way to achieve this is a self-signed certificate.

I think browsers should start recognising this use case and have a mode where they don't have the padlock, coloured URL bars, etc but still encrypt everything and don't complain. Make it look like normal HTTP. Add a cache to check the certificate against the previous one and you're all set.

Unverified certs do prevent passive attacks

Posted Jun 24, 2011 6:12 UTC (Fri) by cypherpunks (guest, #1288) [Link]

You're wrong. Unverified certs do prevent passive attacks. That's
the founding principle of public key crypto. When Alice and Bob
exchange keys and proceed to communicate, Eve can't eavesdrop unless she performs an active attack.

Why it's there in the first place, then?

Posted Jun 16, 2011 0:42 UTC (Thu) by Lennie (subscriber, #49641) [Link] (3 responses)

But why deal with selfsigned if their is a free alternative ?

StartSSL is recognised by most systems out there. Every major browsers, just not some old mobile devices.

Here are the instructions:

https://github.com/ioerror/duraconf/blob/master/startssl/...

* I'm doing some free promotion for them because I think it is cool what they do, not because I'm getting payed or anything like that.

Why it's there in the first place, then?

Posted Jun 18, 2011 7:21 UTC (Sat) by speedster1 (guest, #8143) [Link]

> But why deal with selfsigned if their is a free alternative ?

This does sound like a useful service, but an experienced admin may still choose to use self-signed for non-public servers (e.g. the imap server) because they trust their own security measures better than those of some third party CA. Or, even if their security measures are not actually better, their server is much less interesting to attackers who love to get control of a widely accepted CA... so the risk of compromise is still lower.
It was not long ago that an official certificate authority was compromised and the attackers generated untrustworthy certificates.

Why it's there in the first place, then?

Posted Jun 20, 2011 15:33 UTC (Mon) by nye (subscriber, #51576) [Link]

>But why deal with selfsigned if their is a free alternative ?

Well, right now:
"Due to a security breach that occurred at the 15th of June, issuance of digital certificates and related services has been suspended. Our services will remain offline until further notice."

Why it's there in the first place, then?

Posted Jun 21, 2011 21:25 UTC (Tue) by job (guest, #670) [Link]

Because if you can install the certificate manually, it is much more secure since you don't have to delegate your trust to the CA (as evidenced by the current message visible at StartSSL).

Why it's there in the first place, then?

Posted Jun 16, 2011 19:14 UTC (Thu) by iabervon (subscriber, #722) [Link]

Actually, the sensible thing is to sync your self-signed certificate from your IT-imaged desktop. A very secure policy would be: the phone will not connect to an unrecognized IMAPS server, and won't let you ignore the issue or trust the certificate from the connection, but it will let you supply the root of trust that you expect the site to have and use that instead of the usual PKI root certificates. Sure, the vast majority of people won't be able to use this to authenticate their connections, but that's because they're using gmail. People who have some person relationship with their mail servers can get the correct root of trust in advance. (This also would mean that you'd generally have a configuration where you don't trust your employer in general, but you do trust your employer to authenticate your work email server.)