David E. Ross wrote: > The page also proposes some implementation details that are troublesome. > For example, a hash mismatch would cause the downloaded file to be > deleted. Also a misformed hash would block downloading. Both of these > create denial-of-service opportunities; all a hacker has to do is alter > the hash in the anchor (link) that would be used to initiate downloading.
But if the attacker has that ability, then all they have to do is alter the URL to point to somewhere else entirely! I don't see this as a particular disadvantage of link fingerprints. > Of course, the Web author could accidentally provide a bad hash. Or the > Web author could forget that ASCII files might get modified during FTP > operations, invalidating the hash. Such a forgetful author might also > forget to change the hash in the anchor when changing the file that the > link downloads. Each of these situations results in the page's author > creating his or her own denial-of-service. Yes. All of these are intentional. People using Link Fingerprints should test their links before providing them to others. If the author intends to change the file the link downloads, and yet wants old links to continue to work, he should not be using Link Fingerprints. > I much more favor providing both the target file and a separate file > containing the hash, as is done on the Mozilla FTP site. I actually use > this situation to verify the integrity of the downloaded file with > Mozilla's MD5 hashes. But if the hash is provided from the same source as the download, then a hacker who can replace one can just as easily replace the other. The other problem with putting the hash in a separate file on the server is that there is not programmatic way of detecting and downloading that file, without scattering 404 Not Found errors across the logs of servers worldwide. HTTP has the Content-MD5 header. If we are concerned about corruption in transit, we should start supporting that. That is not what Link Fingerprints are for. > While MD5 is now known to be vulnerable to hacks > based on collisions, it's still valid for checking the integrity of a > file in the absence of hostile actions. I'm sure it is. However, that's not the use case of Link Fingerprints. Gerv _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
