63

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.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
Tom Marthenal
  • 3,272
  • 4
  • 22
  • 26
  • Actually, there are [*three* main benefits](http://security.stackexchange.com/a/21/33): confidentiality, integrity, and authenticity. I.e. encryption, hashing, and authentication. Though in this case I assume you are more focused on the 2nd and 3rd... – AviD Aug 19 '12 at 10:18
  • 10
    `The data can't be read by a middle-man while in transit` does not apply in application download scenario. If I know you're visiting mozilla's website and you're downloading a large amount of data, it is almost certain without even looking at your data stream that you must be downloading the latest version of Firefox, and I can just go to Mozilla instead of having to decrypt your data stream. So serving application downloads over HTTPS only really protects against MITM. – Lie Ryan Aug 19 '12 at 12:28
  • 2
    @LieRyan, which is what I said. "SSL provides two main benefits" was more of an overview of SSL than it was a list of benefits for downloaded files. – Tom Marthenal Aug 19 '12 at 21:26
  • 2
    The best solution might be some sort of link fingerprints. See: http://www.gerv.net/security/link-fingerprints/ This ensures integrity of publicly downloadable files. Only the link needs to go over https. Everything else remains cacheable, or the link can be used to find a download from a mirror or torrent automatically. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034885.html – rjmunro Aug 20 '12 at 23:05
  • @Lie Ryan: Traffic analysis will give you hints on what is *likely* to be in transit - but knowing that I'm probably downloading *a* Firefox binary is much less useful than knowing that I'm downloading a Firefox binary of version Foo, UI language Bar, architecture Baz for OS Quux - not all builds are created equal ;) Moreover, some OSes have repositories hosting many apps - I have a connection open to `https://repository.example.com/`, hosting packages for a distribution; *now* what am I downloading? – Piskvor left the building Aug 21 '12 at 09:31
  • (I'm aware that the Windows situation is very much different, and that most Linux distros use a different integrity mechanism, i.e. package signing) – Piskvor left the building Aug 21 '12 at 09:41
  • More generally, [Why is HTTPS not the default protocol?](http://security.stackexchange.com/q/4369) – Gilles 'SO- stop being evil' Aug 30 '12 at 20:11
  • 2
    Wait, HTTPS *isn’t* used for most software downloads? Oh, I see, this question was asked years ago… – binki Dec 14 '15 at 21:02
  • 1
    @binki unfortunately it's still not the standard – elipoultorak Apr 03 '16 at 09:00
  • HTTP download puts people in danger: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ – Tom Mar 11 '18 at 09:18
  • People are using that post to justify http downloads: https://bugs.launchpad.net/homebank/+bug/1490346 – Tom Mar 11 '18 at 09:19

4 Answers4

62

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!

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 6
    I asked my old employer why we were forcing HTTPS for everything and their reply was "Because we have an extended validation cert and people respect the color it turns their browser bar" .. my desk almost broke when my head hit it. This is a very useful answer that I hope helps to dispel some of that 'mythical' thinking. – Tim Post Aug 19 '12 at 03:57
  • 1
    The caching point is misleading. Of-course you can cache the data received using SSL. What you call "caching" here, is in fact a man in the middle attack. I do not want my network to inspect my traffic, just to provide a "cached" version of the data. – Nappy Feb 15 '16 at 17:22
  • 2
    @Nappy You cannot cache the data transmitted over SSL except at the point of origin or destination. It's often useful to cache data in the middle, e.g. a site cache of packages where many machines run the same set of applications. And indeed caching is a potential man-in-the-middle replay attack. – Gilles 'SO- stop being evil' Feb 15 '16 at 18:12
  • @Gilles I already got your point, but your statement in the answer "if you use SSL, you can't cache data" has to be more precise, because the way you phrase it you make the impression, that you have to decide between the two, and that is not correct. Even with SSL you still have a lot of options to provide proper caching. (Client side caching, DNS, Terminating the SSL at the cache/load balancer itself, etc.). Transparent proxies (for outgoing connections) are bad practice anyway in my opinion, but even I you want to make that point, I should be more precise. – Nappy Feb 15 '16 at 18:36
  • 3
    By the way: Technically it is also not correct that "HTTPS doesn't provide authenticity without also providing confidentiality". You could configure your server or client to only support ciphers with authentication but no encryption. `openssl ciphers -v 'eNULL:!aNULL'` I do not recommend this of-course, only for the sake of an argument ;) – Nappy Feb 15 '16 at 20:13
  • That answer puts people in danger, literally :https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ https://bugs.launchpad.net/homebank/+bug/1490346 – Tom Mar 11 '18 at 09:14
  • 1
    @Tom What puts people in danger is the lack of **end-to-end** verification, not the lack of HTTPS. I've added a more prominent to my answer about the necessity for end-to-end verification. If *direct vendors* aren't providing HTTPS, you can now point them to the last paragraph of my answer. – Gilles 'SO- stop being evil' Mar 11 '18 at 09:22
  • @Tom The biggest risk in terms of application distribution these days is application stores such as Google's and Apple's, where you know that you're getting what Google/Apple is redistributing, but you have no idea who made that software and uploaded it, because all the UI tells you is the vendor's name and logo, which anyone can fake. – Gilles 'SO- stop being evil' Mar 11 '18 at 09:25
  • @Gilles it's not the biggest risk, and everybody have different threat models. If you want to improve your Android security you can use F-Droid, but if you need to download VLC for Windows, you have no choice, only http. HTTPS is necessary, but more need to be done, for example, SRI: https://github.com/w3c/webappsec-subresource-integrity/issues/68 – Tom Mar 11 '18 at 09:35
17

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

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 3
    I check checksums, I don't mind http mirror, if the checksum itself is secure so I can check it against. I would add that all the major package managers on linux do signing and.or checksum checks. – ewanm89 Aug 18 '12 at 23:05
  • 1
    Assuming you're MITM'd you can't trust any connection without TLS and a verified signature. That includes twitter. – Aurelia Jul 25 '13 at 17:59
  • @DamonGant What do you mean "that includes twitter"? Manually going to http://twitter.com in a private navigation window (no cookies or other cache) automatically redirects me to https (which is TLS, as I guess you know). And the browser checks the certificate's signature. So I don't understand what you mean. – Luc Jul 26 '13 at 00:10
  • @Luc sslstrip. For instance. – Aurelia Jul 29 '13 at 08:52
  • 1
    @DamonGant Oh of course, ssl is broken when you don't either type https:// or verify that it's secure (padlock). Still, I think Twitter can be assumed to be a reasonably secure way of distributing checksums. And if you're smart enough to run checksums, you're probably also smart enough to make sure your connection to Twitter is secure. – Luc Jul 29 '13 at 19:14
  • 2
    @Gant: Twitter is in HSTS preload list of all major browsers, so it's not vulnerable to sslstrip. Your connection to Twitter is likely secure due to the preload. The only problem with publishing your signatures/checksum over Twitter is that you have to trust Twitter, which may not fit everyone's threat scenario. – Lie Ryan Oct 23 '16 at 11:33
10

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.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    The biggest problem usually is that servers in big deployments sit behind braindead accelerators that reverse proxy all requests. Deploying SSL in such distributed environment is either impossible, very hard or cuts performance by wide margin (because SSL can't be properly set up or is, simply, broken) – Hubert Kario Aug 19 '12 at 01:29
  • 4
    HTTPS is a bandwidth hog compared to HTTP because it renders proxies unable to cache. When you, for example, have 300 machines that need a major Firefox upgrade, that makes a *huge* difference. The right solution is to use HTTP but to verify the application's checksum or signature. – David Schwartz Aug 19 '12 at 05:38
  • 9
    @DavidSchwartz "_The right solution is to use HTTP but to verify the application's checksum or signature._" The right solution would be a protocol for secure public downloads (with a new URL scheme). – curiousguy Aug 19 '12 at 08:07
  • @D.W.: AFAICT, most Linux package manager uses cryptography to sign the package and for authenticating the servers and the checksum, but I've never heard any that encrypt the packages itself, that would be just a wasteful use of resources without additional security. Also, your article does not apply for application downloads; the workload characteristic of a mail server or a web server is very different from a file server. In application download scenario, everyone is downloading the same files, unlike in a mail server where everyone are served different contents. – Lie Ryan Aug 19 '12 at 12:20
  • 3
    @DavidSchwartz, great point! Thank you. I've updated my answer with your observation. Sounds like one clean solution to that is to make a small downloader program available over HTTPS; when the user runs it, it performs the secure download and checks the checksums. (I don't think it is reasonable to expect users to verify checksums or signatures manually; you need to make it automatic.) – D.W. Aug 19 '12 at 16:30
  • "_it is the cleanest user experience for users that provides security that they can comprehend._" what about HTTPS webpage with just a script to initiate a download via HTTP, then check the result file? (so all the user sees is an `https:` URL) – curiousguy Aug 19 '12 at 16:54
  • @DavidSchwartz "_it renders proxies unable to cache_" I used to believe that they disappeared long ago. – curiousguy Aug 19 '12 at 17:28
  • @curiousguy, that would be a good user experience, but I don't know if it is feasible to implement that in Javascript. I don't know of any way that Javascript can download data, check a signature on it, and then save it to a file only if the signature was valid. (Javascript can initiate a file download over HTTP, but that doesn't allow the script to check the signature on the resulting file and delete the file if the signature is invalid.) – D.W. Aug 19 '12 at 19:51
  • @LieRyan, thanks, I've updated my answer based upon your comments about Linux package managers! As far as your comments about performance, that doesn't sound right to me. The performance overhead due to SSL for serving a large file should be *even lower* than for a mail server. The handshake is the only part that is potentially expensive; serving a large file involves just one handshake, and the cost of that is likely negligible compared to the cost of serving the file. – D.W. Aug 19 '12 at 19:53
  • 1
    @D.W.: What would you think of having the HTML tag which triggers the download include the expected hash of the file? If the tag itself comes from a secure site, that would ensure that illicit modifications to the download could be detected (if the header from the GET request added a tag that included the hash of the file, scenarios where the HTML tag's checksum was out of date could be flagged immediately as an error, without wasting time downloading a file that would fail validation). – supercat Mar 07 '14 at 19:19
  • @supercat, if you are proposing add a new tag to the HTML standard, you'd have to take it up with the standards organizations and the major browser vendors. They are the ones who decide. (I suspect you might quickly find that adding anything to the standard requires non-trivial thought about all sorts of subtle cases one might not think of, and so they have a high threshold for making these kinds of changes to the standard...but you'd have to talk to them, not me.) – D.W. Mar 07 '14 at 19:26
  • 1
    Protocol designed to be efficient large file downloads, automatic caching by participating machines, automatic cryptographically secure checksum, confidentiality is of little concern. To me that sounds awfully like torrents. – Lie Ryan Oct 23 '16 at 11:46
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.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 4
    Which can be tampered with as well. – Luc Aug 18 '12 at 22:41
  • @Luc: precisely--this is the same reason a login page must be in HTTPS and not just the page/controller that processes a login request. If I'm accessing the download page over regular HTTP, then an attacker can simply swap out the checksum for one of their own. – Tom Marthenal Aug 18 '12 at 22:44
  • I suppose you were looking at the page in https and the download being done over plain http. – Lucas Kauffman Aug 18 '12 at 22:44
  • Unlikely, but sure that's possible yeah... – Luc Aug 18 '12 at 22:45
  • 1
    "_After you download it you need to check this to the one that is displayed on the website._" which is OK if 1) the integrity information is downloaded via a secure protocol, so tempering is impossible 2) the checking step is fully automated, so you don't get a chance to forget (or take the easy way out). IOW, if a sane package manager handles that. – curiousguy Aug 18 '12 at 23:55
  • 2
    HTTP+Checksum or signature may be the right solution for a specialized protocol, such as an updater or a packet manager, but not for downloads from the browser. Usability is simply too bad. You can't expect that a normal user manually verifies the checksum. – CodesInChaos Aug 19 '12 at 07:46