Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Posted Apr 6, 2011 0:46 UTC (Wed) by djao (guest, #4263)In reply to: Laurie: Improving SSL certificate security by Lennie
Parent article: Laurie: Improving SSL certificate security
How do you replace a stolen private-key and how do you communicate this to the users ?This sounds like a big problem, but it really isn't. Stolen private keys do not happen very frequently. During natural usage of the system, users learn to accept a low background frequency of legitimate key changes. This is exactly what has happened with SSH, with no effect on systemic security, since active attacks in practice tend to cause rather higher rates of key turnover than the background rate, and thus get noticed. I expect the same to happen for SSL. In other words, no solution is needed -- keep the security model simple, and users will naturally devise the best available coping mechanism in response to any given problem. This is very much the opposite of SSL's heavyweight specification that tries to address all outcomes and ends up addressing none (see below).
All of your questions so far are a great example of "what if?" scenarios that sound great on paper, but in all cases, if you actually go out and run the system in a real-life operational setting, you'll find that in practice the problems that SSL certificates successfully solve aren't really big problems in production, and the problems that SSL certificates fail badly to solve are exactly the problems that really matter.
And once again, it's not legitimate to ask this question without also asking the same question of the status quo, and comparing the two answers. Under the existing SSL system, a stolen private key is at least as large a problem as it is in SSH. In theory, the SSL specification contains a key revocation mechanism, but as the Comodo attack itself demonstrates, this mechanism is utterly useless in practice. The latter is yet another example of the disconnect between theory and practice that pervades the broken SSL standard.
I am a professional cryptographer. I publish cryptography papers as part of my career. My position on this issue is not very popular among cryptographers, most of whom are great theoreticians but terrible practicians. Human factors alone imply that the idea of certificates is always going to be totally unworkable on the public internet. There is no minor tweak that can fix the SSL certificate system. The only viable approach is to scrap the system entirely. You can perhaps see why my position is unpopular, since I am basically pointing out that the last twenty years of research and investment in PKI is completely worthless and cannot be salvaged.
Also how do make this model backwardcompatible, in the old model most keys or atleast certificates are replaced every year.
Backward compatibility only affects web browsers, not servers: my proposal requires eliminating certificate authorities, so that servers no longer have certificates, and it is not possible for a server to both have a certificate and to not have a certificate. Anything short of complete elimination of certificate authorities does not represent progress, since a security system is only as strong as its weakest link, and certificate authorities are the weakest link.
For web browsers, a limited form of backward compatibility is easy to implement. When connecting to a server that offers a valid certificate, cache the certificate authority instead of the key. Even if the key changes legitimately, the CA almost always remains constant during legitimate key changes. This allows web browsers to deploy cache-and-compare without affecting existing certificates. Eventually, when almost all web browsers support cache-and-compare, servers can switch away from certificates. Finally, once all servers stop using certificates, the web browsers can delete certificate support. This strategy accomplishes the transition in three mutually compatible stages.
More generally, it is important to examine and understand the hidden assumptions underlying your question. The reason why certificates are replaced with high frequency in the current model is because the certificate authorities earn more money with frequent turnover: with short expiration dates, they generate more certificates in a given amount of time. By eliminating the certificate authorities, you also simultaneously eliminate the financial incentive for frequent key turnover. Backward compatibility in the sense that you describe is only necessary as a temporary transitional measure, since it is the current system itself that creates the need for frequent key replacement, and I am proposing to eliminate the current system.
Posted Apr 6, 2011 7:50 UTC (Wed)
by Lennie (subscriber, #49641)
[Link] (15 responses)
The user can do 2 things the safe option or just continue because "it might be alright".
I don't know if you have actually seen a non-technical user, but I don't know how this will work.
When they see such a thing the first time, they might ask someone and they check something and tell the user: 'this is ok'.
Then when a man-in-the-middle-attack occurs, they just click ok and keep going.
The whole idea of PKI is that you have have a third party help to determine/identify if this is the server you would want to connect to.
___
Actually, I get my certificates for free: https://www.startssl.com/
So I don't think they have the high turnover rates because they make more money.
You actually pay 1 amount per year for all the domains you want if you want more verification.
Posted Apr 6, 2011 13:21 UTC (Wed)
by djao (guest, #4263)
[Link] (14 responses)
When a website gives an error (because the key has changed), the user needs to actively delete the old key out-of-band in order to resolve the error. This is what OpenSSH does; a few other SSH implementations handle this situation differently. Note that OpenSSH fails safe -- if the program detects that the connection would be unsafe, then it prevents the user from connecting. This is very very different from the SSL approach where all too often the system fails unsafe. You might not think this will work, but you haven't tried it. In practice, contrary to all intuition, it really does work. A non-technical user has to learn once in their life the concept of "this was the old key; it has changed." Admittedly, that concept is hard for many users to master, but are you seriously suggesting that the concept of certificates is easier?
Another reason why it works in practice is that, since changing keys is so disruptive, the SSH error mechanism naturally provides a very strong incentive for site operators to preserve their keys and keep them secure. This makes key changes very rare compared to SSL, where there is very little incentive to maintain static keys. So it is wrong to extrapolate from your experience with SSL the expected rate of key turnover.
Regarding man-in-the-middle attacks, the cache-and-compare system is not perfect, as you rightly point out, but you omit the crucial observation that the certificate system is even more flawed, and by a wide margin. Of course the whole idea of PKI is that you have a third party help to determine/identify if this is the server you would want to connect to. But this idea is fatally flawed in practice. There are too many untrustworthy third parties, and too many avenues for attack, and too many possibilities for undetectable attack, and the system is too complicated for a regular user to tell the difference between legitimate and illegitimate operation.
Your example of StartSSL, rather than supporting your position, actually supports mine. It's nice for individual users that they give "free" keys (although arguably not so nice for internet security that one can obtain legitimate SSL certificates just by hacking the owner's gmail account). But the free keys are only valid for one year. For most companies, the cost of staff time to renew a certificate every year is more than the cost of a paid certificate having (say) two years validity. And indeed StartSSL counts on this to make their money. This was exactly the point I was making: StartSSL has a financial incentive to limit the validity period of certificates to very short periods such as 1 or 2 years. You will never see any 10-year certificates available for free, and even 10 years is short by my standards: I still have and use SSH keys from 12 years ago, when SSH2 was first released.
Posted Apr 6, 2011 15:40 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (11 responses)
Actually, SSH warns you that the server is unknown, shows you the fingerprint of the unknown server's host key, and asks whether you want to accept it. Only after you answer affirmatively is the host key cached for future use. You're supposed to validate the key via some out-of-band communication channel before telling SSH to accept it.
This is analogous to the existing warning page for self-signed SSL certificates in most major web browsers; you somehow validate the self-signed certificate, and then add it to the browser's exception list, after which you no longer receive the warning.
Posted Apr 6, 2011 16:01 UTC (Wed)
by djao (guest, #4263)
[Link] (10 responses)
However, in practice (note again the dramatic difference between theory and practice -- the main point that I have been stressing throughout this entire discussion), nobody ever validates the key out-of-band. And you know what? IT WORKS! SSH does not have, and has never had, any of the structural security flaws inherent in SSL. SSH has a different set of structural security flaws, but these flaws matter little in practice. Functionally there is no difference between what SSH actually does, and what I over-simplistically represented it as doing, because users in practice never verify the public key -- you might as well just accept it automatically.
I think anybody who insists on preserving out-of-band verification or any other security theater is totally missing the point. Actual, real life, non-technical users are far better served by my suggestion to automatically cache the key. Maybe (at most) the browser or ssh client can display the fingerprint for informational purposes (note: informational purposes, not approval purposes), for the benefit of the 1% of users who know how to validate a key out-of-band. All the crypto theory saying that users must validate the key out-of-band is just totally impractical and invalid, because it completely fails to take into account all known principles of usability.
Posted Apr 6, 2011 17:56 UTC (Wed)
by jthill (subscriber, #56558)
[Link] (9 responses)
Posted Apr 6, 2011 18:10 UTC (Wed)
by djao (guest, #4263)
[Link] (8 responses)
True. I am (mis)using security theater in a slightly different sense, but I argue that the effect is just as bad. If the inclusion of a security countermeasure in an internet standard makes no practical difference due to the unavoidable fact that real life users lack the skill to use the countermeasure in the intended way, then I argue that the countermeasure is just as useless as the usual, standard security theater. Both out-of-band key management and SSL certificates fit this definition to a tee.
I don't mind it if out-of-band key management or SSL certificates are permitted in the standard as optional elements for the very small minority of users capable of using them. But to make them mandatory is the height of folly.
Posted Apr 6, 2011 20:31 UTC (Wed)
by jthill (subscriber, #56558)
[Link] (7 responses)
Yes? I think that's a very good point, now I just hope it's yours and I understood your reasoning correctly.
I think getting that done would have to be a matter of just doing it -- the political opposition to offering an alternative to CAs would be fierce. How hard would it be to maintain a patch getting mozilla or chromium to act this way?
Posted Apr 7, 2011 0:06 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
If not, it can probably be changed to do whatever you want it to do as it isn't a lot of code:
http://www.psyc.eu/navigate/certpatrol/content/
Also Mozilla is discussing ideas here:
Posted Apr 7, 2011 11:50 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
Red or missing icons, "Are you sure?" messages, changed site layout, missing authentication steps, none of those clue in the ordinary users Microsoft studied that something is wrong. A Firefox-style full-page warning which requires considerable extra steps tugs at them slightly, but not enough to stop most from continuing to enter valuable financial details.
Users don't have the sophistication we assume in our security designs. Even in djao's much simplified system.
SSH works better mostly because it's used by more technical users. Boring, but true.
Any system that doesn't have a hard stop won't be effective. The response to any validation failure, security problem, error etc. has to be "You can't view that website". No "If you're really sure click this" because every single ordinary user will click the button for an easier life. It's just human nature.
Posted Apr 7, 2011 15:09 UTC (Thu)
by djao (guest, #4263)
[Link] (2 responses)
Although there are obviously legitimate reasons for key changes, on balance they should be rare, unusual events. (Cryptographers will scream and protest, since frequent key changes lead to more interesting problems, more research grants, etc., but let's face it, real world users operate under different assumptions and have different needs.) Let's provide the correct incentives to achieve the optimal balance, rather than the current system which encourages frequent and superfluous key changes.
It is true that SSH has a more technical userbase, and that even the simplest system that I can think of is still too complex for regular users. But this is hardly a reason to support the current certificates system.
Posted Apr 7, 2011 16:38 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Posted Apr 7, 2011 16:58 UTC (Thu)
by djao (guest, #4263)
[Link]
Posted Apr 7, 2011 17:27 UTC (Thu)
by jthill (subscriber, #56558)
[Link]
I think that makes the division of responsibility pretty clear. Why users behave that way is a research question. That there's limits to what a browser can do to keep them safe is established.
But I don't see how it affects the observation that CAs don't help in either case. Keeping the CA infrastructure is abdicating real responsibility in pursuit of an illusory one. Either way, the real security theater is here, not with any onoz.gif warnings.
And SSH might work better because of what djao said: it does exactly what the research says is necessary. It refuses to connect on a key mismatch.
Posted Apr 21, 2011 12:36 UTC (Thu)
by robbe (guest, #16131)
[Link]
Posted Apr 6, 2011 17:56 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
because this lets the CAs charge people more every year to maintain their website.
Posted Apr 6, 2011 18:28 UTC (Wed)
by djao (guest, #4263)
[Link]
Perhaps you are confusing me with Lennie.
Laurie: Improving SSL certificate security
When a user first visits a website, they do nothing special. The browser automatically caches the key. This is what SSH does.
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
You are correct. I was oversimplifying.
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
out-of-band verification or any other security theater
I have "security theater" as meaning practices that even if followed don't achieve anything notable. This isn't that.
automatically cache the key
No. That practically no one ever actually checks the digits is true, but I don't think it means what you think it means. What you're proposing would mean you're the one managing the risk now, not the users. Just ... no.
Laurie: Improving SSL certificate security
I have "security theater" as meaning practices that even if followed don't achieve anything notable. This isn't that.
No. That practically no one ever actually checks the digits is true, but I don't think it means what you think it means. What you're proposing would mean you're the one managing the risk now, not the users. Just ... no.
I maintain that there is in practice no difference in actual effect between what SSH does right now, and automatic acceptance of the initial key. Nothing you said contradicts that.
So to go for brevity at the expense of putting it too crudely, the basic idea is that any user too dull to be suspicious of a new key isn't going to have enough brainpower to understand any explanation anyone can offer.
Looked at that way, I'd call the new-site-new-key warnings that browsers pop now "unnecessary drama" (which I think is accurate, and doesn't dilute the other term). It's the most common situation for getting a new key and the least likely to be a sign of trouble, so fer cryin out loud just install the thing and maybe post a diffident "It doesn't appear you've used this site before from this browser. As an [identifier] they offered [this]; I'll remember it as theirs from now on. [OK]" For changed keys, put enough stutter-steps in the procedure that if they do have the wit to be suspicious they might even click the "How do I know this isn't an impostor?" button in the UI for that.
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
To be clear, OpenSSH and the official SSH clients (with strict host checking on, which is the default setting) do come to a full stop when they detect a key change, and this is what I recommend. You have to run a separate program (ssh-keygen with the -R option), or hand-edit the authorized_keys file using a text editor, and delete the offending cached entry in order to connect. The ssh client's error message does not tell the user how to do these things, so you have to know it already, or look it up in man pages etc., something that a non-technical user will not do. (Other SSH implementations handle this differently.)
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Laurie: Improving SSL certificate security
Uh, excuse me? I agree with you 100%. Certificates change very frequently because the CAs have a strong financial incentive to use short expiry times. That is exactly the position I was arguing.
Laurie: Improving SSL certificate security