Laurie: Improving SSL certificate security [LWN.net]

Laurie: Improving SSL certificate security

Posted Apr 2, 2011 14:35 UTC (Sat) by kleptog (subscriber, #1183)
In reply to: Laurie: Improving SSL certificate security by Lennie
Parent article: Laurie: Improving SSL certificate security

Yeah, EV certificates do have added value. But the green bar... I've helped family members with internet banking and pointed out the green bar. Invariably the response is: "oh, never noticed that before".

ISTM a great example of a technical solution not solving a social problem. There's a lot of user education still to be done.

to post comments

Laurie: Improving SSL certificate security

Posted Apr 2, 2011 22:13 UTC (Sat) by drag (guest, #31333) [Link] (37 responses)

What may be needed, I think, is a second mechanism for inputting financial information that is separate from web pages.

That is a browser should support a special dialog just for entering in bank/personal/private information. Hell it should probably be a entirely different application.

Jut a side channel: a secure protocol just specifically for sensitive information and a simple program to go with it. Not under control of your bank or anything. It asks for what information and then the program prompts you for it after analyzing the security of the connection for you.

Credt card information, bank account information, usernames and password.

No html, no javascript, no nothing. Just pure client-only program with no controls given by the page your connecting to. With a protocol designed from the ground up with security as the primary aim.

This 'green bar' stuff isn't working.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 0:00 UTC (Sun) by tzafrir (subscriber, #11501) [Link] (36 responses)

And how can you tell paypal.com from pay-pal.com? Which of them is the real one? Or pay-pal.com from pay-paI.com?

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 1:29 UTC (Sun) by drag (guest, #31333) [Link] (35 responses)

How do you tell your SSH server is _your_ SSH server?

Previous history with the services and cache'd certificates/credentials will protect established users from phonies. If the service does not match what is established in your records, then it won't allow connection.

The riskiest time is when you sign up with a new service. But you still manage to reduce the problem to the first time you connect versus re-identifying the service from scratch each time you use a new browser session.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 11:38 UTC (Sun) by tzafrir (subscriber, #11501) [Link] (5 responses)

There are quite a few "new times". Just send out many phony messages, and hope you meet someone with a blank history on the current client. E.g. on an internet cafe.

The method of ssh simply ignores the problem altogether. It's not really useful. You might as well educate users to accept self-signed certificates. It's basically the same.

Bingo

Posted Apr 3, 2011 14:30 UTC (Sun) by khim (subscriber, #9252) [Link] (4 responses)

The method of ssh simply ignores the problem altogether. It's not really useful. You might as well educate users to accept self-signed certificates. It's basically the same.

Bingo! Self-signed certificate is exactly right solution. My bank uses "green bar" for normal people, but for large clients (you know, the ones who transfer millions around) they use self-signed certificate. How come? Easy: they give you paper instructions in sealed envelope (which you get in bank personally), it contains fingerprint, etc. If you don't see the "unknown certificate" window - it's fraud, if you see the window and certeficate does not match - it's fraud, if you ever see the window again - please call the bank and you'll get another sealed envelope if the certificate is really changed.

All these talks about "side channels" are missing the point: in most cases where fraud may deprive you of sizable sum you already have a "side channel" - you just need to use it.

Bingo

Posted Apr 3, 2011 15:29 UTC (Sun) by drag (guest, #31333) [Link] (2 responses)

> There are quite a few "new times". Just send out many phony messages, and hope you meet someone with a blank history on the current client. E.g. on an internet cafe.

If a user is carrying about banking stuff via internet cafes there is NO effective way to secure it. Bringing something like that up is just silly.

> Bingo! Self-signed certificate is exactly right solution. My bank uses "green bar" for normal people, but for large clients (you know, the ones who transfer millions around) they use self-signed certificate. How come?

People that transfer 'millions' around are generally businesses. Financial institutions use insecure FTP connections or SFTP (ssh) with a throw away user account. They don't actually get real Unix accounts with vsftp or openssh most of the time. It's just some Java program that provides support for multiple protocols to suite the purposes of the client.

Actual security is provided through PGP encryption/signing of the files being transfered. The protocols used to transfer the files are not trusted.

If it's 'realtime' style connection they will use things like FIX or FIXML connection on a dedicated data line (or at the least a IPSEC tunnel) were all traffic is logged and monitored.

> All these talks about "side channels" are missing the point: in most cases where fraud may deprive you of sizable sum you already have a "side channel" - you just need to use it.

It would solve the biggest threats to average consumers which are going to be things like Phony websites with fraudulent SSL certs and XSS attacks.

Consumer banking, to put it bluntly, are incompetent at designing website applications. They do a shitty job and can't be trusted.

Bingo

Posted Apr 3, 2011 16:31 UTC (Sun) by paulj (subscriber, #341) [Link]

Agreed. Indeed, I've seen *email* used to transfer files whose *content* were worth literally millions of Euro (the data itself - not transferring money between accounts). Secured, just as you say, with PGP.

Bingo

Posted Apr 3, 2011 18:29 UTC (Sun) by jthill (subscriber, #56558) [Link]

Actual security is provided through PGP encryption/signing of the files being transfered. The protocols used to transfer the files are not trusted.

Not to detract from your point, but I think it's worth highlighting that SSL itself is equivalent to PGP. Browsers use a precanned trustdb, but it's the quality of the trustdb the browser vendors deliver that's in question here. Any precanned PGP trustdb will be just as vulnerable, in exactly the same ways. Phil Zimmerman (et al.) was right, a WoT is the only acceptable substitute for personal verification. That's what Google is trying to implement, without making anybody admit it in so many words.

Bingo

Posted Apr 3, 2011 16:56 UTC (Sun) by jthill (subscriber, #56558) [Link]

I'm having a good time remembering the FUD-storm the CA's kick up when anyone tries telling this little home truth in public. It came up on /. a year or so ago and the professional confusers were out in force.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 22:09 UTC (Sun) by Lennie (subscriber, #49641) [Link] (28 responses)

I think it is really interresting how SSH comes up every time there is talk about SSL/TLS.

But what about if you are not a technical user ?

How do you make sure you are visiting the right site (the first time) ?

What about if you are at an internet cafe or somewhere else where you don't have your 'history'.

I have a Firefox addon installed which does this, but most certificates get replaced every year.

It tells me things like: the CA changed and the old certificate was still valid for 3 weeks.

So was this something the company that owns the website did ? or not ?

As a technical user I don't even know.

I think the use of perspectives or similair like in the article is better.

Laurie: Improving SSL certificate security

Posted Apr 5, 2011 17:45 UTC (Tue) by djao (guest, #4263) [Link] (25 responses)

But what about if you are not a technical user ?

The current certificate-based model is much more opaque to non-technical users than the relatively simple concept of "this certificate is the same as the previous one."

How do you make sure you are visiting the right site (the first time) ?

This is a genuine problem, but as I stressed above, it absolutely pales in comparison with the myriad unfixable problems posed by the current certificate-based model, especially when dealing with non-technical users.

It is impossible in real life for an adversary to consistently present a given user with an altered key 100% of the time. Network engineers have never been able to achieve 100% reliable operation even under cooperative scenarios, much less adversarial scenarios. The minute that the adversary makes a mistake, you will find out that something is wrong (just as SSH today emits a very nasty error when the certificate changes). Contrast this to the present situation, where large classes of successful attacks are completely and permanently undetectable.

What about if you are at an internet cafe or somewhere else where you don't have your 'history'.

An internet cafe presents all sorts of problems, of which the one you pointed out is the least concerning. A computer at an internet cafe could potentially contain a hardware keylogger or any of a million other security threats for which no defense is even theoretically possible.

I don't regard it as a priority for a security solution to handle situations such as internet cafes for which no effective defense is even theoretically possible.

I have a Firefox addon installed which does this, but most certificates get replaced every year.

The problem is one of chicken-and-egg. If browsers were to switch to the cache-and-compare security model, then web server administrators would start to place greater emphasis on long-lived keys. This would happen naturally, without any direct intervention. There are some drawbacks to long-lived keys, but again I emphasize: any drawbacks in the cache-and-compare model are utterly insignificant compared to the gaping wide unfixable flaws in the certificate model.

Millions of people, in companies large and small, trust the SSH security model for shell-level access to their servers. Not all of these users are super-technical. If SSH is good enough to secure shell access, it certainly is good enough to secure web access.

Laurie: Improving SSL certificate security

Posted Apr 5, 2011 22:03 UTC (Tue) by Lennie (subscriber, #49641) [Link] (18 responses)

OK, let's look at the current situation and the SSH-model.

How do you replace a stolen private-key and how do you communicate this to the users ?

Also how do make this model backwardcompatible, in the old model most keys or atleast certificates are replaced every year.

Laurie: Improving SSL certificate security

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

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 7:50 UTC (Wed) by Lennie (subscriber, #49641) [Link] (15 responses)

So what is this non-technical user gonna do when he first visits a webshop or his favorite webshop gives an error or warning that something changed.

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 13:21 UTC (Wed) by djao (guest, #4263) [Link] (14 responses)

When a user first visits a website, they do nothing special. The browser automatically caches the key. This is what SSH does.

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 15:40 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (11 responses)

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

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.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 17:56 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

you are missing the main reason why certs change every year.

because this lets the CAs charge people more every year to maintain their website.

Laurie: Improving SSL certificate security

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

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.

Perhaps you are confusing me with Lennie.

Laurie: Improving SSL certificate security

Posted Apr 7, 2011 0:53 UTC (Thu) by clint (subscriber, #7076) [Link]

You can use http://web.monkeysphere.info/ for that until something better comes along.

Laurie: Improving SSL certificate security

Posted Apr 9, 2011 21:18 UTC (Sat) by dmag (guest, #17775) [Link] (5 responses)

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.

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)

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 0:40 UTC (Wed) by martinfick (subscriber, #4455) [Link] (1 responses)

> What about if you are at an internet cafe or somewhere else where you don't have your 'history'.

Your can't trust it period, ever. If you don't own (control) the client, you are already compromised. An internet cafe can fake the entire browser experience if they want. Identifying the "other end" is a waste of time if you are not using a trusted client (i.e. your device, or a device which you trust).

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 7:42 UTC (Wed) by Lennie (subscriber, #49641) [Link]

I should probably have mentioned: computer of a friend instead of internet cafe.

I did mean anywhere else but home or work.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 12:33 UTC (Sun) by geuder (subscriber, #62854) [Link] (7 responses)

The social problem could solved by an extremely simple technical solution: The green bar is not always green, but it's red, yellow, purple just changing every day by a simple public algorithm that browsers implement only for EV certificates. Alternatively the green EV bar contains a small number icon containing 1,2,3. Online banks ask the user "What color/number do you see today?" and check the answer. They should also tell explicitly, that only blue/no number (i.e. non-EV) implies a severe security problem, somebody might be trying to steal your money right now.

Of course 3 choices don't add security as such, but they raise the awareness that banks or whoever cares about EV are a different story. If somebody continues to try all 3 number/colors we are at least no longer talking of an understandable social problem, then it's a severe intellectual problem.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 16:27 UTC (Sun) by Kit (guest, #55925) [Link] (5 responses)

That wouldn't solve the problem of a MITM attack- you're forgetting that the page you're getting is from the _attacker_! If the attacker can get a valid certificate, they can just rewrite the page to make it say that /their/ certificate is valid... after all, the certificate is what is supposed to "prove" the authenticity of the page.

The "social problem" isn't going to be solved by implementing more convoluted systems that the user is simply annoyed/nagged by- any time the user is nagged by security you end up in the ActiveX situation: everyone will just be trained to hit 'yes'/'accept' and totally ignore the text, or the context.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 17:58 UTC (Sun) by jthill (subscriber, #56558) [Link]

I wish people would distinguish certificates from keys. A CA signing a key doesn't make the key valid. Trusting a CA is tantamount to surrendering to a MITM attack in advance -- in every real sense, a CA _is_ a MITM.

If your partner's system and your system are uncompromised (i.e. the attacker is still "in the middle"), a valid key makes the connection absolutely secure. Google's effort is an attempt to make it easier to be ~mostly sure~ a key is valid, and I think it's a good one, but I also think that the real problem is going to be getting people to verify keyprints at all -- the entire CA-infrastructure tribe eats by keeping people ignorant and verification inconvenient, so you can expect any effort like Google's to be met with a FUD storm.

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 18:01 UTC (Sun) by geuder (subscriber, #62854) [Link] (3 responses)

> If the attacker can get a valid certificate

Yes, the attacker can get a valid certificate, but not a valid EV certificate. That has been the assumption for a couple of comments in this thread. With just a valid non-EV certificate the browser would not display the extra color/number info suggested

> everyone will just be trained to hit 'yes'/'accept'

That's why I suggested 3 options, and a different one is "correct" every day (one could also change the algorithm such that a different one is correct completely randomly from human perspective)

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 9:26 UTC (Wed) by jamesh (guest, #1159) [Link] (2 responses)

It shouldn't have been possible to for the attacker to create Domain Validated certificates, but they managed to due to policy problems (possibly due to them outsourcing the validation to a reseller?).

For EV certificates, we're being told that they are more secure because the CAs would never take similar shortcuts when validating these new certificates.

The existing track record of CAs doesn't inspire confidence that we'll never see a bogus EV certificate.

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 15:41 UTC (Wed) by martinfick (subscriber, #4455) [Link]

No, really, I mean it, you can trust this certificate (it is an EV). Well, what about that other one you issued that isn't an EV? Oh, you can trust that one too, we issued it. So, then why would I get an EV one? Because you can really trust an EV one. So I can't trust the non EV one? Well, no, of course, you can. ....[repeat]

Laurie: Improving SSL certificate security

Posted Apr 6, 2011 17:55 UTC (Wed) by dlang (guest, #313) [Link]

it doesn't really matter, when the EV certs get down to the level of normal certs, they will invent 'new, really secure, we really mean it this time' certs and jack up the price on them even more. and a few years later they will do it again.

Laurie: Improving SSL certificate security

Posted Apr 4, 2011 6:51 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

And the colorblind can no longer bank online..

Although with the current system, it's hard to bank online securely (but at least it's possible to do it..).

It's really too bad that red means danger/stop/etc and green means safe/go/etc in so many contexts - and yet they look the same to so many people..

Take care,
-stu