Make it safe to reverse proxy

[mnot]

This came up at the Workshop -- if a reverse proxy is deployed in front of a server, and that reverse proxy doesn't know about this convention, it can expose state to the back end server.

Whether or not that's a security issue depends on the information exposed.

One way to avoid this is to use OPTIONS with Max-Forwards, e.g.,

OPTIONS /.well-known/h2-debug-state
Max-Forwards: 0

However, the downside is that this would make it difficult / impossible to use from a browser, which is probably the point. If it's just meant for programmatic access, maybe a new frame type makes more sense.

[Lukasa]

So this is kinda vaguely dupe-y with #2: @louiscryan probably cares about seeing this issue too.

I think the general consensus is that the only security risk so far being exposed is the HPACK compression state. As far as I see it, then, we have some options:

1. Use OPTIONS. It feels weird, and you're right that if we did that we should really strongly consider using a frame instead.
2. One thing we could do is say that certain fields (e.g. HPACK state) should only be dumped if X-Forwarded-For (or some similar header) is not present.
3. We could say that the entire response should only be served if X-Forwarded-For is not present, given that if it is connection coalescing is probably happening and we should 404 instead.
4. We could just abandon dumping HPACK state.

I'm not sure which of those I prefer. And then we need to ask whether intermediaries should also be inserting themselves into this if they want to, and how they should do that.

[mnot]

How important is being able to just show this in the browser?

If it is, I guess the other option would be to require HTTP auth for it, or something similar.

[Lukasa]

I'd say it's moderately annoying if we can't show it in a browser. If you're writing a server, the obvious way to want to test it is with a browser. Requiring a separate H2 frame removes that freedom, which is a bit sad.

While I'm here, I should point out that if we want to mint a new H2 frame it gets quite a bit more annoying not to pass this spec through the IETF process: if we don't, there's always a risk that someone might stamp on our new frame ID!

Auth could work, though it's not clear to me that it solves the intermediary issue does it?

[mnot]

Use the experimental frame ids :)

re: auth and intermediaries - hm. Probably should get a Real Security Person to look at this.

[Lukasa]

That seems sensible to me. Got anyone in mind? My Real Security People aren't really H2 people.

[mnot]

@ekr?

[ekr]

@mnot, @Lukasa I'm still trying to wrap my head around the concern here. @Lukasa says that it's HPACK compression state, so I'm assuming the concern here is that we have connection sharing and I could use that to extract other people's data? Is that it?

If so, I have some other potential concerns: what if the proxy uses headers and the like to communicate its own state to the server? I might be able to get the server to act as an oracle for that.

[Lukasa]

I'm assuming the concern here is that we have connection sharing and I could use that to extract other people's data? Is that it?

@ekr Yeah, the concern is that HPACK state is only safe to expose hop-by-hop: there is no guarantee that anywhere beyond the first hop it's safe to expose that state.

If so, I have some other potential concerns: what if the proxy uses headers and the like to communicate its own state to the server?

Yup, this is another good reason to not want to expose the HPACK state on that second leg. I'm generally of the view that it's only safe to expose HPACK state one hop.

[ekr]

Given this, my suggestion would be to just not dump HPACK state (note: I haven't analyzed anything else here). We can always invent some new way to indicate that that's OK later.

[bradfitz]

I haven't seen anybody propose using this mechanism to let one connection debug another connection's state, and I don't think we want to open that can of worms, so I think OPTIONS is fine, at least to get HPACK state.

It's cute to demo this in the browser to show people what it does (and we can still do that with GET, as long as GET doesn't return HPACK state), but in reality you're going to use this from the TCP connection you're debugging, and unless you're @mcmanus you're probably not using your browser to debug your HTTP/2 client implementation, so it's not not particularly onerous to make your HTTP/2 client send OPTIONS instead of GET.

[PiotrSikora]

Please note that not every proxy respects Max-Forwards request header (i.e. NGINX doesn't), so we need to handle this at the HTTP/2 level with a new frame (see #9) in order to guarantee this being hop-by-hop.

[bradfitz]

If GET and even OPTIONS can be proxied, and adding a new frame (#9) is too complicated, what about adding a new boolean setting which a peer must advertise in their initial settings frame to declare that they understand /.well-known/h2/state and won't proxy it? Only if that setting is true should peers ever query the state.

[Lukasa]

If GET and even OPTIONS can be proxied, and adding a new frame (#9) is too complicated, what about adding a new boolean setting which a peer must advertise in their initial settings frame to declare that they understand /.well-known/h2/state and won't proxy it? Only if that setting is true should peers ever query the state.

So my concern with this idea is that it protects us against only legitimate users, not malicious ones. If you choose to ignore the setting and have a naive proxy in the way, the proxying will still happen and the HPACK state will be exposed to the malicious user.