Re: CVE for Kali Linux

[Daniel Micay <danielmicay () gmail com>]

On 21/03/15 11:30 PM, Russ Allbery wrote:
> Daniel Micay <danielmicay () gmail 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 fully agree that the PKI system is downright awful. HTTPS + HSTS is
still way better than nothing for the vast majority of users who aren't
going to validate the ISO download manually. Debian would have no issue
getting a certificate pinned in Chromium and Firefox, and I expect that
even much smaller distributions could get included.

The home page that users land on when they want to download the distro
is secured via HTTPS so you're relying on that to initiate the trust
model regardless of the better PGP-based model that's used for package
signing afterwards.

> 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.

I fully agree with what you're saying about package signing. It's what I
pointed out in my other email:

http://www.openwall.com/lists/oss-security/2015/03/22/6

It's a distinct issue from the initial download though, where the user
needs to obtain the PGP keyring in the first place. HTTPS + HSTS + HPKP
has a *lot* of value for bootstrapping the trust model. It provides a
high level of security for *all* users rather than just a tiny minority
willing to go through the trouble of manual verification.

You only need to provide the users with a torrent file securely and
you've done your job, as the torrent client will validate SHA1 hashes.
The mirrors work fine as web seeds. Note that this doesn't require the
user to take any additional *optional* steps to validate, because once
you do that you've failed the majority of users.

Windows users are also left out without this: they don't have GPG, and
they don't have a secure way to obtain GPG.

Attachment: signature.asc
Description: OpenPGP digital signature