On 6/23/2007 2:31 PM, Nelson B wrote: > Gerv, Your web page http://www.gerv.net/security/link-fingerprints/ > doesn't provide any obvious channel for feedback or public discussion > of that proposal, that I can see. So, I'm using this channel. > > The page makes certain claims that I don't believe. Here's one. > >> To substitute a trojan, the attacker would need to hack both the download >> site and the website supplying the information - or the user's mailbox. > > Unless the page that contains that link is an https page, to substitute a > trojan, an attacker need only substitute his own URL for the original > page's URL while the page is in transit. A proxy server is a perfect > place to perform such an MITM attack. Http pages with login forms that > submit their contents via https have the very same vulnerability. >
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. 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. 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. 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. See bugs #101743 and #292481, both of which (especially the latter) seem to be addressed in Gerv's Web page without being cited. By the way, I really like your last sentence about "Http pages with login forms". I unsuccessfully tried to convince my bank of this. See my <http://www.rossde.com/editorials/CalOaksBank.html>. The problem was partially solved when they redesigned their login to split the user ID and password onto two separate pages. With the password now on an HTTPS page, I feel more secure. -- David E. Ross <http://www.rossde.com/>. Anyone who thinks government owns a monopoly on inefficient, obstructive bureaucracy has obviously never worked for a large corporation. © 1997 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
