Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review of signature-based resource loading restrictions. #186

Closed
mikewest opened this issue Aug 10, 2017 · 16 comments

Comments

Projects
None yet
8 participants
@mikewest
Copy link

commented Aug 10, 2017

Hello TAG!

I'm requesting a TAG review of:

Further details (optional):

Relevant time constraints or deadlines: Q4ish?

You should also know that...

There's a discussion starting at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html that's quite relevant. @sleevi's comments at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0004.html are particularly intriguing.

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]
@hadleybeeman

This comment has been minimized.

Copy link

commented Sep 27, 2017

Taken up at our Nice face-to-face.

Thanks for this, @mikewest! As always, you've spawned a deep and intensive conversation in the TAG. :)

We appreciate the use cases you're trying to address here and aren't aware of any other way of solving them. This seems like a sensible way to make it happen.

We've had some debate about the role of CDNs and how the trust model works... Specific questions will be forthcoming. But generally, we are in favour of this.

@triblondon

This comment has been minimized.

Copy link

commented Sep 27, 2017

@mikewest thanks for this, it's very interesting. Speaking as a CDN person, I'm anticipating that CDNs will want to provide this as a service to their customers, ie the customer shares their private key with us and we add the signature into the <script> tags, and add the Integrity header to the appropriate asset responses (or in the case of serving just the script asset, eg cdnjs, do just that half)

Anticipating that this might inspire a SHARINGPRIVATEKEYSWHATTHEHELL freakout, note that CDNs already terminate TLS on behalf of their customers, and also sometimes will validate their customers' user-authentication tokens as well. It seems not unreasonable to anticipate that they might naturally do this too.

This also prompted the thought that any middlebox that can see the content in the clear (eg a corporate proxy which has a root cert trusted by its employees machines) and is able to intercept both the page request and the asset request could modify both to ensure a valid match on the client.

We think this basically wraps up our TAG feedback, would like to express our undying adulation for your glorious specification abilities and thank you for flying TAG. Please come again.

@plinss

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

Presumably multiple signature headers would be valid, should the provider want to sign with multiple private keys (during key rollover or such), or if a CDN wants to cross-sign with their own key. Is there potentially a use for multiple public keys on the consumer end? (so for example allowing signed content from one of multiple providers.)

I also have concerns about the distribution of the public keys, we have the general problem of MITM attackers fooling consumers into using the wrong key. I appreciate that this is trying to be a simple solution, but wonder if we're not going to have to go to a full certificate solution eventually anyway, and maybe we should just bite that off now.

@cynthia

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

@triblondon There is no added value of having the CDN sign in your behalf, at the point everything can be injected/rewritten from the CDN this use case would probably be better covered by the CDNs simply issuing a new key pair for this functionality. The key doesn't have any authority or meaning to the end users, so there isn't much of a point in sharing the key.

@triblondon

This comment has been minimized.

Copy link

commented Sep 27, 2017

Oh, one other thought - is there any impact of the scout pattern of loading JavaScript libraries:
https://alexsexton.com/blog/2013/03/deploying-javascript-applications/

@mikewest

This comment has been minimized.

Copy link
Author

commented Sep 27, 2017

@triblondon:

I'm anticipating that CDNs will want to provide this as a service to their customers

CDN-provided services are basically SRI's threat model. :) One goal is to ensure that a page loads the bits that its owner uploaded to the CDN, unmodified (https://w3c.github.io/webappsec-subresource-integrity/#resource-integrity). It's actually meant to reduce the necessity to hand over the keys to your kingdom to the CDN.

The use cases I'm personally interested in involve a creator holding a private key offline, using it at build-time to sign resources, then taking it offline again until the next build. Signing content dynamically on the server seems to substantially reduce the guarantees the signature provides. I'm sure there are valid use cases for that kind of setup, but, again, it's not the use case we're targeting.

I look forward to chatting with y'all about it tomorrow. :)

@cynthia

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

Signing content dynamically on the server seems to substantially reduce the guarantees the signature provides. I'm sure there are valid use cases for that kind of setup, but, again, it's not the use case we're targeting.

I believe if you have a CI that automates building and deploying to a staging server that is a exact replica of the production, and you take the built package straight to production if everything works in staging, you would want your CI server to sign it for simplified deployment. (given that the CI server has decent policies blocking private key access, this probably is not too likely to happen in the real world though.)

@otherdaniel

This comment has been minimized.

Copy link

commented Sep 27, 2017

@triblondon @cynthia I think you all are actually agreeing, but just wanted to add that a CDN could certainly do its job without knowledge of the private key. However, knowing the private key would allow a 'value add' CDN that e.g. also minifies, compresses, assembles, or elsehow prepares resources on behalf of a client. The proposed spec enables either use case.

The uses cases can even be mixed within the page, on a resource-by-resource basis. (E.g., CDN provides and holds the key for certain standard libraries, like the most up-to-date jQuery; while the page owner holds the key for the app logic.)

Basically, the last thing that is meant to legitimately modify the sub-resource data needs to hold the key. The spec has no opinion on who that should be.

That said, the only-page-owner-holds-the-key use case is certainly an important one.

@hadleybeeman

This comment has been minimized.

Copy link

commented Nov 7, 2017

Discussed at TPAC 2017 in Burlingame, especially the trust model: is the CDN potentially the adversary, or are developers asking for them to trusted to deliver resources on their behalf? I was curious if CDNs were unhappy with this proposal, if it fundamentally changed their role with regard to their customers.

@mikewest explained that, because the private key can be stored offline and the signature generated at build time (under the developer's control) OR can be stored on the server (presumably under the CDN's control) — either trust model is possible within this proposal.

@triblondon

This comment has been minimized.

Copy link

commented Jan 31, 2018

Discussed at London F2F. Two issues seem to remain:

  1. @plinss is concerned that without using certs, there's too much of a risk of fraudulent public keys allowing attackers to compromise an SRI protected resource.
  2. We'd like to ensure that it's possible to send multiple signatures on a single, so you can do key rollover

Pinging @mikewest.

@triblondon triblondon modified the milestones: tag-f2f-nice-2017, tag-telcon-2018-02-20 Jan 31, 2018

@annevk

This comment has been minimized.

Copy link
Member

commented Jan 31, 2018

FWIW, https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0074.html is a pretty compelling argument against this feature. (Sorry, wrong issue.)

@mikewest

This comment has been minimized.

Copy link
Author

commented Feb 1, 2018

@plinss is concerned that without using certs, there's too much of a risk of fraudulent public keys allowing attackers to compromise an SRI protected resource.

As we discussed earlier, using certs seems like a thing that's possible to do. It's the core of https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html, really. I'm really unenthusiastic about reinventing the web PKI, however, and am much more interested in the Simplest Thing That Could Possibly Work(tm) approach we're taking here.

I'm not at all clear about the risks that @plinss is referring to, and they aren't clear from the minutes either. ed25519 is a fairly robust signature mechanism: what "fraudulent public key" risks am I missing?

We'd like to ensure that it's possible to send multiple signatures on a single, so you can do key rollover

That seems reasonable to add. The client-side already supports verification via multiple public keys, so adding it to the server side seems like a thing we could do. It's not clear to me that it's necessary for use cases I know about, but it's not an unreasonable feature.

@plinss

This comment has been minimized.

Copy link
Member

commented Feb 1, 2018

I'm not at all clear about the risks that @plinss is referring to, and they aren't clear from the minutes either. ed25519 is a fairly robust signature mechanism: what "fraudulent public key" risks am I missing?

My concern is that the end user has to know the public key of the resource signer via some form of out of band communication. A bad actor serving a compromised version of the content can also present their own public key and claim it's the original author's key. Users will get confused. Not that certs completely solve this problem, but at least they provide a known mechanism to associate a public key with a form of identity.

I appreciate the STTCPW(tm) approach, I just worry that if the system is too easy to compromise (or the lack of authentication actually causes more confusion in practice) that it will be as much of a barrier to uptake as a more complicated, but more robust solution.

@mikewest

This comment has been minimized.

Copy link
Author

commented Feb 1, 2018

Hey, @plinss! Thanks again for the feedback!

Let me first point again to https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html, which aims to offer the ability to sign things with certificates. That has real use cases, and it's something y'all should give feedback on (especially given Mozilla's apparent disapproval). That mechanism could indeed serve as the basis for a client-side assertion that a resource was signed in such a way that it chains back up to some trusted root, and if it takes off, I could certainly imagine adding some sort of client-side assertion regarding its presence. There are some real complexities there with asserting a particular public key given the weirdness that is path-building and cross-signing and etc, but I'm sure we could work something out.

That said, I have a few thoughts about the threat you're concerned with preventing:

  1. It seems non-unique to this mechanism. That is, the bad actor can put up a malicious copy of jQuery today, along with a hash that would verify that malicious copy: developers who trust the bad actor could certainly be tricked into asking the browser to intensely verify that they're loading the bad actor's code, which would indeed end up executing the bad actor's code on their pages.

    It doesn't appear to me that moving from a hash to a signature makes the problem any worse. In fact, I'd claim the opposite, as the bad actor would have significantly more opportunity to feed a bad hash to a developer since the hash by definition must change every time the resource changes. It seems that signatures might be longer-lived, and therefore less-frequently updated, reducing the opportunity for maliciousness.

  2. The use cases I know about are not actually related to third-party content at all. There might be some marginal value there, but my focus is on first-party content (or third-party content that's audited and part of a deployment process that stamps it with the first-party key). I'm not actually enthusiastic about the third-party use cases (some of the reasons for which are outlined in the discussion with @sleevi in the thread I linked back at the beginning of this review).

My concern is that the end user has to know the public key of the resource signer via some
form of out of band communication.

That's true of certs as well, isn't it? The root certs for the web PKI are distributed either with your OS or your browser, and are trusted accordingly.

@torgo torgo assigned plinss and unassigned triblondon Feb 21, 2018

@torgo torgo removed this from the 2018-02-21-telcon milestone Feb 21, 2018

@plinss plinss modified the milestones: 2018-03-06-telcon, 2018-03-14-telcon Mar 5, 2018

@torgo

This comment has been minimized.

Copy link
Member

commented Mar 13, 2018

@plinss to write feedback

@plinss

This comment has been minimized.

Copy link
Member

commented Apr 7, 2018

Hey Mike,

We agree that this is an improvement over a simple hash, and are happy to see this move forward. As noted above, we'd like to see the ability to have multiple keys and signatures on a single resource to allow key rollover and cross-signing.

There is the one increased risk over a hash in that if an attacker gets a victim to accept a fraudulent key, they can continue to sign new versions of the resource without having to update the key (for example, publish a legit version of a library with a fraudulent key/signature, then after a while, replace the library with a malicious copy using the same key and the victim would likely not notice).

I do think that at some point we'll want a more powerful solution including key revocation and ownership proof, such as a certificate based solution, but I'm happy to wait for a future version and implementation experience with signed exchanges before going there.

@plinss plinss closed this Apr 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.