Redirect behavior?

[mikewest]

Copy/pasting from #44:

@martinthomson:

OK, let me try again. I don't like the idea that @path is involved, but I don't see a way around it. The problem with @path is that you need to establish some sort of expectation, which means that you just eliminated 302 and friends as tools that a server can use. Unless you want to allow signing of redirects...

This is a really good point, thanks for bringing it up. I'd been assuming that @path would refer to the initial URL that was requested (which would prevent redirects along with substitutions of the response body), but now it's not actually clear to me whether that's right. Is "the request target" the request's URL or current URL in Fetch's parlance?

If the latter, I need to think more about reasonable behavior for each intermediate hop. Signing them isn't crazy, though we'd likely want to require the content-location header? Hrm.

[martinthomson]

HTTP signatures deal with a single exchange, so you wouldn't be able to bind to a pre-redirect URL (which might be on a different host even).

In Fetch parlance, "request target" and "current URL" are the two equivalent concepts.

I don't think that you can rely on origin servers changing a whole lot and "content-location" isn't always available -- or even the right concept -- for a redirect.

My conclusion was that redirects are probably out if you want to include the URL under signature. At least if you want to avoid the sorts of resource swapping that is involved here.

(An idea for a remedy for those swapping attacks is to have requests include a Sec-Nonce field that is signed in the response, but that totally ruins caching. There are no easy answers.)

[mikewest]

HTTP signatures deal with a single exchange, so you wouldn't be able to bind to a pre-redirect URL (which might be on a different host even).

In Fetch parlance, "request target" and "current URL" are the two equivalent concepts.

Got it, thanks for the clarification.

I don't think that you can rely on origin servers changing a whole lot and "content-location" isn't always available -- or even the right concept -- for a redirect.

My conclusion was that redirects are probably out if you want to include the URL under signature. At least if you want to avoid the sorts of resource swapping that is involved here.

Indeed, I should have written location (e.g. the server signs the location header along with the current @path as a way of stamping the redirect response, the client verifies the signature before following (and presumably ensures that the entire chain is signed with an acceptable signature if the client has integrity requirements on the request)).

Or we can just punt on redirect responses for any response that includes @path, on the assumption that the server is telling us that the location from which the resource was served is, in fact, important. I think this is your suggestion above.

I'm not sure which of these options is the least complex. They both seem somewhat unfortunate. :)

cc @punkeel, who expressed interest in @path as mitigation for part of Cloudflare's threat model and who might have opinions here.

(An idea for a remedy for those swapping attacks is to have requests include a Sec-Nonce field that is signed in the response, but that totally ruins caching. There are no easy answers.)

I'm planning to punt on nonces for the moment, but I agree that they could be a useful addition in the future (see #41).

[punkeel]

For the record: this directly impacts my use case; our <script> tag points to a redirect. We're also NOT going to use @path in the first few iterations, to keep things simpler, then revisit.

No strong opinions, just a few thoughts:

(A)
The accept-signature header must be sent with all requests. The user-agent can't tell what request will return the content, and the server(s) need to know when to serve the signatures (and "which ones", potentially). Is this something the RFC should clarify?

(B)

I'd been assuming that @path would refer to the initial URL that was requested

This creates two weird "problems":

1. The server needs to know what path to include in the signature. This isn't part of the request/response itself, and would have to be based on "human knowledge"? Like, in my case, I know my script is api.js even if I redirect to api-9847389789fd7897.js.
2. An attacker could control the path in the <script> tag. I can't think of a scenario where this really matters (the server is happy to serve that script+signature already). I think this is what is mentioned in a previous comment.

(C)
Subresource Integrity today is only concerned about the content, not how it gets there it. Signing the intermediate hops feels weird from that perspective?

(D)
I never heard about content-location before, but that doesn't seem that useful here? It looks like it's about content negotiation, not redirects. Naming is hard!

(E)
Just as a data point, not argument: some origin servers redirect to a "dynamic URL", sometimes based on the incoming request. For example, /script.js?abc=def would redirect to /script-v1.2.js?abc=def. This may complicate signatures.

We, for one, used to do that, until we found "better" solutions. :)

(F)
NOT requiring signed hops, then requiring them is technically a breaking change. (#40)

[mikewest]

a) The accept-signature header can only be sent when the client asserts integrity metadata. In that case, it's reasonable to expect it to be sent to each server along the way, as the user agent can't know a priori whether the server will forward them on to another server or not.

b) These are valid implications of that understanding of how @path would work. Happily(?), that's not how it works: as Martin noted above, @path will be serialized with a value corresponding to the current request URL.

c) Generally, I think you're correct. Clients want a resource signed by a given key-holder, and as long as they get it, they're happy. That said, we've been talking about @path in the context of substitution attacks, in which some piece of content you've signed is substituted for some other piece of content you've signed. Assume you served good.js and bad.js and signed both: in the absence of redirects, @path allows the client to verify that the server thinks they're getting what they asked for. Signing redirects would be one way of allowing servers to say that the target of the redirect is indeed what the client asked for, even though the URL doesn't match.

d) Ignore content-location. It was just a typo on my part that's quite unrelated to this discussion. :) I meant location, as part of a redirect response.

e) That is exactly the scenario I'm interested in, in c) above. That's the "attack" @path could help mitigate.

f) I agree.

[martinthomson]

Another wrinkle to consider here. If you want to cover a redirect, the obvious thing to do is cover the request target/current request URL and then cover the status code and location field. But consider that the link might have specified a public key that is only available at the resource that it specified. If that resource needs to redirect, then it might be directing the request to a different origin, where there is no guarantee that the key is the same. Do you want to allow the redirect to specify a different signing key that is used to authenticate the next request?

[mikewest]

As @martinthomson points out, we're talking about two things above:

1. Can we sign redirects generally? That seems straightforward, as we've described: sign @status and location in the same way we sign everything else, and deliver a network error rather than a redirect on failure. This seems like a reasonable capability to add in any event, and should be a relatively small extension to the existing profile.

2. Should we require redirects to be signed with a matching key if a client requires a public key match? This is certainly possible, and would fairly robustly (in combination with signing @path) mitigate the risk that a compromised server hands out a response other than the one expected. We could easily implement this. The questions I have here is entirely practical: could deployments support this requirement, and should it be optional? Hopefully folks like @ddworken, @punkeel, and @yoavweiss can help us think through that from their perspectives.

[ddworken]

1. Can we sign redirects generally? That seems straightforward, as we've described: sign @status and location in the same way we sign everything else, and deliver a network error rather than a redirect on failure. This seems like a reasonable capability to add in any event, and should be a relatively small extension to the existing profile.

+1, this seems quite reasonable and like something that could be easy to include in the MVP.

2. Should we require redirects to be signed with a matching key if a client requires a public key match? This is certainly possible, and would fairly robustly (in combination with signing @path) mitigate the risk that a compromised server hands out a response other than the one expected. We could easily implement this. The questions I have here is entirely practical: could deployments support this requirement, and should it be optional? Hopefully folks like @ddworken, @punkeel, and @yoavweiss can help us think through that from their perspectives.

This requirement seems reasonable and should be doable as long as we continue to send Accept-Signature on those requests.

Though from a security POV, I'm wondering: Is it actually necessary to sign all the redirect hops? As I see it, Signature SRI aims to ensure that the initial response to a JS request isn't forged. If that initial response triggers loading of other JS (either via eval, script#src, or a redirect) it seems like it could be reasonable to say that is out-of-scope for Signature SRI. And that if you don't want the redirect to lead to loading other JS, you shouldn't sign the initial first hop of the redirect chain. I'm not entirely sure if this argument makes sense, but I'd be curious for other's thoughts on this. :)

[jyasskin]

When discussing this with @martinthomson I suggested that resources be able to include a "name" in the signature that's distinct from the URL path. He pointed out that this idea is similar to the nonce discussed in #41, but I think it's important that the name not have to be used just once. The idea would be that you could sign multiple versions of the same resource with the same name as long as it's not insecure to substitute one for the other, and you could serve copies of that signed resource from lots of different places without breaking the signature. You need a similar way to attach the name to the integrity as in #41, but the integrity="ed25519-[key goes here]?name=[script-name]" syntax there seems to work for this too.

[mikewest]

I've thought about this a bit on and off over the last few days, and my current take is that it's reasonable to be strict about the provenance checks that a page is asking for. Defining a variant of the profile that applies to redirects (as discussed above) seems like a straightforward solution, and hopefully won't complicate deployments too much.

@ddworken: I think it would be necessary to sign all the hops for the integrity check to be meaningful. I tried to spell out some of the things I'm worried about in https://wicg.github.io/signature-based-sri/#security-substitution, but at core we've modeled SRI as a network-level integrity check that aims to ensure that developers get the resource they're asking for, even in the presence of an attacker who controls the server from which they're receiving a script. From that perspective, I see redirect responses as being different in kind from eval() or import or etc.

@jyasskin: At the moment, I'd suggest that the URL a developer specifies is a reasonable-enough "name". If we require redirect responses to be signed, and encourage (require?) developers to sign @path/@query-param in their responses as well, I think we'd have a fairly robust system. I worry about the deployment cost of requiring those components, but I might be overestimating the difficulty of teaching a build system about resources' expected locations.

[ddworken]

@ddworken: I think it would be necessary to sign all the hops for the integrity check to be meaningful. I tried to spell out some of the things I'm worried about in https://wicg.github.io/signature-based-sri/#security-substitution, but at core we've modeled SRI as a network-level integrity check that aims to ensure that developers get the resource they're asking for, even in the presence of an attacker who controls the server from which they're receiving a script. From that perspective, I see redirect responses as being different in kind from eval() or import or etc.

This seems reasonable to me, it is true that if someone chooses to sign a redirect and we didn't apply Signature SRI to post-redirect requests, that would essentially negate the benefits of Signature SRI. In my opinion an easy answer is just to not sign redirects, but I think checking the whole redirect chain is also quite reasonable. I don't anticipate this causing any deployment issues.