[H-GEN] https + apache

[Russell Stuart]

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

"Christopher Biggs" <listjunkie at pobox.com> said:
> > 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.

Yes or no.  Depending on how you got hold on my self-signed cert.
If you received a document signed by a self-signed cert you can be
almost certain that it came from the owner of the cert.  The only
limits to that certainly is your faith in the ciphers used and how well
you trust the owner to keep his private keys private.  Whether you
trust the identity of the author of a document has nothing to do with
whether the cert he used to sign that document was self-signed or
not.  As a case in point, PGP keys are effectively self signed certs.
People on this list sign documents with them all the time.

But that, I am sure, was not your point.  So your point must be that
into order to trust that a cert is really owned by who it says owns it,
it must be signed by somebody else.  In other words you can not
trust the ownership of a cert if it is self signed.  So consider two
scenarios.

Scenario 1: I trust your pgp key because it is signed by third parties.
Scenario 2: I trust your pgp key (which remember is a self-signed
cert) because you personally gave it to me at a key signing party.
Out of those two scenarios which key do I trust more?  The
unsigned (ie self-signed) one, oddly enough.

OK, so I am putting words in your mouth, and that was not your
point either.  You were just trying to point out to an apparent newbie
that the "approved way" of building trust in X509 certs is to have
them signed via the PKI hierarchy.  And a good point it is too.  One
reason you are getting this long rant in reply is that the PKI hierarchy
is a poor, over engineered, solution for building up trust in a cert.
Most people, when given a choice, don't use it, and that happened
before VeriSign managed to issue a cert to some smuck in
Microsoft's name.  Cases in point are the ATO, who issue their
own certs for doing tax returns, and of course everyone on this
list, who seem to use pgp/gpg keys.

But the major reason for this long rant is that your reply perpetuates
the myth that self-signed certs are somehow inherently bad.  That
myth is the foundation the business of VeriSign and others are built
on.  I am sure they would applaud your doing it.

The only reason VeriSign and others survive is because of the
behaviour of current browsers.  As far as I can tell, that behaviour
could best be described as one big bug.  Whereas the embedding
of an cert into the SSL protocol could be used to enhance the
security of the internet, it in fact as far as I can tell it manages to do
the reverse: it manages to reduce security.  More on this below.

> 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 problem is not that the certs certificates embedded in SSL can't
help security.  They could, if the browsers did something useful with
them.

Consider this scenario.  Mr A.Criminal goes to a cert provider, and
provides he details, birth certificate, dna sample, or whatever else is
required, and gets his SSL cert.  Perhaps the cert is for
www.smallbank.bnk.com.  He makes www.smallbank.bnk.com
looks exactly like www.smallbank.com site, and starts attracting
www.smallbank.com's customers and ripping them off.

Perhaps Mr A.Criminal's site did not use SSL on his site.
But there is no reason he couldn't.  He has, after all paid freessl
USD$35 for a cert proving he is Mr A.Criminal.  He is safe in
the knowledge that the browser will never display this cert to
the user.  So, how much warning did the browser give to the
poor user that he was at the wrong site?  Answer: The only
way he could know is by looking at the URL.  How is this
different to not having the cert  embedded into SSL at all?
Answer: it is not different.  So what additional security did
embedding the cert in SSL give?  OK, there is a small
benefit.  Unless the Mr A.Criminal is able to get a signed
cert for www.smallbank.com, he can't do a DNS hijack
and use SSL.  He can still do an DNS hijack and not use
SSL.  That way the user won't get a warning.  With any luck
the user will not notice the change of "https" to "http" and the
absence of a little lock icon in the status bar of the browser.
The odds would be very good, I think.

I am no crypto expert, but it is not hard to come up that does
actually enhance security.  Imagine that when you first contact
a SSL site your browser unconditionally displays the cert.  On
the cert are people / organisations that vouch for it.  A major
bank, the ASX, perhaps a few of the merchants suppliers.
Each has a link, so you can check it out.  If you accept the
certificate the browser stores a cookie like object so it
remembers, forever more, that this site must be accessed
using SSL and it must present this cert.  This fixes a few
things:
  1.  DNS hijack of the site, whether the attacker uses SSL or
      not, will cause a warning from the browser.
  2.  The browser will issue a warning if the attacker uses SSL
      on a different domain name.

There is no need for a PKI hierarchy here, no need for
VeriSign.  All that is required is a PGP like network of trust.

> >     This raises a number of issues.  How to I create a root cert (is
> >     there a HOWTO somewhere?)
>
> Did you read the OpenSSL documentation?

No.  Lazy :).  Well that and I find the openssl command line a tad
overpowering.  I did find a HOWTO however, so I managed to
create a self-signed cert, signed a few subsidiary certs, and even
created smime encrypted emails with them that can be read in
Outlook.  It was all heavy going though.

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

Thanks.  I figure this all out in the end.

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

Well, I half agree here.   In trying to create a secure site I discovered
that, as you say, there is a "get-rich-quick parasite scheme that sucks
every cent out".  That discovery prompted the original email.  I was in
a state of denial as I wrote it.  Something along the lines of "someone
please tell me this is not right - show me the way out" sort of thing.

The bit I disagree with it that the current system ensures, that as you
say "everyone can safely trust the identity of remote parties".  It does
not do that.  US companies have somehow managed to socially
engineer a system that does not provide any additional security, but
does require us to pay them money.  A truly awe-inspiring feat.

Even more amazingly, its is the browsers that control this situation.
You can understand how commercial browsers might be party to this.
But Mozilla, Konq - why in gods name to they continue to play the
game?  If anybody was in a situation to break this silly system,
surely it is then open source movement.


--
* 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/