Re: CVE for Kali Linux

[Daniel Micay <danielmicay () gmail com>]

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

Their browser and operating system are inherently trusted when modeling
the threats involved in the user downloading something with it. It's not
an excuse to introduce unnecessary vulnerabilities.

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

Debian is not using HTTPS for the ISO download. I was pointing out that
the trust starts when the user arrives at the site. The point is that a
compromise at this point is all that's necessary for an attacker.

It doesn't really matter what you think about HTTPS. It must work for a
non-expert user to visit the site and download the distro securely. The
attacker could provide instructions and files of their choice if it did
not work, so it's an upper bound on the security of the whole process.

DNSSEC/DANE provides another model for securing that HTTPS connection,
but since it's unimplemented by clients it has no value here. Anyway, it
means trusting an even more centralized system run by people who have
decided that 1024-bit RSA is good enough for the keys with the ultimate
level of trust.

> Its also far more portable than browser pinning allows.

It's more portable in the sense that no one implements it, rather than a
few projects implementing it. There's no inherent limitation of HPKP to
web browsers. HPKP is the ideal solution for critical infrastructure and
popular sites. The problem with it is the the inability to scale, which
is why stuff like PKI and DANE exists in the first place.

There's no reason that HSTS or HPKP is limited to web browsers. It would
work fine for tools like curl/wget if someone felt like doing the work
to implement it. The lists in Chromium/Firefox could be extracted and
merged together. It's a set of restrictions, not something that is
granting extra permissions.

> 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 can see why they don't want to implement a non-solution. Is placing
ultimate trust in Verisign for every .com domain really what you want?

The domain name registrars they feel like doing business with are the
other set of people you have to trust.

Perhaps people aren't implementing it because we don't need another
overly complex and very flawed security technology. It has a *lot* more
wrong with it than simply the lackluster trust model. I'm not here to
argue about DANE though...

> HTTPS as commonly implemented is a joke, which is how the channels get
> routinely hijacked.

The GPG implementation is in way worse shape than the widely used
implementations of TLS. Regardless, HTTPS is used to secure things
initially so you don't gain security by using something else for the
later steps.

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

You missed that I've been talking about HSTS preload lists. If you set
the expiry long enough you can simply ask for it to be included in
Chromium and Firefox and they'll do it. What's the problem with that?

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

It doesn't increase any footprint. I agree that it can't scale, but it
only needs to scale enough to bootstrap sane trust systems like the
package signing models used by distros like Debian and Arch. It's a set
of restrictions so I don't see what you'd lose by using Mozilla's list
of pinned keys elsewhere just as Debian and other distributions use
their list of trusted root certs.

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

The root server as the ultimate authority. I can't see centralizing all
trust in organizations like Comodo and Verisign. Seriously, DNSSEC is
dead after the NSA shitstorm. I doubt that people are going to place
ultimate trust in a few American corporations with very close ties to
the US government. That applies to the IANA too, regardless of any
rebranding they feel like doing.

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

The delay in revoking keys is very minor issue compared to "place full
trust in VeriSign *and* your domain registrar".

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

Again, I am not talking about package signing.

The user can't be assumed to have apt and the Debian keychain... they
are downloading the distribution.

If you somehow convinced every operator system vendor to bundle the GPG
key used to sign the ISO for distribution X, then great, you solved the
issue for the few users who are going to manually verify it.

I mentioned torrents to point out that users choosing to download via a
torrent file provided by the original site are already validating that
the download is what it was supposed to be. A direct download via HTTPS
works fine too... if there isn't a bandwidth issue.

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

So you're turning the problem of obtaining an ISO into the dual problem
of obtaining a GPG implementation via TLS, obtaining a GPG key via TLS
and then doing the necessary verification. This is a solution to the
issue of TLS being insecure?

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

How does the user obtain the GPG key? It means security-aware users
already on Debian can download it securely.

GPG is an awful, legacy codebase in a memory unsafe language. It's also
suffering from lack of developers. You're not drawing a contrast with
TLS implementations but rather pointing out a problem that afflicts GPG
to an even greater degree. You already have TLS as part of your trust
chain so GPG is just increasing the vulnerability footprint if you don't
have the key already.

Attachment: signature.asc
Description: OpenPGP digital signature