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

71–78 of 78 posts

Re: Subresource Integrity

#71

Post by jsprogrammer »

geofft wrote: post #53
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.

You're separating which third party can do that, which is useful. I don't think it's at all unusual or wrong for me to decide that, if I'm using minified jQuery, I trust the jQuery project signing key, but I don't really trust whatever CDN I'm using (or that I want the freedom to choose a CDN solely for technical performance and not for security infrastructure). If that's not convincing, consider the case where it's…

That is all fine and it would cover many cases. However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key).

If you are already using a CDN, put your updated manifest (index.html) there as well.

Re: Subresource Integrity

#72

Post by geofft »

jsprogrammer wrote: post #71
geofft wrote: post #53

Earlier quoted context omitted.

You're separating which third party can do that, which is useful. I don't think it's at all unusual or wrong for me to decide that, if I'm using minified jQuery, I trust the jQuery project signing key, but I don't really trust whatever CDN I'm using (or that I want the freedom to choose a CDN solely for technical performance and not for security infrastructure). If that's not convincing, consider the case where it's…

That is all fine and it would cover many cases. However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key). If you are already using a CDN, put your updated manifest (index.html) there as well.

> However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key).

Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party."

> If you are already using a CDN, put your updated manifest (index.html) there as well.

I'm not sure how this helps. Wouldn't this leave the index.html in the hands of the CDN, such that they are free to modify it?

Re: Subresource Integrity

#73

Post by jsprogrammer »

geofft wrote: post #72
jsprogrammer wrote: post #71

Earlier quoted context omitted.

That is all fine and it would cover many cases. However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key). If you are already using a CDN, put your updated manifest (index.html) there as well.

> However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key). Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party." > If you are already using a CDN, put your updated manifest (index.html) there as well. I'm not sure how this helps. Wouldn't…

>Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party."

I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys)

>I'm not sure how this helps. Wouldn't this leave the index.html in the hands of the CDN, such that they are free to modify it?

I think you are right, as the system currently works index.html would not be safe. Currently you need a more dynamic system where the manifest is protected as well. A sidechannel (WebSockets, WebRTC) could be established to securely deliver updated manifests (which a lightweight client would translate into DOM operations).

Re: Subresource Integrity

#74

Post by geofft »

jsprogrammer wrote: post #73
geofft wrote: post #72

Earlier quoted context omitted.

> However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key). Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party." > If you are already using a CDN, put your updated manifest (index.html) there as well. I'm not sure how this helps. Wouldn't…

>Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party." I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys) >I'm not sure how this helps. Wouldn't this leave…

> I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys)

I'm not capable of running a CDN myself. So I have to trust someone. I might as well minimize the number of potential someones I trust; I claim that gives me a concrete benefit.

Since I'm not writing jQuery myself, I'm not minimizing it myself, and I'm certainly not minimizing it by hand, I do already have some trust in the jQuery project and their infrastructure. I don't currently have any trust in a CDN. If I'm going to move to using a CDN, I'd like a route with lets me put slightly more trust in the jQuery project (who I already trust to some extent) than in some completely new party.

Alternatively, I don't have to trust jQuery. I can trust someone else who's good at running secure build infrastructure, auditing libraries like jQuery or anything else, and minimizing and signing the result. (This is, loosely, analogous to the role that a Linux distribution plays.) Then I can choose to trust these people or not based solely on how good they are at security, choose my library authors based solely on how good they are at writing libraries, and choose my CDN based solely at how good they are at distributing content. I don't have to conflate the security trust with anyone other than the people I intentionally choose to put security trust in.

Re: Subresource Integrity

#75

Post by infinity0 »

morgante wrote: post #70
infinity0 wrote: post #48

Earlier quoted context omitted.

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…

Yes, it's nominally less secure but I trust the authors of major scripts (ex. the Facebook like button) to be able to keep their keys secure. If losing private keys is a major security concern, then TLS is also useless.

It's not "nominal"; losing private keys is a major security concern. No, "TLS is useless" does not follow from that - we have things like forward secrecy which are security models specifically designed to give some protection in the case of private key compromise.

(edit: e.g. see https://en.greatfire.org/blog/2015/sep/popular-chinese-ios-a... just out today)

Especially in the case of a library developer, they hold the keys to many websites, so there is extra incentive for an attacker to break that rather than "some random guy's website". The more third-party signers you trust, the more holes you (and your users) have.

Furthermore, you are forcing your users (who actually run this code) to place their trust in these parties too, which is not a great thing (transitive trust) to force upon someone. (This is not the case for e.g. depending on system libraries explicitly installed by the user.)

Re: Subresource Integrity

#76

Post by duskwuff »

ihsw wrote: post #23
skrebbel wrote: post #18

Earlier quoted context omitted.

How is that dangerous?

It leaks private user info -- a malicious server could include a JS file confirmed to be highly sensitive/top secret, and measure whether the client already has that cached. If so then the user is confirmed a sensitive target.

No, there's a worse attack possible: you can attempt to include a resource with sensitive contents with SRI, and use the SRI to make a "guess" at the hash of the contents. If your guess is incorrect, the resource will fail to load, and you can detect this error and make another guess.

Obviously, this technique will only work if the contents of that resource are constrained enough that it's possible to guess them with brute force. Depending on how SRI interacts with the browser cache, though, it may be possible to make guesses very quickly -- it is likely that the browser will only fire one HTTP request for the initial attempt, and will load the resource from cache for all subsequent attempts.

Re: Subresource Integrity

#77

Post by knweiss »

The next step: A distributed, content-addressed caching system that allows the web browser to fetch the data from the fastest/nearest caching server by hash.

IPFS comes to mind.

Re: Subresource Integrity

#78

Post by jsprogrammer »

geofft wrote: post #74
jsprogrammer wrote: post #73

Earlier quoted context omitted.

>Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party." I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys) >I'm not sure how this helps. Wouldn't this leave…

> I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys) I'm not capable of running a CDN myself. So I have to trust someone . I might as well minimize the number of potential someones I trust; I claim that gives me a concrete benefit. Since I'm not…

Reducing the number of someones you trust is good. I think the only difference in our approach is what others are trusted to do. In your model, some are trusted to send new code to users. In my model, new code must be acknowledged first, before users can consume it.

I don't think one approach is necessarily worse, but one can provide all of the essential functions of the other, without allowing unseen code to be pushed to users.

Post reply on HN