Link Hashes - Revision history

Hildjj: /* hash attribute */

2013-11-20T08:36:47Z

hash attribute

← Older revision		Revision as of 08:36, 20 November 2013
Line 54:		Line 54:
	<pre>		<pre>
	<a href="..." hash="b3187253c1667fac7d20bb762ad53967">		<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
			</pre>

			Note: MD5 is a particularly bad choice here, assuming that the resource being accessed can be modified by an attack (e.g. it is open source). A collision attack where the original message's JavaScript comments are modified to produce the same hash as a valid JavaScript file that does something malicious would be unfortunate.

			As well, algorithm agility would be nice. Brad Hill [http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0129.html suggested] a syntax like:

			<pre>
			<link href="https://www.example.com/foo.css" digest="sha256:ab8e92231...">
	</pre>		</pre>

Mnot at 04:24, 14 November 2013

2013-11-14T04:24:00Z

← Older revision		Revision as of 04:24, 14 November 2013
Line 1:		Line 1:
	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.		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. Furthermore, there are other use cases where link hashes might be useful to improve caching or modify the user experience of security.

	== Problem Description ==		== Problem Description ==
Line 7:		Line 7:

	=== Current Usage ===		=== Current Usage ===

	Some links to software download pages featuring hashes:		Some links to software download pages featuring hashes:
	* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]		* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]
Line 26:		Line 27:
	Additionally, the failure case needs to be considered; if we use hashes for security and the hashes don't match, how should this affect the page load?		Additionally, the failure case needs to be considered; if we use hashes for security and the hashes don't match, how should this affect the page load?

	Displaying a new type of error to users probably won't improve security; it'll just be another warning to click through. However, hashes COULD be used to improve the current security experience.		For downloads 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?''<br>[Delete File] [Keep in Quarantine]

			Displaying a new type of error to users for linked content (e.g., CSS, JS, SVG) probably won't improve security; it'll just be another warning to click through. However, hashes COULD be used to improve the current security experience.

	For example, a Web page served over a https:// URL could include hashes for links to assets with http:// URLs; if the hashes match, mixed content warnings might not need to be given.		For example, a Web page served over a https:// URL could include hashes for links to assets with http:// URLs; if the hashes match, mixed content warnings might not need to be given.
Line 41:		Line 46:

	== Proposed Solutions ==		== Proposed Solutions ==


	=== hash attribute ===		=== 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 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.

Line 50:		Line 57:

	==== Processing Model ====		==== 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.		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?"~~		For links to JS, CSS, etc., where HTML has been fetched over SSL/TLS, a matching hash means that the mixed content warning can be omitted. This might require substantial modification of the fetch to allow content to be downloaded before the policy decision is made.

	~~==== 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?''<br>[Delete File] [Keep in Quarantine]		(The processing model for all of the proposals is largely the same)

	~~==== 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 ===		=== Hash Microformat ===
Line 85:		Line 82:
	:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"		:"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~~ ====		=== Link Fingerprint ===
	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?''<br>[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.		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.

Line 109:		Line 93:
	The [http://www.gerv.net/security/link-fingerprints/ Link Fingerprints article] by Gervase Markham gives more details.		The [http://www.gerv.net/security/link-fingerprints/ 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?''<br>[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.

	=== HTTP Headers ===		=== HTTP Headers ===

Mnot: /* Content-MD5 HTTP Header */

2013-11-14T04:10:13Z

Content-MD5 HTTP Header

← Older revision		Revision as of 04:10, 14 November 2013
Line 127:		Line 127:
	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.		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~~ ===		=== HTTP Headers ===
	~~It has been suggested to use~~ the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. ~~A tampered file~~ on a ~~hacked~~ server ~~is very likely to get its digest updated accordingly however~~.
			HTTP defines the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. However, MD5 has known security flaws, and is not recommended for use.

			The [http://tools.ietf.org/html/rfc3230#section-4.3.2 Digest] HTTP header avoids this by allowing the hash algorithm to be specified.

			Both of these approaches are on the response itself, rather than in '''links''' -- so they're only able to indicate the integrity of the response they occur within, and are naturally vulnerable to modification in transit and on the server.

			Another approach would be using [http://tools.ietf.org/html/rfc5988 Link headers] to indicate hashes for the links in content; this could be useful if you want to add hashes with a server plug-in or a reverse proxy, for example.

	== Mailing List References ==		== Mailing List References ==

Mnot: /* Current Usage */

2013-11-14T03:59:54Z

Current Usage

← Older revision		Revision as of 03:59, 14 November 2013
Line 11:		Line 11:
	* [http://www.php.net/downloads.php PHP Downloads]		* [http://www.php.net/downloads.php PHP Downloads]
	* Apache: [http://httpd.apache.org/download.cgi HTTP Server]		* Apache: [http://httpd.apache.org/download.cgi HTTP Server]

			Hashes on links are used in [http://tools.ietf.org/html/rfc6249#section-6 Metalink], which is implemented by a number of software download products.

	Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.		Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.

Mnot: /* Benefits */

2013-11-14T03:56:10Z

Benefits

← Older revision		Revision as of 03:56, 14 November 2013
Line 17:		Line 17:

	There are a few use cases for link hashes.		There are a few use cases for link hashes.

			==== Integrity ====

	The most obvious is easier discoverability of tampered files which could come from a mirror server being hacked. However, the security improvement is limited to the security properties of how the links themselves are conveyed.		The most obvious is easier discoverability of tampered files which could come from a mirror server being hacked. However, the security improvement is limited to the security properties of how the links themselves are conveyed.
Line 25:		Line 27:

	For example, a Web page served over a https:// URL could include hashes for links to assets with http:// URLs; if the hashes match, mixed content warnings might not need to be given.		For example, a Web page served over a https:// URL could include hashes for links to assets with http:// URLs; if the hashes match, mixed content warnings might not need to be given.

			==== Caching ====

	Another use case is for caching. If a browser has a cached copy of jquery, for example, and a link has a hash that matches the cached copy, it could avoid a request, even if the URL is completely different. The collision resistance and other security properties would obviously need to be carefully specified here, but if the hash doesn't match, it isn't necessary to present the error to the user; you just fetch the URL as per normal.		Another use case is for caching. If a browser has a cached copy of jquery, for example, and a link has a hash that matches the cached copy, it could avoid a request, even if the URL is completely different. The collision resistance and other security properties would obviously need to be carefully specified here, but if the hash doesn't match, it isn't necessary to present the error to the user; you just fetch the URL as per normal.

Mnot: /* Benefits */

2013-11-14T03:48:47Z

Benefits

@@ Line 15: / Line 15: @@
 === Benefits ===
-Easier discoverability of tampered files which could come from a mirror server being hacked.
 == Proposed Solutions ==

Annevk: /* Mailing List References */

2011-01-26T12:11:20Z

Mailing List References

← Older revision		Revision as of 12:11, 26 January 2011
Line 113:		Line 113:
	* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006		* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

	[[Category:~~Feature Request~~]]		[[Category:Proposals]]

KornelLesinski: Undo revision 2486 by Special:Contributions/Usome (User talk:Usome)

2007-08-31T08:03:02Z

Undo revision 2486 by Special:Contributions/Usome (User talk:Usome)

← Older revision		Revision as of 08:03, 31 August 2007
Line 105:		Line 105:

	=== Content-MD5 HTTP Header ===		=== Content-MD5 HTTP Header ===
	It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5~~][http://www.usome.com~~] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.		It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

	== Mailing List References ==		== Mailing List References ==

Usome: /* Content-MD5 HTTP Header */

2007-08-31T06:20:40Z

Content-MD5 HTTP Header

← Older revision		Revision as of 06:20, 31 August 2007
Line 105:		Line 105:

	=== Content-MD5 HTTP Header ===		=== Content-MD5 HTTP Header ===
	It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.		It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5][http://www.usome.com] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

	== Mailing List References ==		== Mailing List References ==

Michel Fortin: Added to the Feature Request category.

2006-11-18T13:56:10Z

Added to the Feature Request category.

← Older revision		Revision as of 13:56, 18 November 2006
Line 112:		Line 112:
	* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006		* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
	* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006		* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

			[[Category:Feature Request]]