Re: [nmap-svn] r23169 - nmap-exp/colin/updater

[Daniel Roethlisberger <daniel () roe ch>]

Fyodor <fyodor () insecure org> 2011-05-18:
> On Sun, May 15, 2011 at 05:19:48PM -0700, commit-mailer () insecure org wrote:
> > Added: nmap-exp/colin/updater/requirements.txt
> > ==============================================================================
> > --- (empty file)
> > +++ nmap-exp/colin/updater/requirements.txt Sun May 15 17:19:48 2011
> > @@ -0,0 +1,7 @@
> > +* It must be possible to verify the integrity of update metadata (e.g.,
> > +  latest version number).
> > +* It must be possible to verify the integrity of package contents.
> > +* The system must derive trust from GPG keys.
> > +  (In other words, if the system requires the generation of new
> > +   keypairs, it must be possible to sign those with existing GPG keys.)
>
> SSL may be OK too.  I think the current GPG-signing mechanism for Nmap
> downloads is more secure than if we just distributed them from an SSL
> site.  But only if people actually verify the downloads.  The
> unfortunate reality, as evidenced by our web logs, is that only a tiny
> percentage even download the signature files, much less verify them.
> With SSL, the security isn't as strong.  For example, it wouldn't by
> itself catch a malicious binary placed by someone who hacks the
> distribution server.  Plus SSL CAs aren't very trustworthy.  But at
> least the browsers check it automatically for each download.
>
> I'm not suggesting changing the Nmap PGP-signing model (though we
> probably should use SSL distribution in addition to the PGP signing).
> But I think an update service using SSL should not be ruled out just
> because it isn't GPG-key-based.

Some thoughts on that:  SSL only provides last hop entity
authentication, not end to end authentication (a.k.a. data origin
authentication, both implying integrity).  I assume that there
will be mirror servers.  With SSL, you only have the assurance
that the update was not modified in transit between mirror server
and client.  However, you don't protect against mirror server
distribution files being trojaned after a break-in, or by a rogue
mirror server administrator, or in transit between master server
and mirror server.

I think that requirement should read "data origin authentication"
or some such, not "GPG".  Data origin authentication could also
be provided by a custom solution, based on X.509 certificates or
raw RSA/DSS/whatever keys.

Of course, security requirements vary wildly, but personally, I
regard data origin authentication as a must for any automated
update solution.

-- 
Daniel Roethlisberger
http://daniel.roe.ch/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/