Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subresource Integrity

githubengineering.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Subresource Integrity

#41

Post by Animats »

It's nice that Github, Inc. likes subresource integrity. Did they put it on their web pages? As of right now, it doesn't seem to be on their home page. The next big step is for Wordpress to support it.

Subresource integrity is in some ways more important than "HTTPS Everywhere", because the MITM-as-a-service sites such as Cloudflare subvert HTTPS Everywhere. For security reasons, you might choose to serve your home page and a few security-critical pages from your own server, without using a CDN. But run everything else through the CDN, using subresource integrity to keep the CDN honest.

With subresource integrity, many items no longer need to be encrypted. This is good for security. Encryption interferes with caching, and HTTPS in front of caches means that the attack surface is larger, and includes the CDN.

(Yes, there's an argument that HTTPS conceals what the user was browsing. Not really. Checking document length will provide a good hint on what static asset was read. The pattern of document lengths requested tends to fingerprint the page being read.)

Re: Subresource Integrity

#42

Post by toomuchtodo »

zupa-hu wrote: post #16
bosdev wrote: post #10

I really wish browsers could leverage this for caching across origins. If my copy of jQuery has the same SHA256 as another file the user has already downloaded, there's no need to load it again

ahahah and slowly bittorrent takes over http :D

We've been on our way for a while now with IPFS.

https://ipfs.io/

Re: Subresource Integrity

#43

Post by detaro »

iancarroll wrote: post #38
ryan-c wrote: post #28

Earlier quoted context omitted.

This is to prevent files on a 3rd party CDN from being loaded if they've been replaced with malicious ones.

Ah, I see. I misunderstood. Though signatures seem to be just adding another part in the deployment process where you update the files themselves as well as the pages they're loaded from. Is there any security gain from doing that?

If you include content produced by a third party (e.g. JQuery) off a CDN, right now you can use the hash-based SRI mechanism to make sure that only the exact file you specified can be included, otherwise the CDN could suddenly send any compromised code. The file can't be changed, because otherwise the hash wouldn't match.

With a signature, you could specify "include cdn.com/jquery-X if signed by the JQuery project", so JQuery could publish security updates and those could be rolled out to the CDNs and included in all pages automatically, without the siteowners having to make changes (if the security fix doesn't break compatibility).

For your own content, you'd mostly gain the convenience of not having to update the hashes on all the pages including the resource.

Re: Subresource Integrity

#44

Post by gellerb »

Animats wrote: post #41

It's nice that Github, Inc. likes subresource integrity. Did they put it on their web pages? As of right now, it doesn't seem to be on their home page. The next big step is for Wordpress to support it. Subresource integrity is in some ways more important than "HTTPS Everywhere", because the MITM-as-a-service sites such as Cloudflare subvert HTTPS Everywhere. For security reasons, you might choose to serve your home p…

Login and inspect the home page afterwards. http://imgur.com/bwUHgcT

Re: Subresource Integrity

#45

Post by Animats »

gellerb wrote: post #44
Animats wrote: post #41

It's nice that Github, Inc. likes subresource integrity. Did they put it on their web pages? As of right now, it doesn't seem to be on their home page. The next big step is for Wordpress to support it. Subresource integrity is in some ways more important than "HTTPS Everywhere", because the MITM-as-a-service sites such as Cloudflare subvert HTTPS Everywhere. For security reasons, you might choose to serve your home p…

Login and inspect the home page afterwards. http://imgur.com/bwUHgcT

I'm logged in. Not seeing it. Maybe it's not deployed for all accounts yet.

Re: Subresource Integrity

#46

Post by mastahyeti »

Animats wrote: post #45
gellerb wrote: post #44

Earlier quoted context omitted.

Login and inspect the home page afterwards. http://imgur.com/bwUHgcT

I'm logged in. Not seeing it. Maybe it's not deployed for all accounts yet.

It's only included for browsers that support it. That's Chrome>45 and Firefox>43.

Re: Subresource Integrity

#47

Post by jsprogrammer »

detaro wrote: post #40
jsprogrammer wrote: post #37

Earlier quoted context omitted.

It's just a semantic question. Does a URL point to a specific version of a resource or does it point to whatever the server considers to be the resource at a given time. It would seem more desirable to be able to point to a specific version, instead of allowing a third party to be able to insert implicitly trusted code without acknowledgement.

But if you need to sign updates, a third party CAN'T insert new code without it going through the site owner or a trusted party (e.g. new jQuery versions signed by the jQuery project). And it would seem desirable to be able to roll out a security fix without having to touch every single page that includes it (and the potential cache issues discussed above)

You can create similar semantics. The only difference is in who controls what code goes to your users.

I'd consider jQuery a third party. If only signatures are checked (and not content), then trusted third parties can push whatever code they'd like to your users.

Re: Subresource Integrity

#48

Post by infinity0 »

detaro wrote: post #43
iancarroll wrote: post #38

Earlier quoted context omitted.

Ah, I see. I misunderstood. Though signatures seem to be just adding another part in the deployment process where you update the files themselves as well as the pages they're loaded from. Is there any security gain from doing that?

If you include content produced by a third party (e.g. JQuery) off a CDN, right now you can use the hash-based SRI mechanism to make sure that only the exact file you specified can be included, otherwise the CDN could suddenly send any compromised code. The file can't be changed, because otherwise the hash wouldn't match. With a signature, you could specify "include cdn.com/jquery-X if signed by the JQuery project",…

This is more convenient but less secure than a straight-up hash. If an attacker compromises the JQuery signing key, they could still serve malicious files. With a hash, the authenticity is ONLY dependant on the TLS connection to the main website, e.g. github.

TL;DR:

* hash: need to compromise the main website, that supplies (and authenticates) the hash

* signature by CDN: attacker can either compromise the main website OR the third party CDN author/signer of the third-party resource

(edit: correction as pointed out by response)

Re: Subresource Integrity

#49

Post by zeveb »

bsimpson wrote: post #7

What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.) To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for…

> What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page.

Only if your page requires JavaScript to function and doesn't gracefully degrade. None of us would ever write that sort of page, would we?

Re: Subresource Integrity

#50

Post by detaro »

infinity0 wrote: post #48
detaro wrote: post #43

Earlier quoted context omitted.

If you include content produced by a third party (e.g. JQuery) off a CDN, right now you can use the hash-based SRI mechanism to make sure that only the exact file you specified can be included, otherwise the CDN could suddenly send any compromised code. The file can't be changed, because otherwise the hash wouldn't match. With a signature, you could specify "include cdn.com/jquery-X if signed by the JQuery project",…

This is more convenient but less secure than a straight-up hash. If an attacker compromises the JQuery signing key, they could still serve malicious files. With a hash, the authenticity is ONLY dependant on the TLS connection to the main website, e.g. github. TL;DR: * hash: need to compromise the main website, that supplies (and authenticates) the hash * signature by CDN: attacker can either compromise the main websi…

It would still help against compromise of the CDN, but not against compromise of the original source.

Of course it's a trade off. For stuff like Google Fonts, the Facebook like button etc I'd expect that hashes won't become common, because the effort of publishing changed hashes and embedding them into sites is to big.

Post reply on HN