6

Assuming that both the page linking the download, and the download itself are on trusted domains over HTTPS, is there any reason to worry about checking the hash/checksum of the downloaded file (especially executables/installers, which are also not themselves signed by something the OS trusts)?

As I understand it the reason to do so is to catch download errors (although TCP should do this?) or malicious attacks infecting the files.

But HTTPS (TLS) should already provide full protection from those, so is there any further value in manual validation?

Fire Lancer
  • 1,413

2 Answers2

8

I wouldn't think HTTPS would catch either of those. AFAIK HTTPS offers no additional protection from corruption over TCP.

I'm no security expert, but I know that TLS (HTTPS) does these 2 things:

  1. Verifies that the server you are connecting to is actually who they say they are.
    For example if you type in https://microsoft.com and your traffic gets sent to https://badguys.com instead without your knowledge (DNS spoofing), you'll get a certificate error. Sure the bad guys could create a fake certificate on https://badguys.com that claims to be https://microsoft.com, but it won't be signed by a valid certificate authority.
  2. Encrypts the traffic so that it cannot be read/altered by a Man-in-the-middle attack (MITM). In this scenario, someone can see all your network traffic. If you weren't using TLS they could detect a GET request and start sending you fake data, in place of the real data from the web server.

Back on the topic of downloads, many sites distribute their large downloads to mirrors. If the mirror is compromised, the file can be replaced with a malicious version. Even if the mirror uses TLS, if it was hacked or wrongfully added to the mirror list, you can be downloading a malicious version from a HTTPS site. And of course if this happens, they will update the checksum on the mirror.

This is why you should never verify a download against a checksum from a mirror, only use the checksum from the original site (as per this question).

Ian
  • 942
1

Adding to Ian's response.

In a MITM attack, the man-in-the-middle won't be able to change the payload to something malicious, hence the checksum is useless.

If the MITM has root certs installed on client's machine, or is somehow able to manipulate the connection, then checksums are ALSO useless, because he can change the checksums that are displayed.

Against a server attack, the same thing should happen, if he already has access to the server, he will be able to change the checksum. But, if the server is split (download server and a server to show the download link/checksum), then it would be better to provide a checksum.

So I think the rule of thumb is: if the server that is displaying the checksum is the same that provides the download file, then the checksum is useless. If you have multiple mirrors, it's a must.

late update/not exactly security related but useful to know:

I have found another valid reason to add checksums, which is for files that are probably going to be archived (for instance, in archive.org) so the users know that the file they're getting is the same as when it was available on your site.

And it also help if you're trying to find an specific version of the file in the internet (considering it's versioned under the same executable name), some mirror sites or archive sites has the MD5/SHA1 of the file available for search engines, so you might be able to find it easier by searching for the hash instead (I have actually came to this specific problem in the past and found it by searching for the HASH).

Lucca Ferri
  • 111