[H-GEN] https + apache
Russell Stuart
russell at stuart.wattle.id.au
Mon Jul 21 01:11:06 EDT 2003
[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]
On Sun, 2003-07-20 at 19:14, Christopher Biggs wrote:
<snip>
> 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.
I agree with most of what you said in the snipped bit. It was just
hammering home some basic truths about certs, and todays CA's. Several
years ago I decided the current ISO PKI system (does it have a name?)
was a waste of time, so my ideas begin to diverge from yours at this
last paragraph. I have never had the opportunity to debate them before,
so I will do that below.
> > 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".
It is just a reference to the fact that SSL/TLS sends X509 certs as part
of the initial handshake. Thus a cert exchange is "embedded within it",
as it were. It is an optional part of the protocol (cf RFC 2246 section
7), meaning you can use SSL to setup a secure tunnel without sending any
x509 certs, but I suspect (meaning I have not checked the RFC's) that it
is not optional in HTTPS/POP3S/IMAPS.
> Browsers used to show you all this stuff more agressively, back in the
> Elder Days. Now they don't.
Did they? I didn't realise that.
> People Don't Want To Know.
Perhaps. The more cynical among us (and I would count you in that
group), would say Microsoft had a choice. They could:
1. Leave a little warning box that irritates their users, but
enhances their security.
2. Remove the security feature and "improve the user experience".
Now up until recently Microsoft always took option 1. Word processing
documents and spreadsheets that can be executable programs, Active X
controls that can be marked "safe for scripting", Browser Helper Objects
that make it easy to hi-jack URLs, executable email are some of the
crimes Microsoft have justified under the banner of "enhancing the user
experience". Perhaps this is another example.
It would be easy enough to fix, but that would require sacrificing that
revenue stream from the Root CA's. So far, they have not been able to
bring themselves to do it.
> 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.
Well, I am not sure I completely agree. Firstly the question does not
have to be that scary. When you enter a site for the first time, the
browser just has to display a message like the one below unconditionally
when entering a SSL site:
"You are entering site XXX. This site has been vouched for by:
BBBB bank [read-what-they-say-about-XXX]
YYYY Big name supplier [read-what-they-say-about-XXX]
ASX [read-what-they-say-about-XXX]
ASIC [read-what-they-say-about-XXX]
[OK] [Don't-prompt-me-about-XXX-again] [Cancel]"
Secondly Microsoft already does it. We all know about the big scary
message XP gives you when you try to install a device driver that
Microsoft has not signed. Apparently Microsoft does not think it is
going to scare off their customers, though. It is an interesting
contrast to their attitude on Browser warnings.
> 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.
I agree that low level crypto is not just hard, its bloody near
impossible. But that is not what is going on here. I am just deploying
an industry standard solution to a fairly common platform. This should
be drop dead easy, and I expect it is on many platforms. No one could
call running the "openssl" program drop dead easy, however.
> >> 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.
This is where I insert my little rant about the OSI PKI system (for want
of a better term).
Consider this scenario: I want to buy a PDA. I roam the net, and come
across some merchant and happy with the blurb on their web page make the
purchase through their SSL web site. Obviously I somehow built up
enough trust in merchant to give them money before I got the goods.
Where did I get the information to build up the trust? Well the one
place I did not get it from was the cert embedded within SSL - I did not
even get to see it. People less informed than I are in a worse position
- they did not know it exists.
This harks back to discussion we had about self signed certs earlier.
You said (quite correctly) that I can't trust a self-singed cert because
if I did not get it through a trusted channel. But this is irrelevant
because cert was never the source of my trust in the first place!
All of the OSI PKI system is irrelevant in a similar way. The PKI
system does a very good job of certifying that the cert that says it is
owned by such and such a Company who lives at xyz address and web page
www.acompany.com is really owned by that Company. But how relevant to
me is that? I possibly have never heard of Company XYZ at all, I
probably live in another state, possibly on the other side of the
world. The company could be owned by Mr A.Criminal, and all those
statements about the certs would be valid. Ergo the CA who signed the
cert has done their job. And done it as well as I could possibly hope
for, despite your comments earlier that the system would work only if
"the CA companies did better checking". I disagree, obviously - better
checking will not fix the system.
Now consider a different scenario. I go to a web site and am presented
with multiple certs like this:
Company XXX has banked with us for the last 20 years
-- cert signed by bank BBB
Company XXX has been reselling out palm pilots for 5 years
-- cert signed by Palm, US.
Company XXX lease this retail property at address AAA off
us for 8 years
-- cert signed by property owner OOOO
Company XXX has been a registered busness with $$$ turnover for
9 years
-- cert signed by the ASIC
These are statements that have meat, and more importantly are signed by
entities that I can trust to some extent to know what they are saying is
true! They are not unlike the "references" found on common commercial
documents today. Not unsurprisingly such references are not "bought and
sold" by some "reference broker". They come from people who can be
reasonably though of as independent third parties who are not paid for
their references by the people we are trying to trust!
Time for more examples. If I go to a hotel and stay the night do they
ask for a cert that gives my name and address, such as a drivers
license? On often. Do they swipe my credit card and thus get an
authorisation number that is effectively a cert from the bank that says
I am good for the money? You bet! If I want to send a secure email to
life and death email Christopher Biggs would I be happy with a X509 cert
with no other information other than a VeriSign key? No. But would I
be happy with a couple of PGP keys signed by people I know and trust at
humbug? Yes!
And that is what is wrong with PKI. It seeks to replace our "human web
of trust relationships" with some artificial hierarchal thing, with all
knowing gods at the top. I don't think it will ever work. PGP's web of
trust is in some ways a much closer fit.
Which brings me to my last complaint about OSI PKI. It has sucked all
the oxygen out - there doesn't seem to be any room left for other
solutions to grow. Sit two people at a table at your typical company
meeting and have one say: "I think we should implement some kind of web
of trust model", and another who says "I think we should implement the
OSI PKI model - we just get our VeriSign certs and go!" and see whose
argument wins. I think we would be far better off if the thing had not
been built in the first place. To dismantle it now we have to combat
the propaganda from the CA's who in their own way are every bit as bad
as the record companies when it comes to someone threating their
business.
Alright, its not my last complaint. Now that I have understood (finally
- after years of using the system) the shonk the SSL CA's have managed
to pull, it will take me weeks to get over it. The audacity of it just
amazes me! It is, without a doubt, one of the most awesome swindles I
have come across. And it was going on under my very nose without me
knowing. Bah!
--
* 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/
More information about the General
mailing list