More on Certificates and Trust Decisions

More on Certificates and Trust Decisions

  • Comments 9

I said earlier that certificates could be used to establish identity and hence the right to run trustworthy software on your machine.  I want to emphasize in the strongest possible terms that this is not all that certificates are used for.  A lot of people are confused by this, including a lot of very smart, technically savvy developers.  Cryptographic security is complex and poorly understood.


Let me give you an example.  One time I went to a friend's web site.  My friend is a sharp and highly experienced developer.  His web site happens to use HTTPS, the "secure protocol", and I was very surprised when I got an error message from IE saying that the certificate associated with the site could not be trusted because it was self-signed.  In other words, the certificate says "The bearer's name is Sven Svenson.  The bearer's identity has been confirmed by Sven Svenson."


Obviously that is not any kind of identity-establishing evidence!  To trust the cert you have to trust the certifying authority, but the certifying authority is the person whose identity is in question!  This chain of trust is not rooted in an explicitly trusted authority, so it is worthless.  What is stopping, say, Bjorn Bjornson from typing up the same certificate?  Nothing!


I asked my buddy why he didn't use a Verisign certificate and his answer surprised me:  "Nobody's told me that they won't use the service unless I got a Verisign cert. And if they did, I'd probably tell them that they shouldn't use my system if they don't trust me ;) "


My friend was confusing code signing with secure HTTP.  HTTPS does not use certs to establish a trust relationship between the client and the server by establishing the identity of the code author!  HTTPS uses certs to establish secure communication over an insecure network by establishing identity of the web site.  Those sure sound similar but they are in fact completely different uses of certs.  Why?  Because in the first case, it is the code author who is (potentially) untrusted.  In the second case, it is the insecure network that is (definitely) untrusted.


Before I continue let me briefly explain what the goal of HTTPS is, and how it works.


The goal of HTTPS is to ensure that when you send information over the internet, two things happen.  First, the information is encrypted so that if it is intercepted, the eavesdropper cannot read it.  Second, the server that you're talking to really is the server that you THINK you're talking to. 


We have these two goals because there are two threats: first, someone might be listening in on the traffic between the client and the server, so you need to ensure that they can't make sense of what they overhear.  Second, someone may have set up a "fake" server that fools your client into believing that it is talking to the "real" server, so you need to ensure that you are talking to the "real" server.


When you go to a secure web site -- like your bank, or Amazon or some other web site involving transmission of credit card numbers over the internet -- the first thing the web site does is send you a certificate containing the name of the web site.  The certificate has been signed by a trusted root -- Verisign, for example.  Your browser can then compare the certificate's web site name with the web site you actually went to, and because it is vouched for by Verisign, you know that you really are talking to the right server.  The certificate also contains information about how to encrypt messages so that only the server can decrypt them.  That is then enough information to mitigate both threats and establish a secure channel.  (The details of how that channel is established are not particularly germane; I may discuss this in a future post.)


I'll say it again: the certificate is NOT there to establish a trust relationship between the client and the server.  The certificate is there so that you know that you are talking to the real server, and no one can eavesdrop. This is the internet we're talking about: for all you know, evil geniuses have cut every line between you and the entire internet and have inserted their own evil routers and servers that look just like the real internet.  (For all you know, this is someone else's blog!) It's Verisign's job to ensure that those evil geniuses never get their hands on an certificate vouched for by Verisign, because that is the only evidence you have that you are actually talking to the real internet.


So when you go to a web site with a self-signed HTTPS certificate, IE pops up an "abort or continue?" dialog box.  What that box is trying to communicate is:


"Hey, buddy, you are trying to communicate securely with FooCorp's web server but because the certificate does not establish a chain of trust, IE is unable to determine if the insecure internet between you and FooCorp has been taken over by evil genius hackers who are presently spoofing you into believing that you are on the real internet.  Do you want to go ahead and possibly be spoofed, or stop right now?"


Unfortunately, the dialog box is not particularly clear on this point, and besides, everyone clicks "OK" without reading dialog boxes.  But that's another story.


To sum up: whether you trust FooCorp or not is not the issue -- if you're going to send them your credit card number, presumably you already trust them!  What you don't trust is the wiring between you and them.  There might be hackers at their ISP, or your ISP, or at any node on the network.  There might be people listening with packet sniffers and packet replacers. There might be people listening to your wireless network traffic.  HTTPS is designed to protect users against untrustworthy, insecure or hostile network providers by ensuring identity and encrypting traffic.


  • Related to the IE "abort or continue?" dialog boxes and users being given the power to make ad hoc trust decisions, do you have any thoughts as to what would be a better alternative? Also hope you'll write on to how the secure channel is established sometime in the future. btw, thanks very much for blogging and the amazing content. I really like your writing style and your most excellent “Visual Basic .NET Code Security Handbook”.
  • Regarding the buddy specific case - self-signed certs are not a bad thing be definition. In fact, any cert serving as a root had better be self-signed. The question then becomes how that self-signed cert is passed to the client. As long as it's sent via some other secure, out-of-band channel, then it's a perfectly valid model. I used to do this with clients coming in to look at code I was writing for them all the time. Hand them a floppy with my self-signed root cert on it and then they can peruse various https url's later and be just as confident as if Verisign had signed them. This is obviously tangential to the well made point of another great blog entry. Thanks Eric.
  • When someone asks me why I use my own certificates, I tell them it's the cost. I mean, does it really cost Verisign $1,000US to maintain their side? Does each certificate reside in their own server? If I was developing a site that made millions of dollars, maybe a grand wouldn't be a bad investment. But for me, a single person development shop, it's a bit prohibitive.
  • There's two additional reasons why one might not use a certificate from a "trusted root": 1. One doesn't trust the "trusted root" (e.g. Verisign, which recently broke DNS for .com, .org, and .net). 2. E-commerce notwithstanding, in a great many online interactions, I couldn't care less who a person might be in real life; all I want to know is that I'm talking to the same person each time. A self-signed certificate does this as well as a certificate signed by Verisign. If I regularly visit Bob's website on cats, I want to know that I'm still looking at Bob's website. I don't care that Bob is actually John Smith, janitor, in Albany.
  • I assume that VeriSign spends part of its $1000 on verifying that you are who you say you are and have the right to ask for the certificate you're requesting. No, I don't think it should cost that much either. I seem to recall that VeriSign handed out a code-signing certificate to someone claiming to be from MS but who actually wasn't, and MS had to issue a patch with an explicit certificate revocation to get round it.
  • Dear Mr.Blake, what about that "...self-signed certs are not a bad thing be definition. In Any cert serving as a root had better be self-signed..."
    I don't think you realyy got the pointDear Mr.Blake, what about that "...self-signed certs are not a bad thing by definition. In Any cert

    serving as a root had better be self-signed..."?
    I don't think you really got the true point, which is in fact 'authentication'.
    Just let me give you a common life example. Suppose you are a bank clerk, having to check that

    someone, trying to withdraw some cash from Mr. John Wise' s account, is actually the same Mr.Johnny

    Safe who opened that account (doesn't really matter if his true name is, say, Bob Stealthy, he'd

    not stealing someone else's money anyway).
    If direct, visual identification is impossible, because you just saw Mr. John Wise once in a

    lifetime, you would certainly ask for an identity certification, and one you can trust, for example

    his passport, not certainly a visit card (which can be easily faked).
    In other words, reliable identification is also the best guarantee against identity spoofing, which

    is dangerous per se, even under circumstances where true identity is unimportant or irrelevant.
    Anyone with the right knowledge can produce a self-signed certificate which can exactly mimic your

    own and pretend to be you. I would state that even Verisign should sign itself using a certificate

    issued from another independent certification authority, otherwise there would be no true means to

    verify who is who.
  • That makes no sense.  Think it through.  Suppose Verisign gets their root certificate signed by Fooisign.  Great.  _Who signed Fooisign's certificate???_

    The chain has to terminate in a trusted root, and that trusted root has to be self-signed.  Therefore some additional trust mechanism must be in place, because obviously a self-signed certificate itself is no evidence of anything.  That's why there's the trusted root store.  Any cert in the trusted root store is by definition fully trusted irrespective of how it was signed.

  • You are perfectly right!

    Of course, circular referencing among certificates is not the magic recipe against fake certificates.

    But why not allow cross-referencing between certificates issued from two independent and trusted certification authorities, so that one can counter-sign the certificates of the other?

    This might certainly provide additional security, just in case one certificate becomes compromised (or anyone simply suspects to be so).

    Unfortunately, web browsers not always (are configured to) check for revoked certificates, or that check may occasionally fail (it occurred to myself at least a couple of times, I don't remember when and where), in which case you have two options: either ignore the warning and take the risk or just give up.

    But the real problem, as pointed out by Mr. Blake and Martin, is that small businesses and organizations usually cannot afford the cost of certificates issued from officially trusted authorities, so they have to resort to their own (obviously self-signed).

    If they have some means to provide their counterparts (i.e. customers or associates) with a genuine copy of their certificate through some secure (and preferably off-line) channel, these certificates can be just as safe (if not safer) than official ones and perfectly entitled to be included into a trusted root store.

    Unfortunately, this is not the typical scenario in today's web panorama.

    I found university, non-profit and local administration sites using self-signed certificates, with no easy means for a visitor to actually authenticate them.

    I bet quite a number of these visitors may have decided to include these certificates in their trusted store, partly because of poor understanding of the trusted communication channel concept you so brilliantly outlined in this article and partly because they may have thought the game was worth the candle.

Page 1 of 1 (9 items)