Laurie: Improving SSL certificate security [LWN.net]

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 15:40 UTC (Wed) by nybble41 (subscriber, #55106)
In reply to: Laurie: Improving SSL certificate security by djao
Parent article: 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.

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.

to post comments

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 16:01 UTC (Wed) by djao (guest, #4263) [Link] (10 responses)

You are correct. I was oversimplifying.

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 17:56 UTC (Wed) by jthill (subscriber, #56558) [Link] (9 responses)

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

Posted Apr 6, 2011 18:10 UTC (Wed) by djao (guest, #4263) [Link] (8 responses)

I have "security theater" as meaning practices that even if followed don't achieve anything notable. This isn't that.

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.

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 20:31 UTC (Wed) by jthill (subscriber, #56558) [Link] (7 responses)

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.

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?

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 0:06 UTC (Thu) by Lennie (subscriber, #49641) [Link]

Atleast in Firefox you could probably just disable all current CA and install certificate patrol.

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:

http://etherpad.mozilla.com:9000/FOIS

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 11:50 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

The Microsoft research found (I am paraphrasing but you should be able to find it easily enough) that users basically ignore everything except a hard stop.

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.

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 15:09 UTC (Thu) by djao (guest, #4263) [Link] (2 responses)

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

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.

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 16:38 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

Cached SSH host keys are stored in known_hosts, not authorized_keys. The latter file is where you put the public keys used to identify SSH clients instead of, or in addition to, password authentication.

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 16:58 UTC (Thu) by djao (guest, #4263) [Link]

Oops, yes, typo (or thinko). The rest of my post is accurate to my knowledge.

Laurie: Improving SSL certificate security

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.

Laurie: Improving SSL certificate security

Posted Apr 21, 2011 12:36 UTC (Thu) by robbe (guest, #16131) [Link]

My company uses a SSL MITM to do virus scanning of https streams. This poses other problems, but a nice feature is that whenever this MITM proxy can't validate a certificate (expired, no link to a trusted root), the user just gets an error page. No simple way around it, the only option is to call an admin, who will do some serious vetting (hopefully!) of the cert, and maybe put it on the exception list.