Laurie: Improving SSL certificate security [LWN.net]

Laurie: Improving SSL certificate security

Posted Apr 9, 2011 21:18 UTC (Sat) by dmag (guest, #17775)
In reply to: Laurie: Improving SSL certificate security by djao
Parent article: Laurie: Improving SSL certificate security

I really like your arguments, although I'm not sure I fully understand your plan (i.e. exactly what happens on 1st use.) Here's my idea:

1) *NEVER* prompt on first key use. (unless you're also going to prompt on all un-encrypted use too!) I browse too many sites to worry about individual ones.

2) When a user cares, (i.e. goes to enter some data), they are trained to glance at the lock icon. The lock icon always will be RED and unhappy looking unless the cert (or a parent cert) has been *explicitly* trusted before. (Ideally, it would pop up and yell if entering personal info on an untrusted connection.)

3) At any time, the user can explicitly click "trust cert" or "trust CA" (heck, there could be chain of CAs, and they can trust at any level they want.) This should be 2 clicks (one on the lock, one on the scary dialog), and it should have "you've seen this cert N times before on these websites..". Obviously, the browser should start with an empty list. There should be an easy way import a list of certs (i.e. "go to firefox.com, click the lock and click 'trust' to get the old firefox list")

4) When a cert is trusted (click on the lock), it shows the whole chain (not just the cert).

5) Ideally, there should be a way to sign *OTHER* people's certs, so anyone can participate in the WoT.

to post comments

Laurie: Improving SSL certificate security

Posted Apr 9, 2011 23:20 UTC (Sat) by djao (guest, #4263) [Link] (4 responses)

I propose to do what SSH does, except that (unlike SSH) the system should not prompt on first key use.

Your system is not quite the same as what I propose, since your system depends on asking the user to explicitly set trust levels. Your system is analogous to PGP/GnuPG. Well, PGP/GnuPG is a failure in the marketplace. Most of our email is still unencrypted. Contrast this with SSH, which has succeeded in eliminating telnet -- most remote logins are encrypted.

SSH is the only cryptographic protocol in human history that has achieved marketplace dominance over its corresponding unencrypted version. We should pay attention to the things that SSH does right.

In the SSH system, trust levels, by default, are determined by one and only one question: "Is this key the same as the key that I was given before?" Advanced users can do things differently, by manually editing the known_hosts file, but the default mode of operation is what I described.

Your proposal requires user training to interpret trust levels. Your proposal requires user action to set trust levels. Based on all available evidence so far, any cryptographic protocol that requires even minimal user participation will not succeed, in the sense above (namely, it will not completely eliminate the corresponding unsecured protocol). A security program needs to have safe, usable, automatic defaults. It is worth compromising some security in order to increase usability or decrease the amount of user input. Advanced users will figure out how to recapture the lost security, so they lose nothing. Unskilled users gain the ability to use the program, and thus even with the compromise are more secure than they were before; without safe, automatic defaults, unskilled users would have no security.

A web of trust is terrible in practice. PKI is terrible in practice. These concepts should be optional elements of the standard, for advanced users to deploy if they wish. The default behavior for novice users must be, and can only be: 1. On first use, cache the key and trust it. 2. Trust all previously cached keys. 3. Hard stop when encountering untrusted keys.

Laurie: Improving SSL certificate security

Posted Apr 10, 2011 18:47 UTC (Sun) by juhah (subscriber, #32930) [Link]

I like your proposal.

Few ideas how it might be further improved:

1. On first use, query pool of certificate fingerprint servers and check that others see what you see. Not a fool proof but helps in any case. Hard stop only if severs see different fingerprint. This has a potential privacy issue though.

2. Allow certificate to be updated without hard stop by caching fingerprint of next valid certificate immediately after storing the initial certificate. Hard stop if certificate changes and the new certificate fingerprint doesn't match the previously stored fingerprint.

Laurie: Improving SSL certificate security

Posted Apr 10, 2011 20:25 UTC (Sun) by dmag (guest, #17775) [Link] (2 responses)

> PGP/GnuPG is a failure in the marketplace

I hear you. I've read the directions dozens of times, but never set it up...

> SSH is the only cryptographic protocol in human history that has achieved marketplace dominance over its corresponding unencrypted version.

Agreed, but why? I claim it has nothing to do with the "security model" per se (other than it's not *too* annoying), and more to do with having a killer feature that Telnet doesn't have: The ability to log in without a password prompt. (I've forgotten how annoying that was!) If telnet could do that (without being insecure like rsh), people would still be demanding telnet enabled by default.

My takeaway is that we need a "killer app" for HTTPS that doesn't work under HTTP. Imagine if browser makers said "cookies should not work under HTTP by default".

> In the SSH system, trust levels, by default, are determined by one and only one question: "Is this key the same as the key that I was given before?"

Er, no. If you've seen the key a hundred times, but haven't said "yes I trust it", then it will will still prompt you. I think we agree "popup until trusted" is NOT a good solution for the web. So I'm still confused on what you're proposing.

Also, I think SSH is used with a *small* number of hosts, so "keeping a database" isn't that big of a deal. On the other hand, keeping a database of every (HTTPS) website you've ever browsed seems like a big deal.

Plus, for SSH, I care 100% of the time about trusting my hosts. For browsing the web, "trust" isn't a useful concept 99% of the time. When I browse a random Geocities page, I don't care about trust.

> Hard stop when encountering untrusted keys.

Er, I'm still confused by what this means. Browser a pop-up? How does a key go from untrusted to trusted? And should un-encrypted sites be more trusted that unknown encrypted sites?

As an aside: I think people's solutions tend to be influenced by their goals. The current system _seems_ like it was ONLY designed to enable e-commerce. By that measure, it's a roaring success. Of course, measured most other ways, it's a miserable failure.

Laurie: Improving SSL certificate security

Posted Apr 10, 2011 21:51 UTC (Sun) by djao (guest, #4263) [Link]

Agreed, but why? I claim it has nothing to do with the "security model" per se (other than it's not *too* annoying), and more to do with having a killer feature that Telnet doesn't have: The ability to log in without a password prompt.

I disagree in the strongest possible terms. It takes a relatively advanced user to configure passwordless authentication. Novice users see no point in this feature, since you have to type in a passphrase anyway, and they have no conceptual model capable of distinguishing passphrases from passwords; neither do they appreciate the benefits of multitasking by using an agent. The entire thesis of my argument is that SSH's success is attributable to its adroit handling of novice users, and its ability to provision them with maximal usability together with some security.

Only a very small minority of SSH users use passwordless authentication. I cannot believe that this minority is responsible for marketplace success. If such a small minority could determine marketplace success, then PGP would have succeeded as well. Could you be right? Sure, you could, but you're arguing the complete opposite of what I'm arguing.

Er, no. If you've seen the key a hundred times, but haven't said "yes I trust it", then it will will still prompt you.

Technically true, but quite misleading. When you connect for the first time, you are asked if you trust the key. By default, if you say no, you can't connect at all. (It is possible to configure this behavior differently, but only relatively advanced users do this.) So your implication that one can see a key a hundred times without saying "yes I trust it" is off the mark. In order even to succeed in connecting for the very first time, you need to indicate that you trust the key. There is no one (that I know, anyway) who would initiate 100 connection attempts, say "no" to the trust question (and thus failing to connect each time), and then say "yes" on the 101st.

Example of a session demonstrating what I just said:

[djao@laptop:~]$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 76:27:d1:f3:a5:71:75:61:7b:b5:94:ce:f4:d9:81:20.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
[djao@laptop:~]$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 76:27:d1:f3:a5:71:75:61:7b:b5:94:ce:f4:d9:81:20.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Last login: Fri Apr  1 12:19:11 2011 from laptop.dominia.org
[djao@laptop:~]$ exit
logout
Connection to localhost closed.

[djao@laptop:~]$ ssh localhost
Last login: Sun Apr 10 17:30:37 2011 from laptop.dominia.org
[djao@laptop:~]$

Er, I'm still confused by what this [hard stop] means.

Between this comment and the previous one above, it sounds like you have absolutely no firsthand experience at all with either OpenSSH or with the official SSH client (and I'm a little puzzled why you seem to imply in your replies that you do have such experience). Hard stop means that if a key does not match the trusted key, then SSH will not complete the connection, and will not allow the user to override this decision via any mechanism within the program itself. OpenSSH exhibits this behavior under its default configuration, and I am honestly surprised that you have never encountered it. Here's an example:

[djao@laptop:~]$ ssh iso
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
76:27:d1:f3:a5:71:75:61:7b:b5:94:ce:f4:d9:81:20.
Please contact your system administrator.
Add correct host key in /home/djao/.ssh/known_hosts to get rid of this message.
Offending key in /home/djao/.ssh/known_hosts:275
RSA host key for isomorphism.org has changed and you have requested strict checking.
Host key verification failed.
[djao@laptop:~]$

Laurie: Improving SSL certificate security

Posted Apr 11, 2011 1:05 UTC (Mon) by dlang (guest, #313) [Link]

I think you need to be careful how you define SSH as a 'success'

yes lots of people use it, by that definition it's a success, but the reason for this is convenience, not security.

it's much more convenient to transfer files via scp than it is to use ftp, the fact that 'telnet' functionality, file transfer functionality, and tunneling functionality all happen over the same port is 'convenient' (as long as you don't want to allow some of these functions and not others)

it's also widespread because it's become a 'checkbox security' item that auditors can understand (you use telnet with one-time passwords, evil, you use ssh with passwordless access and everyone able to sudo, wonderful)

I don't believe that good security practices around ssh are nearly as widespread as security people seem to think. I believe that most people will not care about any ssh warnings, and will do whatever it takes to clear them if they come up (as opposed to actually worrying that the system has been compromised)