[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fv8xd7zy.fsf@hope.eyrie.org>
Date: Sat, 21 Mar 2015 20:30:09 -0700
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
Daniel Micay <danielmicay@...il.com> writes:
> It would be much better to provide the download via HTTPS from a domain
> that's HSTS preloaded and ideally has some level of key pinning. We are
> all well aware that few users are going to go through a manual process
> on the command-line to verify the download, especially if they're on
> Windows as they won't have the commands that are being used.
Unless you do certificate pinning, I don't see how this adds much
meaningful security. Commercial CAs at the level of browser verification
of server certificates are a bad joke. You should assume that a
moderately sophisticated attacker can get a valid brower-acceptable
certificate for any web site they choose, particularly given the number of
opportunities attackers have to insert new root CAs into the user's
browser store. (Sometimes even preinstalled on the factory-shipped
computer.)
I think the approach Debian takes here has some real merit, although it
would still be a good idea to offer https downloads just for privacy
reasons (it's hard to do so just because of the way the mirror network and
the commercial CA world work). Because the downloads are over HTTP,
everyone goes "wait, what?" and looks for the *actual* security, which,
provided you can get a good bootstrap of the initial public PGP keys, is
quite a bit better than just TLS verification of the server. As opposed
to seeing TLS and assuming that adds meaningful verification of the
server, which is dubious.
And that approach has the significant advantage that, because it uses
proper public key cryptography, anyone can mirror the packages and you
don't have to care where you got the packages from or establishing a full
trust chain for them. You only have to do that for the published signing
key, and then verify the signatures, which apt does for you. This is a
pretty huge advantage, since it means that large organizations can just
mirror the repository with rsync, and any apt client can be pointed to the
mirror without needing to configure any new keys and while getting the
same level of security validation.
The problem, of course, is how to do the bootstrap, and that's where the
original post came in. The ISO images presumably (like Debian's) include
the pre-installed repository signing keys, so known-good ISO images are a
way to bootstrap the security of subsequent downloads. But this requires
actually verifying the ISO signatures in some meaningful way, which is
hard for the average user to do, since there isn't any pre-existing trust
relationship that one can easily leverage.
--
Russ Allbery (eagle@...ie.org) <http://www.eyrie.org/~eagle/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
