SSL does not create trust

August 4, 2008

One of the stories that people tell about SSL on the web is that proper, valid SSL certificates create trust (and thus do all sorts of good things, like facilitating Internet commerce). This is, how shall I say it, not actually true.

Here's how SSL certificates fail to create trust:

  • simply having an SSL certificate doesn't mean you're especially trustworthy, because anyone can get an SSL certificate.

  • you might be able to trust an identity that's guaranteed by SSL, except SSL's idea of an identity is wrong for the Internet.

    (And even given that, certificate authorities have been fooled at least once for a high visibility case, and an unknown number of times for less visible people.)

  • SSL solves the wrong problem. As lots of events demonstrate, the vulnerable point is not the network or a sophisticated man in the middle attack; the vulnerable point, and the most valuable place to compromise, is the web server itself. And a web server having an SSL certificate says nothing about how secure it is.

    (The other valuable thing to compromise is the person sitting in front of the computer; hence phishing attacks.)

  • finally, and hugely, SSL creates no trust because it creates no legal basis for trust for anyone. There are no contracts with terms, no duty, no guarantees, no liability, no nothing. You pay some money and you get some magic bits, and that is it. No one is on the hook if something goes wrong.

Trust is created by people having a motivation to act in your interest. One of the ways that this can happen is that you pay them; another is that they pay you if something goes wrong (ie, liability). SSL involves neither, and as a result the presence of an SSL certificate means nothing more than that someone got an SSL certificate.

(Yes, trust can be created by reputation, but since anyone can get SSL certificates having a valid one says nothing about your reputation.)

Another way to look at this is to ask if there is anything that you can rely on, either practically or legally, if you see a proper SSL certificate. The answer is clearly no, for the reasons above; you have no legal reliance at all, you have no real assurance of who the website is, and you have no idea if the website is (still) secure even if they are a trustworthy business.

The conclusion is inescapable: in both practical and legal terms, SSL creates no trust at all. Any 'trust' it creates is both misplaced and entirely in the minds of users.

(It is hopefully obvious why misleading users about security issues is a very bad idea.)

(None of this is original to me, but I feel like writing it down in one place that I can point to. See here and the link in the comment here for some sources I learned from.)

Comments on this page:

From at 2008-08-05 09:06:52:

I don't think that SSL solves the wrong problem, I think that people just assume that it does. It's misused by people who see the lock, or the green bar, and think "I'm safe", rather than looking at the lock or green bar and then inspecting the certificate.

If I go to my bank site, and I see a certificate that is assigned to my bank, signed by Thawte, I've got a reasonable expectation that this isn't a phisher-redirected site.

On the other hand, if the bank's account access web site has been compromised by a (cr|h)acker, then honestly, there are other issues at hand, the severity of which outweigh my meager savings being pilfered...things that would probably involve FDIC action

Matt Simmons

From at 2008-08-05 18:35:09:

Inspecting the certificate doesn't provide or prove trust in the endpoint. Nor does it ensure safety.

First, PKI certificates and the information in them are not really humanly parseable. This is true even for experts in the field, who regularly "miss" such details as conflicting ns* extensions or the like. Worse, PKI certs are total gobbledigook to regular users, so examining them will add no safety for the general public.

Second, SSL/TLS only secures the long-haul communications channel. As Spaf puts it, SSL/TLS is the "equilvant of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench." The major threats are not on the long-haul communications channel. And they never have been.

PKI certs are free or nearly so. Even the "extended validation" restart of the whole "we'll show users scary dialog boxes unless you pay the CA who will then pay us" scam is tending towards negligible checking and lower costs. This is market pressure setting the value of securing the long-haul communications where it belongs. Couple this with the practical impossibility of "verifying" a cert by looking at it, especially for a regular user who won't spend the weeks necessary to understand PKI at that level, and you have the wrong problem being attacked.

Not solved, mind you, just attacked. A secured long-haul communications channel based on such a mass of quicksand can't say anything about trust in the endpoints.

Written on 04 August 2008.
« Our answer to the ZFS SAN failover problem
More on the funding capture problem »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 4 23:10:20 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.