On Thu, Jul 31, 2003 at 08:21:05PM -0400, Steven M. Bellovin wrote:
> In message <20030729145326.GB25682@rek.tjls.com>, Thor Lancelot Simon writes:
> >On Tue, Jul 29, 2003 at 08:09:55AM -0400, Steven M. Bellovin wrote:
> >> In message <20030729061636.GA29270@rek.tjls.com>, Thor Lancelot Simon writes
> >> >
> >> >This raises an important issue (which, amusingly, most Linux
> >> >distributions seem to botch): if we're going to ship binaries
> >> >with the system that support SSL or other certificate-authenticated
> >> >protocols, we need to try to do some kind of certificate validation,
> >> >and we need to ship a reasonable default bundle of trusted root
> >> >certificate authorities.
> >> 
> >> I think that this is a very dangerous path to go down.  It means that 
> >> NetBSD sites will trust these roots, whether they know it or not.  Do 
> >> we really want to be in that business?  (With one exception, of course: 
> >> a NetBSD CA for NetBSD-related certificates, such as those used for 
> >> distributing patches and the like.)
> >
> >Well, it's an interesting question, but the thing to bear in mind is
> >that without a bundle to validate against, most commonplace Unix
> >speakers of SSL (e.g. stunnel, lynx) do *no* certificate validation.
> >Whatever you think of Mozilla's root CA policies (I don't think they
> >are as bad now as it sounds like they once were) trusting the same
> >people as just about everyone else on the Net can't be as bad as
> >trusting everyone, everywhere.
> 
> Trust for what?  What privileges am I supposed to grant to someone who 
> has a NetBSD-signed certificate that I wouldn't grant to any random 
> person on the net?  Remote login?  Obviously not.  Email?  I don't send 
> a lot of sensitive email that's best protected by SMTP/TLS, as opposed 
> to PGP.  The only answer I can think of is distributions -- but that 
> applies to https contact to the NetBSD web servers.  Beside, what I 
> want there is a signature on the distribution itself, not on the 
> transmission.
> 
> In short, I don't see what problem is being solved.

The issue is one of user expectations.  Naive users expect that when they
connect with SSL to a service, that connection has (at least) two 
properties:

1) They have a reasonable assurance that the identity of the other party
   is what they believe it to be.

2) The connection is secure from prying eyes, even if those eyes choose
   to run active attacks against the SSL session, e.g. MITM.

The problem is that much open-source software that uses SSL does not
provide these properties because it does *no certificate validation at
all*.  Obviously, without some trusted CA to validate against, you can't
do any -- which, I'm contending, is an even worse situation to leave the
naive user in than the one in which he trusts whoever you decided it
might be reasonable for him to trust by default (IOW, uses the browser/OS
default certificate bundle).

Sophisticated users can look out for themselves -- they already had to,
with no bundle provided and no validation going on, after all -- but it's
Joe User who blithely tries to use pkgsrc lynx to do his online banking
I'm worried about, here; the current state of the system leaves him all too
open to attack.

Thor