A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Link Hashes: Difference between revisions
No edit summary |
(Added a link to Gervase Markham's article on Link Fingerprints.) |
||
Line 83: | Line 83: | ||
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967 | http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967 | ||
</pre> | </pre> | ||
The [http://www.gerv.net/security/link-fingerprints/ Link Fingerprints article] by Gervase Markham gives more details. | |||
==== Processing Model ==== | ==== Processing Model ==== |
Revision as of 18:42, 17 November 2006
Many download sites, especially for software download, give hashes or digests for the file they distribute so that users can check the validity of the files once they've downloaded it. The process for verifying the hash however isn't straightforward.
Problem Description
A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file. Checking the file ensure that the downloaded file is same as the author of the page wanted to give you. Corrupted or tampered files can be detected that way.
The problem is that there is no way to automate that verification process. To automate this process, a browser would need to extract the hash associated with the link on the original page.
Current Usage
Some links to software download pages featuring hashes:
- Apple: Security Update 2006-006
- PHP Downloads
- Apache: HTTP Server
Other examples can be found on the hash examples page on the Microformat wiki.
Benefits
Easier discoverability of tampered files which could come from a mirror server being hacked.
Proposed Solutions
hash attribute
A hash attribute could contain a md5 checksum of the target file. If the hash of the downloaded file does not match the one from the link, the file is deleted or quarantined and the user is alerted of a potential security risk.
<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
Processing Model
When the link is clicked, the browser keeps the hash in memory to compare it with the it hashes from the downloaded file. Once the file is downloaded, the the computed hash is compared against the expected hash.
- "To be completed: what to do about non-download links, like links to other pages, when they have a hash?"
Limitations
- Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.
Implementation
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.
A browser could display the following message when in case of hash mismatch:
- File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?
[Delete File] [Keep in Quarantine]
Adoption
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.
Hash Microformat
The hash microformat provides a way to associate hash values with links:
<span class="download"> <a rel="bookmark" href="...">Download OpenOffice.org <span class="checksum md5">e0d123e5f316bef78bfdf5a008837577</span> </a> </span>
The microformat is better described on the hash-examples page.
Processing Model
When a link is clicked, the browser check if it corresponds to the microformat (details to be added). If it is the hash value is extracted and, once the file is downloaded, the computed hash for the file is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.
- "Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"
Limitations
- Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.
Implementation
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.
A browser could display the following message when in case of hash mismatch:
- File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?
[Delete File] [Keep in Quarantine]
Adoption
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.
The microformat markup is heavier that it needs to be. It also force page authors to put the hash visible inside the link, or to apply specific stylesheets to hide it on visual browsers.
Link Fingerprint
Append a digest for the file in the fragment identifier of the URL. The browser can then check the validity of the file when it downloads it.
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
The Link Fingerprints article by Gervase Markham gives more details.
Processing Model
When the link is clicked, the browser check if the URL contains a hash. If the URL contains a hash, once the file is downloaded the computed hash is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.
- "Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"
Limitations
Work only for downloaded files; fragment identifiers are used in other ways for regular pages and PDF files opened in the browser with a plugin.
Implementation
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.
A browser could display the following message when in case of hash mismatch:
- File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?
[Delete File] [Keep in Quarantine]
Adoption
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.
Content-MD5 HTTP Header
It has been suggested to use the Content-MD5 HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.
Mailing List References
- Re: hash attribute -- Tom Pike, Wed Nov 8 05:21:22 PST 2006
- Re: hash attribute -- Ian Hickson, Wed Nov 8 08:28:19 PST 2006
- Re: hash attribute -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
- Re: hash attribute -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006