More on Certificates and Trust Decisions


/>

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

 

Comments (9)

  1. Siew Moi Khor says:

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

  2. Blake says:

    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.

  3. MartinJ says:

    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.

  4. yipyip says:

    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.

  5. Mike Dimmick says:

    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.

  6. Valerio Galetta says:

    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.

  7. Eric Lippert says:

    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.

  8. Valerio Galetta says:

    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.

Skip to main content