On Jan 28, 2004, at 10:40 AM, Douglas Koobs wrote:
> I have finally installed a self-signed SSL certificate on my mail
> server
> at home, and it works great for webmail (using Squirrelmail). However,
> I
> have 2 questions:
>
> What are the security concerns with using a self signed certificate
> instead of one signed by Thawte or Verisign? I'm assuming that since
> the
> only people that use this server are my family and friends, and they
> all
> trust me, that there is no need for an expensive signature.
I sha'nt go into my full rant, since I don't have time and I don't want
to fill anyone's mailbox.
(Insert Nicholson-esque "Heeeeere's Johnny!" mental image as I whip out
the metaphorical axe....)
SSL certs have two basic purposes: Security and Identification.
Verisign has one basic purpose: screw the internet-using public as
badly as they can manage without being caught performing outright
criminal behaviour. (Note the "being caught" clause...)
The x509 cert format includes space for identifying details of the
person to whom the cert is assigned, including a set of public/private
key(s) with which encryption can be performed and SSL certs are just
x509 certs. In the specific case of SSL, the public/private keys are
used to encrypt the one-time keys generated at session setup, so each
SSL session has its own dynamically generated set of keys that are
exchanged using the keys in the cert. So the keys contained in the
cert are only used once when the SSL session is first established.
(One place) where Verisign is, and has been, screwing the public is in
the implication that a "signed" cert is not valid for encryption. THIS
IS FALSE. A self-signed cert does just as much good at encryption as
one you paid $99 or $999 to get signed. (I love how they also push
their "SuperCert" which supposedly gives you "extra" encryption or
something. Completely glossing over the fact that, as I mentioned, the
keys in the cert are only used to encrypt the session keys used to
really encrypt the vast majority of the data.) Whether a cert is
"signed" or not has no effect on whether or not the contents of that
cert include keys that can be used to establish an SSL session.
The only time you need a "signed" cert is for identification purposes.
when you pay them for the privilege, Verisign verifies that the data
you have included in your cert is truly identifying data for the person
who is asking that cert to be signed. (Although lately I have seen
absolutely no evidence that they're doing more than a cursory attempt
at this anymore.) The signature really only says, "We verify the
identifying information on this cert is correct." That doesn't mean
that it is, only that some third-party is saying it is, to the extent
that they received enough money to be willing to put their signature on
it. (And we all know what you call someone who will do anything for
money...)
Where the current SSL design _as a whole_ is screwing the public on the
Idnetification/Indemnification aspect is in having a limited, known set
of Cert Authorities that are considered "authoritative" and if the
signing cert for one of those CAs is not in your browser, the browser
simply "doesn't trust" the information on the cert. For 99% of cases,
nobody cares, since your main concern is whether the data is encrypted,
not whether or not the person on the other end is who they say they
are, either because the transaction just isn't that important or you
have already verified through other means that the party is who they
are claiming to be. Regardless of whether or not it matters in a given
situation, people get worried when they see the warning pop up about an
unknown cert, which undermines the effectiveness of SSL.
The way the SSL system should have worked is like the PGP "web of
trust" mechanism. When you contact an SSL website, it would do the
cert exchange thing, then look up their key in some public database and
get a "trust rating" based on feedback from users as to whether or not
that cert is accurate, based on the same web-of-trust mechanism you
find in PGP or GnuPG. Your browser would have a little button that
would say, "I think this site is who they say they are" which would
effectively put your signature on their cert, just as in PGP.
For a site like Amazon, they could easily get enough people to certify
they are who they say they are that it would be a non-issue. Smaller
sites would have more trouble developing a large web-of-trust, but at
the same time the problem could be more easily circumvented because it
would be more likely that the parties visiting the site could certify
directly with the site's owner and the ratio of the sizes of
web-of-trust to users would be larger. Plus, nobody has to pay for
anything to make it work, which of course is why it doesn't work this
way.
The reason the SSL system works this way is because long, long ago,
when Netscape designed the SSL spec and decided how it "should" work,
they thought that _they_ would be the end-all-be-all CA that would
appear in every browser and every user and company would need to come
to Netscape to do encrypted web traffic. For whatever reason, they
decided to allow third-parties and Verisign muscled right in and
screwed them right out of their screw-job, only going to show that when
a company tries to develop a "standard" designed to screw the end-user
and they get screwed too, the pain of the screw-job really doesn't even
come close to offsetting the pleasure of seeing it happen.
And yes, that's the short version of the rant.
(Derek takes off the white smock, wipes the axe head, thinks "I need to
get this sharpened"...)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"We all enter this world in the | Support Electronic Freedom
same way: naked; screaming; soaked | http://www.eff.org/
in blood. But if you live your | http://www.anti-dmca.org/
life right, that kind of thing |---------------------------
doesn't have to stop there." -- Dana Gould
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:32:58 EDT