[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550E8162.1040602@treenet.co.nz>
Date: Sun, 22 Mar 2015 21:46:26 +1300
From: Amos Jeffries <squid3@...enet.co.nz>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
On 22/03/2015 5:12 p.m., Daniel Micay wrote:
> On 21/03/15 11:30 PM, Russ Allbery wrote:
>> Daniel Micay 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.
Cert pinning would increase the vulnerability footprint with regards to
whether the browser being used was trusted, ANd whether the pinned cert
database was tructworthy. Same as the issues already outlined for
obtaining gpg and apt trust.
>
> 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.
Look a bit closer, past the https://. Debian are using DANE (DNSSEC and
TLSA records) to publish their HTTPS details in a way which avoids
dependence on the browser organizations security and pinned certificate
registry. Its also far more portable than browser pinning allows.
Unfortunately the browser vendors are letting us all down by refusing to
implement DANE validation and going with their in-house developed
mechanisms instead.
>
>> 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.
HTTPS as commonly implemented is a joke, which is how the channels get
routinely hijacked.
HSTS is a joke today due to the insecure channels - so your going to
send a flag saying the content MUST be kept secure ... over the channel
that just got hijacked. Yay.
HPKP helps - but increases the footprint of things that have to be
secured and thus trusted. And only covers the major browsers or
implementers capable of developing their own registries for pinned certs
- otherwise you are back to trusting the browser vendors X, Y, or Z
registry again.
With DANE the TLSA record is under control of the publisher, and DNSSEC
ties it securely to both the origin server for the HTTPS channel, and to
the keys of a mutually trusted upstream authority in a web-of-trust like
model. Only the DNS root server key needs to be bootstrapped at some
point down the chain.
Single point of vulnerability with 0-24hr DNS TTL updates turnover when
attacked,
vs.
multiple points of vulnerability with weeks of turnaround to publish new
browser updates plus all the time to get the user population upgraded.
>
> 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.
You still have the bootstrap problem of how to validate the torrent
client binary. Might as well use apt validation and avoid the complexity
of torrent.
>
> Windows users are also left out without this: they don't have GPG, and
> they don't have a secure way to obtain GPG.
>
Ironically the safest way to obtain GPG is probably to download it with
Internet Explorer these days.
Consider the signed boot loader validated by CPU itself, loading a
signed OS, loading signed WUpdate binary, installing signed MSIE and
certificates binaries, running the resulting signed browser to connect
to a HTTPS download site for signed GPG installer - should (in theory at
least) be signed from top to bottom.
Of course there are loopholes at the browser trusted-CA and cert
pinning stages, browser not veryfing download signatures and side
channel infections are an ever present problem. But then those are still
issues if one uses a non-IE browser installed between the IE and GPG
stages (at risk of more software ~= larger vulnerability footprint).
AYJ
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.
