3

This question already has an answer here:

When you download a file, sometimes the website owner puts an MD5, SHA1, SHA256 or similar hash/checksum of the file right next to it; either on the page where you can download it, or as a separate file you can download.

It is wonderful as a way to check integrity; if the checksum I can compute locally from the file and the observed checksum don't match, then something went wrong during downloading.

However, it frequently happens that these checksums are shown on pages that are (only) accessible by a non-end-to-end encrypted connection.

If you're not using an end-to-end encrypted connection, doesn't that mean that this whole approach is open to man-in-the-middle attacks, and that a checksum proves very little? (After all, Trudy the intruder could replace both the file you download and the checksum you would percieve with variants of her own, malicious files).

Am I missing something here? Is there any purpose for providing checksums on a non-HTTPS location?

marked as duplicate by Steffen Ullrich tls Oct 2 '16 at 19:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2

These checksums are there to defend against accidental corruption, not against a malicious attacker.

I've had instances where the download was corrupted or stopped midway through but the browser didn't error out and still considered the file complete - using the checksum we can easily detect such occurrences.

The checksum can also be used to tell whether a file you already own is the same as the file you're about to download without downloading is, thus saving bandwidth which can be precious on low-speed or metered connections.

Not the answer you're looking for? Browse other questions tagged or ask your own question.