httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Bowen <>
Subject Re: [users@httpd] Content Negotiation with <DirectoryMatch> in Apache 2.0.43
Date Sat, 28 Dec 2002 14:24:27 GMT
On Sat, 28 Dec 2002, imacat wrote:

>     Putting the public key on the website implies putting the source of
> trust to the DNS system.  This is the same as putting the public key on
> the FTP site, or spreading the public key using some auto-reply mail
> machanism.  The current DNS system is not quiet trustworthy.  Putting
> the public key on the public keyserver is even worse.  Public keyservers
> are polluted with plenty of fake keys.  Putting the public key inside
> the distribution file is worst, needless to say.  These are all the
> key-spreading methods I had ever seen till now.  Each has a different
> degree of danger.
>     But, what if we combine all these methods together?  If these
> methods' seperated trust levels are: 25%, 25%, 25%, 15%, 8%, will they
> have a combination of 98%?  This is based on the assumption that "one
> attacker cannot break everything at a time".  This is a reasonable
> assumption, and is the current practice of many security modules.
> Unless the user is completely isolated to the outside world by the
> attacker, with a dedicated system to fake the network responses, she/he
> must have some way to find a correct key.  Also, the administrators can
> easily be notified if any of these sources is corrupted.  Fix can be
> quickly applied.
>     If we put the Apache software distribution public key at all the
> possible ways, on the main website, child websites, FTP, mail server,
> public key servers, etc., we'll get a distributed source of trust.  This
> is something like Phil's web of trust.  Every part of it is marginally
> trusted, but their trusted value can be joined into one.

Well, we have that. It is on the key server, the web site, the ftp
server, in the cvs server, and on several dozen mirror servers. We don't
have it in the distribution, but that seems a little silly to me. And
all the keys in the KEYS file are on the key servers, which are,
themselves, a distributed system. And, since attackers never know for
sure which member is going to do the next release, there are 70+ keys
that have to be compromised, not just one.

> > We've talked about this - having a single key with which we sign stuff -
> > but I'm not clear how this is any better. It is a single untrusted key,
> > rather than multiple, but it is still untrusted, right?
>     Well, at least it has one benefit:  When I see a Apache distribution
> tarball signed by:
> imacat@rinse /arc/src % gpg httpd-2.0.43.tar.gz.asc
> gpg: Signature made Thu Oct  3 14:01:01 2002 CST using RSA key ID 10FDE075
> gpg: Good signature from ""
> gpg:                 aka "William A. Rowe, Jr. <>"
> gpg:                 aka ""
> gpg:                 aka ""
> imacat@rinse ~ %
>     It's always hard for me to recall who this "William A. Rowe, Jr." is
> and why I signed his key. :p  But if it's something like:
> imacat@rinse /arc/src % gpg iptables-1.2.7a.tar.bz2.sig
> gpg: Signature made Mon Aug 26 22:37:07 2002 CST using DSA key ID CA9A8D5B
> gpg: Good signature from "Netfilter Core Team <>"
> imacat@rinse /arc/src %
>     Yeah, I remember this key and why I signed it.
> > I'll make some inquiries, and see how people have solved this problem,
> > or what the "right" way to do things is, and either get back to you
> > directly, or post something to the mailing list,
> > if I exercise my usual carelessness and lose your email message. ;-)

The responses that I have received so far recommend that you 'lsign'
rather than 'sign' the message. That is a local, non-exportable
signature, so you get all the benefits you listed above, but the
signature does not go out to the public servers.

Pilgrim, how you journey on the road you chose
To find out where the winds die and where the stories go
 --Pilgrim (Enya - A Day Without Rain)

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message