Your entire download infrastructure needs to use HTTPS

April 8, 2015

Let's start with something that I tweeted:

Today's security sadface: joyent's Illumos pkgsrc download page is not available over https, so all those checksums/etc could be MITMd.

Perhaps it is not obvious what's wrong here. Well, let's work backwards. The Joyent pkgsrc bootstrap tar archive is served over plain HTTP, so a man in the middle attacker can serve us a compromised tarball when we use curl to fetch it. That's obvious, and the page gives us a SHA1 checksum and a PGP key to verify the tarball. But the page itself is served over over plain HTTP, so the man in the middle attacker could alter it too so it has the SHA1 checksum of their compromised tarball. So surely the PGP verification will save us? No, once again we are undone by HTTP; both the PGP key ID and the detached PGP ASCII signature are served over HTTP, so our MITM attacker can alter the page to have a different PGP key ID and then serve us a detached PGP ASCII signature made with it for their compromised tarball.

(Even if retrieving the PGP key itself from the keyserver is secure, the attacker can easily insert their own key with a sufficiently good looking email address and so on. Or maybe even a fully duplicated email address and other details.)

There's a very simple rule that everyone should follow here: every step of a download process needs to be served over HTTPS. For instance, even without PGP keys et al in the picture it isn't sufficient to serve just the tarball over HTTPS, because a MITM attacker can rewrite the plaintext 'download things here' page to tell you to download the package over HTTP and then they have you. The entire chain needs to be secure (and forced that way) and from as far upstream in the process as you can manage (eg from the introductory pkgsrc landing page on down, because otherwise the attacker changes the landing page to point to a HTTP download page that they supply and so on).

Of course, having some HTTPS is better than none; it at least makes attackers work harder if they have to not just give you a different tarball than you asked for but also alter a web page in flight (but don't fool yourself that this is much more work, not with modern tools). And it's good to not rely purely on HTTPS by itself; SHA1 checksums and PGP signatures are at least cross-verification and can detect certain sorts of problems.

By the way, in case you think that this is purely theoretical, see the case of some Tor exit nodes silently patching nasty stuff into binaries fetched through them with HTTP. And I believe that there are freely available tools that will do on the fly alterations to web pages they detect you fetching over insecure wireless networks.

(I don't feel I'm unfairly picking on Joyent here because clearly they care not just about the integrity of the tarball but also its security, since they give not just a SHA1 (which might just be for an integrity check) but also a PGP key ID and a signature checking procedure.)

Comments on this page:

By Albert at 2015-04-08 04:04:22:

This was discussed recently on the RISKS mailing list: (original message, complaining about mostly the same thing) (answer)

By cks at 2015-04-08 12:03:25:

The reply in RISKS 28.58 is dangerously incomplete; how do you securely obtain the initial package signing key for Kali? If everything is distributed over HTTP instead of HTTPS, the answer is 'you don't'; an attacker can compromise the initial copy you download to have their key instead of the real key, then just sign all further (compromised) packages you get with that key. This is effectively just like what Joyent is doing when they provide the PGP key ID to use for verification on an insecure web page.

(A clever attacker might be able to give you both their key and the real Kali key, so they can mostly let you use real packages and real mirrors but substitute a compromised one whenever they feel like.)

From at 2015-04-08 13:13:44:

Comment on the discussion from a Kali developer.

By Albert at 2015-04-09 03:57:44:

Well, usually PGP keys are (on purpose) widely distributed and can be downloaded and cross-checked from multiple sources. It would be quite hard for an attacker to compromise them all.

By Joshua M. Clulow (Joyent) at 2015-04-11 13:17:07:

I emphatically do not agree that everything needs to be over HTTPS. It is, frankly, a waste of cycles to encrypt the bulk downloads themselves. Rather, signing the download with a PGP key is not just sufficient, it actually provides real security and not just a feeling of security.

The HTTPs trust model is pretty bad. Many organisations inject their own certificates into the trust stores of corporate machines so that they may sniff (and modify) traffic from workstations and servers. Laptop manufacturers have even been caught doing it, as recently as this year. If a Certificate Authority (CA), even by accident, signs a domain without correctly verifying identity then they are instantaneously a gaping, difficult-to-detect hole in the trust chain.

I agree that telling users to find our PGP key on the unsecured front page along with all of the other materials is not our best foot forward. What we do with Node is considerably better: we sign a manifest of SHA signatures of all distributable files using the key of the current release manager. This key is available via several third party services, such as, where the user is encouraged and expected to get it. The trust chain is explicitly not something we provide solely through our website, but indeed a larger set of infrastructure owned by multiple parties. People who download more than one Node release can use their previously obtained copy of the key material, in the same way that SSH stores host fingerprints, for an additional layer of protection.

We should absolutely push for better integrity of downloaded software, but HTTPS is not an appreciable increase in real security -- just security theatre.

By cks at 2015-04-11 15:29:06:

I disagree very strongly with your view that HTTPS for downloads is a waste of cycles in general. The practical reality is that very few people will securely obtain your PGP key and go through the effort of PGP-verifying your signed collection of hashes by hand. I expect that almost everyone simply downloads things and just installs them; as a result a non-HTTPS download gives them no security.

Some will now say that those people who didn't verify downloads with carefully obtained PGP keys don't really care about security and deserve the lack of security that they get. This is wrong. As always, security is people, not mathematics; if actual people are not using your download system securely, you have not created a secure system. You have not solved the real problem, you've just washed your hands of it.

HTTPS is a mess. HTTPS has flaws. But for most download situations HTTPS is unambiguously better than non-HTTPS, and you should be using it.

(As a side note, you can safely switch to non-HTTPS downloads if your initial bootstrap is delivered over HTTPS and it automatically verifies those non-HTTPS downloads, rejecting anything that fails.)

Written on 08 April 2015.
« How Ubuntu and Fedora each do kernel packages
Probably why Fedora puts their release version in package release numbers »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Apr 8 01:04:58 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.