mailing list archives
Re: [nmap-svn] r23169 - nmap-exp/colin/updater
From: Daniel Roethlisberger <daniel () roe ch>
Date: Wed, 18 May 2011 16:05:04 +0200
Fyodor <fyodor () insecure org> 2011-05-18:
On Sun, May 15, 2011 at 05:19:48PM -0700, commit-mailer () insecure org wrote:
--- (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
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/