Why aren't application downloads routinely done over HTTPS?

Question

We all know we should be using SSL whenever we collect passwords or other sensitive information. SSL provides two main benefits:

• Encryption: The data can't be read by a middle-man while in transit.
• Protection against MITM attacks: A man in the middle can't pretend to be a server, since they can't produce a CA-signed certificate for the server.

If I'm downloading an application, I'm probably going to run it at some point, maybe even as root. Some programs will be signed, but many aren't. Shouldn't downloads be done over SSL so that I know that it hasn't been tampered with during transit?

If somebody steals my password, that's bad. But if somebody plants a keylogger on my computer, that's way, way worse.

Answer 1

Note that the part of this answer below the horizontal line was written in 2012, back when the question was asked. At the time, only a small part of the web used HTTPS. Since then, most of the web has switched to HTTPS, so the short answer is ”they are”. This answer is still relevant insofar as it explains what HTTPS does and does not secure, in the context of application downloads.

---

Because HTTPS is not very well suited to securing downloads of large public files. For this use case, it's slow and not that useful. There are reasons for not using HTTPS well beyond incompetence or unawareness.

HTTPS doesn't fully solve the problem. This If you're getting your application straight from the vendor's website, HTTPS does ensure the authenticity of the application. But if you're getting your application from a third party (e.g. mirrors of free software), HTTPS only protects the connection with the third party. A package signature scheme works better: it can protect the whole chain from the vendor. Application distribution requires end-to-end protection and HTTPS doesn't provide that.

HTTPS uses more bandwidth. The overhead per download is minimal if you don't take caching into account. This is the spherical cow of “HTTPS doesn't cost more”: if you use SSL, you can't cache data except at the SSL endpoints. Application downloads are cachable in the extreme: they're large files that many people download.

HTTPS is overkill. The confidentiality of an application download is rarely an issue, all we need is authenticity. Sadly, HTTPS doesn't provide authenticity without also providing confidentiality. Authenticity is compatible with caching, but confidentiality isn't.

HTTPS requires more resources on the server. Google mail got it down to a 1% overhead and a 2% bandwidth overhead, but this is for a very different use case. The Gmail frontend servers do more than mindlessly serve files; a file server doesn't need a powerful CPU in the first place (it's very strongly IO-bound), so the overhead is likely to be significantly larger. The same goes for memory overhead: a file server needs very little memory per session in the first place, almost all of its memory is a disk cache. Getting the resource usage down requires a serious amount of work.

HTTPS wouldn't help many people. The security-conscious will check the hash provided by the vendor (that should be over HTTPS). The non-security-conscious will blithely click through the “this connection is insecure” message (there are so many badly configured servers out there that many users are trained to ignore HTTPS errors). And that's not to mention dodgy CAs who grant certificates that they shouldn't.

---

If you want to make sure that you're getting the genuine application, check its signature, or check its hash against a reference value that you obtain with a signature (for example over HTTPS).

Good vendors make this automatic. For example, Ubuntu provides GPG signatures of its installation media. It also provides the hashes over HTTPS (sadly not linked from anywhere near the download page as far as I can see). After that, the software installation tool automatically checks that packages come with a valid signature. See How to use https with apt-get?

Note: if you're getting the application directly from the vendor (as opposed to via some package repository or application marketplace), then HTTPS does provide protection. So if you're a vendor providing your application directly for download on your website, do protect it with HTTPS!

Answer 2

(Update: please note that this answer is now almost a decade old and does not necessarily reflect the 2021 state of things. I find the zeitgeist interesting to read even if I apparently wrote this myself, so I will leave it for posterity.)

It's the same reason as why not all login prompts are using https yet: people are too lazy, think a certificate is too expensive, or have hosting that charges more for using https.

The real question is why downloads are served over a plain connection more often than login forms. And I think this is mostly because of unawareness. Checksums are often provided, but they are not secure if sent over http. One good implementation of checksums I've seen is where they were posted to Twitter (which uses https, and can be reasonably assumed to be uncompromised). However I don't know anyone who ever checks the checksum, perhaps only if the software doesn't run. Usually TCP is assumed to do reasonable error checking.

Of course, https is heavier on the server than http. For high-traffic websites this may be a reason. But then again, high-traffic websites can also generate 'high-money' to finance it.

Answer 3

Arguably, when users download an application over the web, the application download should be over HTTPS, because it is the cleanest user experience for users that provides security that they can comprehend. It is arguably realistic to expect many users to check for a green glow in the address bar before they download, but it is not reasonable to (for instance) expect them to compute hashes and check them securely.

However, these application downloads often aren't offered over HTTPS, for a variety of possible reasons:

• Good reasons: HTTPS prevents caching in the network. This may increase network traffic, load on the server, and load on the client-side network.

• Bad reasons: People have a mistaken belief that "HTTPS is slow" (which is a myth), because it takes extra work to set up a server with SSL, because they rely upon mirrors and the mirror sites don't use HTTPS, or because people haven't thought of it or don't think they are at risk. For widely-used software, these beliefs are probably short-sighted. Apparently, also some sites may use load-balancers or accelerators that are brain-dead and don't understand HTTPS properly, and they don't want to or can't afford to engineer a proper deployment that can speak HTTPS properly.

Some application distribution sites do use HTTPS. But many do not.

Firefox is one high-profile example of an application that does not use HTTPS by default when you download the application (see How safe are copies of Firefox that are on various Mozilla mirror sites?).

Windows Update is all done over a secure channel (akin to HTTPS). Linux package managers use cryptography to protect the software they download, though not HTTPS itself.

Answer 4

Most of the time there will be MD5sums and SHA1 sums for the application. After you download it you need to check this to the one that is displayed on the website. If the one you calculated is the same, then there is no problem.