Why it's there in the first place, then? [LWN.net]

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

Posted Jun 15, 2011 10:54 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Why it's there in the first place, then? by khim
Parent article: WebOS: the other Linux-based mobile platform

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.

to post comments

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 (guest, #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).