[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 <russell at stuart.id.au> moved upon the face of the 'Net and spake thusly:

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

Well, a self signed certificate received across an insecure channel
from someone with whom you have no trust relationship tells you
nothing.  A certificate signed by someone whom *you* trust allows you
to make a trust decision.

>  As a case in point, PGP keys are effectively self signed certs.

Yes, and a PGP public key that was not
     a) signed by someone you trust, or
     b) received over a secure channel (eg. in person), or
     c) verified (fingeprint check) over a secure channel

should be afforded no trust.   This is exactly why the PGP 
"Web of trust" exists, to allow you to make trust decisions about
certificates received over insecure channels.

The PGP web of trust and the SSL hierarchical PKI are both doing the
same thing.  The difference is that the commercial system has fixed
trust anchors at the top of the hierarchy (you must trust verisign),
whereas the PGP system allows YOU the end user to assign trust values
to each signator, and manage the degree of transitivity-of-trust you
are willing to accept (e.g. If I trust my brother Bob, and he trusts
his neighbour Charlie, I can configure PGP to work out how much *I*
trust Charlie.)

If we could all meet in person to exchange keys, none of this
rigmarole would be neccessary.

> People on this list sign documents with them all the time.
>

And without keysigning "parties" or some other verification of key
authenticity, such signatures cannot be trusted.   

(another form of verification I once used was to have my key
fingerprint on my business card.  That way somebody posing as me not
only has to create a forged certificate, but to print forged business
cards).

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

This is true.

>
> Scenario 1: I trust your pgp key because it is signed by third
> parties.

This is true.

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

This is true.

> Out of those two scenarios which key do I trust more?  
> The
> unsigned (ie self-signed) one, oddly enough.

WHICH YOU RECEIVED OVER A "SECURE CHANNEL".

With SSL we are talking about certificates received over INSECURE
CHANNELS.

PKI does not aim to address communication security, those problems
have been solved by secret key methods for over half a century.

The big win that PKI brings is that it simplifies KEY DISTRIBUTION.

Public-key infrastructures such as SSL and PGP mean that you don't
*have* to exchange briefcases in the park, or send locked boxes by
courier, or resort to other out-of-band key distribution pain, instead
you make just *one* secure communication (you get your certificate
signed by the CA, who verifies your identitity), then all other key
distributions may take place over insecure channels (i.e. the Internet).

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

Yup, totally agree.

But if you want play the WWW commerce game, you've got to work within
their little money-pit PKI.

BTW, The ATO uses out-of-band verification---to obtain your
certificate, you have to know the reference number from your last tax
assessment statement.   

> But the major reason for this long rant is that your reply perpetuates
> the myth that self-signed certs are somehow inherently bad.  

Not bad, just not solving the whole problem.

> That
> myth is the foundation the business of VeriSign and others are built
> on.  I am sure they would applaud your doing it.

<this paragraph deleted to retain PG rating>

> The only reason VeriSign and others survive is because of the
> behaviour of current browsers.  

The problems with the current WWW PKI are:

    1.  The trust anchors are fixed: whatever keys are in your web
        browser binary.

    2.  You have no power to assign your own trust levels on the root
        keys.

    3.  The CAs are greedy bastards.

    4.  The "verification" processes use by some CAs are pathetic.


However, in regard to point one, come up with a better way to securely
distribute root keys, and the world will beat a path to your door.
The catch is: your grandmother must be able to do it.

> 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

I don't understand what you mean by "embedding...protocol".

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

That's what I meant by points 2 and 4 above.  

Lousy verification is a bug in CA's security policy, not in the
overall PKI.

> 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?
[....]

Face it, security is hard, and people are dumb.  

Contrast this with St George bank, whose site user agreement requires
that you telephone them and verify their certificate fingerprint
before using the site.  

I bet almost nobody actually does that.   I did.

I'm sure you won't find too many computer experts who disagree that
browsers suck.  However, they are probably as complicated as they can
get and still be usable by Joe Sixpack.   Maybe in a generation
things will improve.  Nah.   

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

Browsers used to show you all this stuff more agressively, back in the
Elder Days.   Now they don't. 

People Don't Want To Know.

What people want to know is that when they see a little padlock icon
they can buy their "Gruntmaster 9000 automatic fat blaster" from
Demtel using their credit card and have it arrive in the mail by
Tuesday.

Asking them a bunch of questions they don't understand will only
frighten and confuse them.  Now I am not condoning sweeping security
under the rug, or refusing to try to do the right thing, I am simply
stating that we're always going to be stuck with a tradeoff between
security and ease-of-use.

It's a social issue, not a technical one.  Merchants, CAs and software
publishers want to make the internet look "safe" to a population who
simply cannot understand the immense technical and social problems
involved in doing that.

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

You, like me, probably have a circle of friends and family who are all
tertiary educated.   Do you think your plumber's wife is going to
understand any of that when she wants to buy her "Ab Swing" off Bert
Newton's show?

She's gonna go, "Oooh, scary", and shop at K-mart instead.

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

I happen to think that a hierarchical PKI could work if it was run
more like a public utility than its current state which is more like
"mafia protection racket".

But the SSL PKI is what we're stuck with for the moment.

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

Yeah, well, it did only take me about six months of devouring code and
documentation to understand this stuff.

It's HARD.  Real hard.   It's amazing that achieving "secure"
authenticated communication between two parties who have never met is
even possible at all. 

If you can't make the effort to learn enough to do it, then pay
someone else.   There is no free lunch.

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

It is technically capable of doing so.

Alas, the human side of the equation (the strictness of verification),
has become dangerously lax.

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

You assume that somebody knows what a better way (that meets the
criteria of usability by the unsophisticated) _is_...

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