LWN: Comments on "WebOS: the other Linux-based mobile platform"

Security != authentication, authentication != certificates

robbe — Thu, 30 Jun 2011 10:33:05 +0000

> Actually, how often do you hear about man-in-the-middle-attacks against HTTPS ?

We don't hear about incidents affecting single users very often, unless they are a celebrity.

But there are GUI tools (e.g. Cain and Able) available to perpetrate this MITM attack that make it easy enough for the typical Windows kiddie. I am pretty this happens all the time in networks where these abound (schools, anyone?).

On the enterprise side, there is security software doing https MITM for virus scanning (and optionally other) purposes. Of course here the admin does it on purpose, and proper deployment means that he will install the MITM's CA certifacte as trusted on every user machine.

Unverified certs do prevent passive attacks

cypherpunks — Fri, 24 Jun 2011 06:12:02 +0000

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.

OpenEmbedded

foom — Thu, 23 Jun 2011 20:35:13 +0000

Funny. Have you checked their website recently? :)
https://www.startssl.com/?app=11&action=true

"Due to an attack on our systems and a security breach that occurred at the 15th of June, issuance of digital certificates and related services have been temporarily suspended as a defensive measure. Our services will be gradually reinstated as the situation allows."

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

job — Tue, 21 Jun 2011 21:25:45 +0000

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

SSH?

dlang — Tue, 21 Jun 2011 03:26:49 +0000

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.

SSH?

djao — Tue, 21 Jun 2011 01:48:32 +0000

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?

dlang — Tue, 21 Jun 2011 00:46:51 +0000

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?

djao — Tue, 21 Jun 2011 00:23:04 +0000

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.

This is doubtful...

sonnyrao — Mon, 20 Jun 2011 22:58:35 +0000

That's not the "other reason"
It's most likely *the* reason they went with Microsoft
They needed the money and apparently Google didn't want to pay them to use a free operating system

SSH?

elanthis — Mon, 20 Jun 2011 22:13:17 +0000

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.

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

nye — Mon, 20 Jun 2011 15:33:50 +0000

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

Security != authentication, authentication != certificates

djao — Mon, 20 Jun 2011 14:24:04 +0000

I mentioned a man-in-the-middle attack in my post -- the Comodo attack. Another example is the RapidSSL MD5 attack. That's already two more examples than SSH.

OpenEmbedded

jschrod — Mon, 20 Jun 2011 09:43:24 +0000

"[citation needed]"

Please explain the security advantage of a "real" certificate for an IMAP server in one's own company that's used by ca. 4 persons, to be used on one's own workstations and one's own (self-configured) notebooks, compared to a self-signed certificate. This use case obviously includes import of that specific certificate (or of one's own CA, more likely) into respective applications like MUAs.

I don't see any.

Please list specific risks that are mitigated by the "real" certificate in that use case. Also consider the cost-risk relationshiop of generic CA's trustworthiness in your answer, and explain why authentication by a self-signed cert is no authentication in that specific use-case. Thank you.

Security != authentication, authentication != certificates

Lennie — Mon, 20 Jun 2011 08:56:58 +0000

Actually, how often do you hear about man-in-the-middle-attacks against HTTPS ?

In the whole history of Mozilla & Firefox there was exactly one bugreport of a user who was on a wireless that tried (for a longer period of time*) to redirect the traffic somewhere else than intended.

Now I know this is just the top of the iceberg, but still that isn't much either.

I think the real solution to HTTPS or TLS in general is to hook it up to DNSSEC. Although it still has deployment issues at the moment, but when IPv6 gets going it will automatically solve most of the DNSSEC deployment issues.

It can't be long now until IPv6 gets going, I would think. It is also being deployed as fast as IPv4. it has a very similair growth curve.

SSH also supports DNSSEC btw and it already works, it solve the fingerprint problem.

Also SSH can use certificates too. ;-) It is a bit new and isn't much used yet though.

* That is why the user created the bugreport, she has a lot of HTTPS untrusted warnings/errors.

It's only partially true

kleptog — Sun, 19 Jun 2011 21:52:08 +0000

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.

Security != authentication, authentication != certificates

dlang — Sun, 19 Jun 2011 10:33:03 +0000

I haven't heard of SSH being attacked via man-in-the-middle, but I have heard of cases where SSH has been used as the method of attacking by stealing copies of the keys on the client side.

this isn't a flaw in SSH, it's a flaw in the common deployment scenario where SSH is configured to trust client keys without some other (strong) form of authentication

Security != authentication, authentication != certificates

djao — Sun, 19 Jun 2011 10:00:17 +0000

As you just said, users aren't educated enough to know the difference between the right key and the wrong one, and users don't check the fingerprints on SSH, even though they should.

Yet, despite all this, SSH does in fact work very well. When was the last time you ever heard of a successful man-in-the-middle attack against SSH in the wild? I know I've never heard of any. It can't possibly be for lack of trying, given the huge payoff for a successful attack (root shell in many cases).

Rather than dismissing SSH's lack of authentication, I think it's worth trying to understand why SSH works so well. Maybe browsers and email clients should start caching fingerprints. (You're right that none currently does.) I don't have all the answers, but I can tell you one thing for sure: certificates aren't the reason why SSH works, since SSH doesn't use certificates.

Security != authentication, authentication != certificates

Lennie — Sun, 19 Jun 2011 09:36:04 +0000

I'm sorry, but the general public is not educated enough in this field to know the difference between the right fingerprint and the wrong one. They have nothing to compare it to.

And usually the people that should be educated about it also don't check the fingerprints on SSH.

I don't know of any browser or email client which keeps a cache of fingerprints.

But I should probably not have mentioned what I mentioned.

Because manually addding a CA is obviously fine, as long as you transfer the CA-cert to the device through a secure channel.

Security != authentication, authentication != certificates

djao — Sun, 19 Jun 2011 03:17:01 +0000

SSH is a program that many people (including Jon, I'm sure) trust for use on root shells. SSH doesn't use real certificates. SSH doesn't even use self-signed certificates. As a matter of fact, SSH doesn't use any certificates whatsoever. Authentication is done using plain public keys. The first time you connect to a server, you don't even get that (you're asked to manually accept a key, which could potentially be a forgery).

According to you, without authentication, SSH "just isn't [secure]." Really? If so, how do you reconcile this claim with the mountain of real-world evidence that indicates otherwise?

Let's compare the two using a simple attack tree. Consider SSL. A typical web browser has some 500 certificate authorities that it trusts by default. If any one of those CAs is compromised (even if it's one that you don't use for your own certificates), then the attacker can man-in-the-middle everyone in the world. This has actually happened at least once (Comodo attack).

Now consider SSH. To launch a man-in-the-middle attack, the easiest way is to intercept and alter the victim's initial connection to the server. (Has this ever actually happened outside of a lab? My guess is no.) Failing that, you'll have to alter the victim's key cache in memory or on disk. Obviously if you have access to the victim's disk/memory then you can trivially break SSL as well.

The inescapable conclusion is that, if you want real security, you should cache and compare key fingerprints yourself rather than relying on a third party (or worse, 500 different third parties) to do the job for you.

SSH?

djao — Sun, 19 Jun 2011 02:48:39 +0000

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.

WebOS: the other Linux-based mobile platform

speedster1 — Sat, 18 Jun 2011 07:28:47 +0000

On my Pre, the keys are small but nicely separated so that you can get a feel for the keyboard pretty quickly. I use it sometimes for ssh sessions to my server; typing is not fast like a real keyboard, but not frustratingly inaccurate either.

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

speedster1 — Sat, 18 Jun 2011 07:21:43 +0000

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

WebOS: the other Linux-based mobile platform

iabervon — Fri, 17 Jun 2011 15:37:26 +0000

Beats me; I'm still using my Treo 650. Just because HP's goal seems to be to migrate PalmOS users to WebOS seamlessly (and without having them all go to Apple or a random Android vendor) doesn't mean they're successful at it.

WebOS: the other Linux-based mobile platform

marcH — Fri, 17 Jun 2011 13:19:06 +0000

Then please tell us more about these great and seamless Pilot->WebOS data migration solutions you are alluding to. I have not yet heard anything good about that.

This is doubtful...

TRS-80 — Fri, 17 Jun 2011 10:16:04 +0000

If so, it'll be undead in the way that MeeGo is undead; HP bought Palm because they want to put WebOS in a lot of products, just like MeeGo is apparently used in quite a few embedded products. Except that unlike MeeGo, there's still a phone vendor who wants to use it.

WebOS: the other Linux-based mobile platform

iabervon — Thu, 16 Jun 2011 19:29:40 +0000

The thing that makes WebOS make a lot more sense, from the odd UI to the lack of community interaction, is that it is targeted at the PalmOS user base, who don't want to change away from their late-90s PDAs and closed-source freeware apps (which were largely closed source because the authors didn't bother to distribute the source, and because the build environment was kind of ad-hoc). HP might like to make stuff more sane, but that requires dragging users into the 21st century, and the main market for these devices is really people who would rather have a Pilot than an iPhone.

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

iabervon — Thu, 16 Jun 2011 19:14:26 +0000

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

OpenEmbedded

iabervon — Thu, 16 Jun 2011 18:45:48 +0000

CA-signed certs aren't all that secure. The most secure certificate is a self-signed one whose fingerprint you know. (Or a cert signed by a CA you personally know and trust, if you trust that someone you personally know can run a CA without introducing insecurities.)

Jon's obviously got a "real" certificate (from Equifax) that lwn.net provides to authenticate itself to strangers, but why should Jon have to trust Equifax to authenticate himself to himself?

French telcos

yaap — Thu, 16 Jun 2011 15:33:10 +0000

> As one consequence of that, French mobile phone operators have collectively decided to make SIM-only plans uninteresting.

True, but this is changing right now. A new law will force cheaper SIM only contract (the contract will not include mandatory subsidy for a new phone, like "old" SIM only contacts where you didn't get a phone at first, but were still enrolled in their subsidy plan to get discount or free phone every couple years) soon, and one operator has started this already --- I just saw an add for it yesterday.
I don't know for sure, but I wouldn't be surprised if the law was a transposition of an EU directive.

WebOS: the other Linux-based mobile platform

a0321898@ti.com — Thu, 16 Jun 2011 15:20:47 +0000

Doesn't the "bogo" in "bogomips" essentially mean "bogus"? I don't really know much about bogomips, but I think this is one of those cases where it is especially misleading. I think the measurement is impacted by the cpufreq governor, which is likely ondemand, so the performance you are showing is in a low-power mode. You should expect the available "bogomips", whatever those really are, to be many times.

This really isn't that interesting of a point, but I would discourage the use of bogomips to talk about the performance of a device, despite the fact that you were saying that there is quite a bit of performance available. Some folks just might get the wrong idea if the number doesn't have some relevant meaning behind it.

WebOS: the other Linux-based mobile platform

wazoox — Thu, 16 Jun 2011 14:34:38 +0000

I find the Pre 1.5 keyboard perfectly usable, and I have hands large enough. It's not much different from the previous handspring/Palm keyboards, maybe very slightly smaller than the Treo 680.
However the form factor is excellent. Comparable phones are either much bigger, or lack a keyboard completely.

French telcos

marcH — Thu, 16 Jun 2011 12:09:38 +0000

> As one consequence of that, French mobile phone operators have collectively decided to make SIM-only plans uninteresting.

... and pre-paid plans even less interesting.

Anything cheap... isn't!

French telcos

marcH — Thu, 16 Jun 2011 10:14:40 +0000

> I lived in the NL, and it was indeed cheaper to take a sim-only contract. I moved to France, and here I could not find a sim-only contract that was financially advantageous.

The French land line broadband market is one of the best in Europe. No limit triple play set top box for 30 euros per month. For this price the only limit is usually just the bandwidth of your copper line and that's it. Fiber is being actively deployed in all major cities right now.

On the other hand, the French mobile phone market is probably the worst in Europe because of the collusion between mobile operators. They were fined 534 millions euros for that (just search "French mobile phones fined") yet things have not changed much.

As one consequence of that, French mobile phone operators have collectively decided to make SIM-only plans uninteresting.

There is some hope at the moment since one of the landline operator is entering the mobile market after finally defeating intense lobbying from the incumbents.

> One curious thing about France mobile phone market is that the law requires that every phone sold locked to also be available for purchase unlocked.

This is not specific to mobile phones: laws against tying are very strong in France. You generally must offer the products separately as well.

http://en.wikipedia.org/wiki/Tying_(commerce)

US carriers charge the same price with or without a contract

mitchskin — Thu, 16 Jun 2011 10:02:10 +0000

I had the T-Mobile plan that I think you're talking about (the "Even More Plus" one), and it's true that they've taken it off of the website (although apparently you can still get it if you call in or go to a store). Now, though, I have a t-mobile prepaid plan (no subsidy, no contract) that's roughly as nice as the even more plus ones. They have unlimited prepaid plans that renew monthly, and some of those monthly plans include data. I'm paying about as much as before, but I now have unlimited minutes which I didn't have with my "even more plus" plan.

Prepaid is growing a lot, and it doesn't lend itself to a contract subsidy, and it's aimed at a very price-conscious market, so I'm hopeful that there'll continue to be useful no-contract options. In the past it was hard to get data in a prepaid context, but as data becomes more and more important, I think that'll change.

I agree that carriers want to own the relationship, but I'm hopeful that it'll get more difficult for them to do that with prepaid.

US carriers charge the same price with or without a contract

ekj — Thu, 16 Jun 2011 09:40:44 +0000

Is this really the case for USA ?

Up here (Norway) the best no-phone contracts are *SIGNIFICANTLY* cheaper than the best phone-included contracts, and most of the time the difference is enough that the price-differential over the length of the contract comes out to the same, or more, than what buying a unlocked phone costs.

Indeed, many of the with-phone contracts have two distinct prices, one for the first year (that covers the phone) and one thereafter, which makes it pretty darn clear that it's just a credit-buy.

For example, on the way to work today, I saw an offer for an Iphone for no-money-down, but you had to sign up for a 12-month contract that costs $120/month -- the *exact* same contract, from the same provider, is available for $70/month without a phone.

This makes it -perfectly- clear that you're paying $50/month, or $600 over that year for the phone.

US carriers charge the same price with or without a contract

fb — Thu, 16 Jun 2011 09:31:15 +0000

I lived in the NL, and it was indeed cheaper to take a sim-only contract. I moved to France, and here I could not find a sim-only contract that was financially advantageous.

One curious thing about France mobile phone market is that the law requires that every phone sold locked to also be available for purchase unlocked.

WebOS: the other Linux-based mobile platform

Kluge — Thu, 16 Jun 2011 04:23:26 +0000

Thanks for the suggestions.

I'm being picky, I know (they are *personal* electronics, after all), but the big Android sliders aren't quite "pocketable" enough for my taste. Granted, they are much more suitable for email and browsing than a Blackberry bar phone, but I like having something that can sit in a pocket without being noticeable. A friend has the G2, and it's very nice, aside from the battery life. Just a little too big.

While I know Sony Ericsson isn't a *wholly* owned subsidiary of Sony, I still try to avoid any Sony-affiliated products, given their past behavior.

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

Lennie — Thu, 16 Jun 2011 00:42:15 +0000

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.

This is doubtful...

Lennie — Thu, 16 Jun 2011 00:36:25 +0000

An other reason Nokia went with Microsoft is they gave Nokia a large sum of money "as advertising budget".

US carriers charge the same price with or without a contract

Lennie — Thu, 16 Jun 2011 00:33:50 +0000

Atleast in my country (the Netherlands in Europe) a SIM-only is a lot cheaper than a contract which subsidies a phone.

There is also a law which says that if a provider locked the phone you should be able to get it unlocked by the provider.

So if you have a phone from such a contract and it runs out your provider has to unlock it and you can get a SIM-only contract and pay less.