The design fails to make a secure guarantee

[douglasheld]

As noted in section 5.1, the design makes no claim to guarantee integrity of the payload. Therefore, the only utility of the design is to indicate when an accidental modification of the content has occurred. That, to me is a dubious value.

But with a change to the specification, the design could provide a security guarantee. Instead of a plain old SHA384 digest, the design could provide a digital signature, for example an HMAC signed by the HTTP server's associated HTTPS private key, or another pre-shared asymmetric key pair.

Example Use Case:

1. Alice is the distributor of example.js and the holder of domain example.com.
2. Alice publishes a TXT record in DNS such as _integrity.example.com = "30 82 01 0a 02 82 01 01 00..." (an RSA public key or GPG public key)
3. When Alice releases example.1.0.js, she also publishes a detached digital signature, for example a GPG signature "89 01 b3 04 00 01 0a 00..." for the file.
4. Carol publishes an unencrypted website that imports example.1.0.js and she wishes to provide end users with a guarantee of authenticity for the 3rd party content. She calculates (in this case a GPG) signed digital signature and publishes the string together with the release.
5. Bob runs a web browser configured to run only verified scripts, and requests Carol's website. His web browser reads <script src="http://example.com/example.1.0.js" integrity="gpg 89 01 b3 04 00 01 0a 00..." >...</script>. The browser then executes the script, conditionally on the verification of the author Alice and the content.

Abuse cases:

• A1. Alice makes a new release with malware in it. (Step 1) The design offers no mitigation.
• A2. Attacker Eve takes control of example.com DNS. Eve can overwrite the public key - in which case Bob's browser will fail the verification and will not run the legitimate content (Step 5).
• A3. Eve takes control of example.com website traffic. Eve can modify the JavaScript release or the digital signature. Bob's browser will fail the verification and will not run the malicious content (Step 5).
• A4. Eve takes control of Alice's DNS, website traffic and the private key. Eve can now impersonate Alice and attack Bob (Step 5).
• A5. Eve takes control of Carol's website traffic (or Bob's receipt of that traffic). Eve can now attack the user Bob, but not through modification of the example.js script tag.
• A6. Eve convinces Bob to disable protective configuration in his web browser. She can now attack Bob through A2 or A3.

[mozfreddyb]

Hi Douglas,

Your comment left me a tiny bit confused. Let me try to paraphrase and answer bit by bit, so we can arrive at a state of shared understanding. 1) accidental modification: I don't agree with this completely. Assuming that the subresource protected by SRI is hosted on another origin (and by another party) than the main resource, the benefit of SRI is that you no longer have to trust the other party to not modify the file to your detriment.

This scenario is, of course, weakened if the main document is served from a non-secure context. In which case, all bets are off - regardless of whether SRI is being used. You were linking to Section 5.1 which briefly talks about HTTP hosted resources. This section aligns with the global push for more HTTPS. We do want all websites to enjoy the confidentiality, authenticity and integrity protection from HTTPS.

2) Signatures: The proposal you make is a bit confusing, as you also introduced a serialization format for binary data that differs from the one we currently use in integrity metadata (i.e., base64).

Google Chrome is experimenting with signatures in SRI according to @mikewest's Explainer doc. It looks to me as if this was a better forum (if there is any) to discuss baking signature support into SRI. Lastly, I also want to note that my employer, Mozilla, has looked into it and is not wiling to support that use case yet.

[dveditz]

There's broad interest in signed content for use in many contexts where SRI isn't defined or appropriate. The IETF has had a stab at such a definition several times in the past e.g. https://web-payments.org/specs/ED/http-signatures/2014-05-08/ https://tools.ietf.org/html/draft-thomson-http-content-signature-00

and is currently entertaining https://datatracker.ietf.org/doc/html/draft-yasskin-http-origin-signed-responses

Rather than shoehorn content signatures into SRI it seems better to let those attempts play out. Once we have a general mechanism we can work out a way at the Web Application layer to assert that resources must be signed.

[dveditz]

Bob runs a web browser configured to run only verified scripts, and requests Carol's website. His web browser reads . The browser then executes the script, conditionally on the verification of the author Alice and the content.

The specifications produced by the Web Application Security WG are largely aimed at helping Carol describe the security properties of the intended content. They are not meant to protect Bob from Carol who can, after all, simply not use them. They help Carol protect Bob from people who might try to tamper with Carol's intended content. They all assume secure transport to have any real effectiveness which is why we've spent time defining things like Mixed Content Blocking, Upgrade Insecure Request, HSTS (in the IETF, not WASWG), the Secure Contexts spec and restricting new web features to those contexts. In addition many member companies are pushing hard to convince sites to switch to secure transport through things like changes to UI treatments in browsers, search engines demoting insecure content, and donating to the Internet Security Research Group (https://letsencrypt.org/isrg/) to reduce financial barriers to running secure sites.