[H-GEN] https + apache

[Christopher Biggs]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Russell Stuart <rstuart at lubemobile.com.au> moved upon the face of the 'Net and spake thusly:

> 3.  For now I have created a self signed X509 cert that expires in
>     2038.  

I think you missed the point of using certificates there...

Self-signing a certificate prevents anyone from later modifying it,
but it proves nothing about your identity.

>   Way 1 would be to become issue my own root cert - ie
>     become a CA myself.  I could then sign as many certs as I liked
>     without having to pay for them.  This would be nice, as I have
>     a number of other servers (pop3s, imaps) on other hosts that should
>     be using "real" certs, not self signed ones.  

You missed the vital step that being a "root CA" means your public
signing key must be available using "secure out of band access".  The
real-world approximation to this abstract goal is that the root CA
keys are shipped embedded in the executable files of the web browser.

Micrsoft and Netscape will want about a million bucks to add your
certificate to their browsers.

You need to play the game and get your cert signed.  It costs, what,
seven bucks?

>     It bugs me no end to
>     have my user's pop3s client say _my_ pop3s server is unsafe.  

OK, let me explain where the certificate fits in to the secure
communications picture.

The SSL protocol always guarantees a secure channel with the other
party, thanks to Diffie-Hellman or other key exchange.

What a simple key-exchange /doesn't/ guarantee is knowledge of who the
other party *really* *is*.

Say somebody hacks DNS, or roots your box, or even reroutes your
network wiring to their box.   A self signed certificate will not 
protect you, or the client.

The only way the client can be *sure* that this has not happened is
if somebody who is "trusted" by the client "vouches" for your identity.

The purpose of having an identity certificate signed by a Certificate
Authority is to say that "Big Rich Company Foo says that <this public
key> is genuinely owned by FOOBARSOFT INC".    The unspoken assumption is
that the client trusts BRCF Inc to vouch for you.    Root CAs live or
die by their goodwill.

In order to vouch for you, the CA will expect you to verify your
identity using physical identity documents (drivers license, company
letter of authority etc.) or some other method, and of course don't
forget to bring the seven bucks.  Then you get a certificate that says
you are *really* you.

The expiry date on the certificate ensures that:

    1.  Keys are rotated regularly

    2.  The CA makes a shitload of money.


The browser considers self-signed certificates (or certificates signed
by an unknown CA) to be "unsafe" because

   1.  A connection-stealing or man-in-the-middle attack is possible

   2.  The Browser's authors make a shitload of money by charging the 
       CAs $BIGNUM to get their public key put in the browser binary.

Yes, you can manually load new root public keys into browser after
installation, but expecting Joe Sixpack to do this is unrealistic.
(Picture the "average man in the street"; by definition, HALF THE
PEOPLE IN THE WORLD are even dumber than him.  Scared yet?).

>     This raises a number of issues.  How to I create a root cert (is
>     there a HOWTO somewhere?)  

Did you read the OpenSSL documentation?

A root-cert is simply a self-signed certificate, (possibly
cross-signed by another root) that is stored by the browser.   It also
has an attribute that says it is allowed to sign other certificates.

>     How do I download the cert into the browser - is there a special
>     mime type?  

Yes.   Sorry, I forget the exact type.

For small communities of users, or internal corporate use, loading a
cert into each client browser is viable.

For public internet use, it's unrealistic to expect people to do that.

> 4.  The downside to "Way 1" is that the users Browser should bring up
>     lots of flashing red lights when they install the my shiny new root
>     cert.  You average J.Citizen would be deterred by that (I hope).
>     One way round that would be to get an existing root provider (such
>     as VeriSign) to sign my "root cert".  Do they do this sort of
>     thing - ie provide a cert which I can use to sign other certs? 

You're talking about becoming a (jeez, I forget the term, it's
"<some-word-other-than-certificate> authority", I think).  Yes, this
is possible.

You will need.
         1.  Certificate authority software and secure hardware
         
         2.  A means for positively identifying parties whose
             certificates you sign

         3.  A wheelbarrow in which to to carry the money that
             VeriSign will demand from you in order to enter
             a sub-CA arrangement.

It's not practical for a small organization.

The root CAs are in this business in order to get rich by charging you
$7 a year (or whatever the current figure is) for a simple but vital
job.   The browser manufacturers feed off them in a symbiotic
embrace.    

They are not going to make it easy for you to do without them.

> 5.  Way 3 is simple, and is probably what I have to do.  Its just that
>     it irks me a lot that I am forced to do it.  I have to pay VeriSign
>     or some similar company money every year each host / server I need
>     a cert for.

You're screwed.  Pay the money.

The state of the SSL PKI is this: A simple system for ensuring
everyone can safely trust the identity of remote parties has been
turned into a get-rich-quick parasite scheme that sucks every cent out
of the host (web site operators) that the host population will pay.

Welcome to capitalism.  It's the second worst system for running an
economy known to man.  Every other method tried so far is tied for
first worst.

--cjb


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/