Subject: Re: SSL support in system binaries
To: None <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 07/29/2003 08:09:55
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
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.)
Netscape had an interesting trust metric: they'd list anyone as a root
CA if they paid Netscape enough money... To quote Matt Blaze, a
typical CA will protect you against anyone from whom they won't take
>A coworker of mine at ReefEdge wrote some nice tools to turn the
>CA bundle from the Mozilla CVS repository into a format that
>OpenSSL can handle, and I have some nice sample code that does
>certificate validation (including correctly handling chains,
>which most OpenSSL applications seem to get wrong) with OpenSSL.
>I suppose I should probably try to get this stuff into the tree
>soonish, if we anticipate adding SSL to more pieces of the system. :-)
That's a good idea. The OpenSSL tools are pretty ghastly; anything
that makes certificates easier to use is a good idea. And code to
validate certificate chains would be an excellent idea, though I
thought that the SSL protocol itself didn't support that.
--Steve Bellovin, http://www.research.att.com/~smb