MozillaWiki

Security/Features/Content Hashing/Spec: Difference between revisions

< Security‎ | Features‎ | Content Hashing
(Created page with "=Specification= The content hashing mechanism aims at improving the browser caching performance and providing a means for website to enforce the integrity of their external reso...")
 
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:




== Use cases==
=Use cases=
 
== How to specify the element hash value ? ==
 
What is the best way to specify the element hash  ?
Potential candidates:
* adding a tag element : <img src="a.jpg" hash="yyyyyyyyyyy">
* Use a manifest file
* Use a header
 
= Technical issues =
 
== External elements update ==
 
How an external website can tell that the element request by the page was updated ?
 
== Loading failure reporting ==
 
How to report that an element failed to load because to the signature verification failed ?
Maybe using the SCP report mechanism ?
 
 
=Potential security issues=
 
== Second image collision attack ==
An attacker can potentially create a hash collision between a specially crafted file and a well known file if the hashing algorithm is weak.
MD5 must be avoided at all cost.
 
== Integrity ==
Using the hash as an integrity mechanism is tricky because it can be delivered over HTTP. In this case a Man in the Middle attack can be performed.
Communicate this limitations to user and developer is tricky. 
 
== Mime type confusion ==
 
There is a potential issue with element cached as a specific mime-type and then used as another type. The canonical example being the gifjar attack.
http://www.gnucitizen.org/blog/java-jar-attacks-and-features/
 
 
= Previous work =
 
Previous work on the subject:
 
* http://wiki.whatwg.org/wiki/Link_Hashes
* http://www.gerv.net/security/link-fingerprints/
 
== Related RFCS ==
 
 
* RFC 2803 - Digest Values for DOM (DOMHASH) http://tools.ietf.org/html/rfc2803 draft-hiroshi-dom-hash-00 http://tools.ietf.org/html/draft-hiroshi-dom-hash-00
* RFC 3972 - Cryptographically Generated Addresses (CGA) http://tools.ietf.org/html/rfc3972
* RFC 4982 - Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) http://tools.ietf.org/html/rfc4982
* RFC 4982 - Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) http://tools.ietf.org/html/rfc4982
* draft-ietf-csi-hash-threat-12 - SEND Hash Threat Analysis http://tools.ietf.org/html/draft-ietf-csi-hash-threat-12
* draft-thiemann-hash-urn-01 - A URN Namespace For Identifiers Based on Cryptographic Hashes http://tools.ietf.org/html/draft-thiemann-hash-urn-01
* RFC 2938 - Identifying Composite Media Features http://tools.ietf.org/html/rfc2938
* draft-bryan-ftp-hash-08 - File Transfer Protocol HASH Command for Cryptographic Hashes http://tools.ietf.org/html/draft-bryan-ftp-hash-08
* draft-ietf-ftpext2-hash-00 - File Transfer Protocol HASH Command for Cryptographic Hashes http://tools.ietf.org/html/draft-ietf-ftpext2-hash-00
* draft-eaton-oauth-bodyhash-00 - OAuth Request Body Hash http://tools.ietf.org/html/draft-eaton-oauth-bodyhash-00
* draft-arkko-mipv6-select-hash-00 - Selection of MIPv6 Security Level Using a Hashed Address http://tools.ietf.org/html/draft-arkko-mipv6-select-hash-00
* draft-irtf-cfrg-rhash-01 - Strengthening Digital Signatures via Randomized Hashing http://tools.ietf.org/html/draft-irtf-cfrg-rhash-01

Latest revision as of 22:23, 15 July 2011

Specification

The content hashing mechanism aims at improving the browser caching performance and providing a means for website to enforce the integrity of their external resources.


Use cases

How to specify the element hash value ?

What is the best way to specify the element hash  ? Potential candidates:

  • adding a tag element : <img src="a.jpg" hash="yyyyyyyyyyy">
  • Use a manifest file
  • Use a header

Technical issues

External elements update

How an external website can tell that the element request by the page was updated ?

Loading failure reporting

How to report that an element failed to load because to the signature verification failed ? Maybe using the SCP report mechanism ?


Potential security issues

Second image collision attack

An attacker can potentially create a hash collision between a specially crafted file and a well known file if the hashing algorithm is weak. MD5 must be avoided at all cost.

Integrity

Using the hash as an integrity mechanism is tricky because it can be delivered over HTTP. In this case a Man in the Middle attack can be performed. Communicate this limitations to user and developer is tricky.

Mime type confusion

There is a potential issue with element cached as a specific mime-type and then used as another type. The canonical example being the gifjar attack. http://www.gnucitizen.org/blog/java-jar-attacks-and-features/


Previous work

Previous work on the subject:

Related RFCS

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Features/Content_Hashing/Spec&oldid=330245"