Subject: Re: SSL support in system binaries
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 07/29/2003 10:53:26
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:
> >On Tue, Jul 29, 2003 at 02:30:02PM +0900, YAMAMOTO Shigeru wrote:
> >> Hi, all,
> >> I make a patch to support HTTPS for /usr/bin/ftp.
> >> It is quick hack.
> >> Please try and test it.
> >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.
OpenSSL can validate certificate chains; I don't know if the SSL
protocols all support transmission of chains but TLS definitely does.
You may recall a rather notorious Microsoft security hole involving
allowing people to certify from chained certificates where the
intermediate cert did not have the appropriate bits set in the