- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 17 Jul 2017 08:18:10 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>
- Message-ID: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
i folks, We had a discussion today in TOKBIND about handling security-sensitive indications in HTTP headers (this came up in the context of https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The setting here is that you have a network with a TLS reverse proxy serving the origin server, and the TLS proxy is responsible for doing some security check and telling the server about it. E.g., Client Proxy Server <--- TLS w/ client auth ---> <----- HTTP with cert ---> The client does TLS client authentication with the proxy and then passes the certificate to the back-end server in an injected HTTP header (e.g., X-Client-Certificate). In order for this to be secure, the proxy has to *strip* any security sensitive headers sent by the client. Otherwise, the client could inject their own headers that would appear to come from the proxy. Obviously, this design doesn't fail safe if the proxy fails to strip the headers. One way in which this can happen is if you have a large network of load balancers fronting a server network and you somehow incompletely misconfigure either the servers or the proxies, so that a server which supports this mechanism ends up behind a proxy which does not (and hence does not strip the headers). So, it would be nice to do something better that wasn't too heavyweight, especailly as a general solution. One natural design is simply to have a shared key between the proxy and the server. In that case, it's easy to demonstrate that the header is injected, as in [0][1] X-Client-Certificate: <key>, <certificate> The obvious objection to this design is that it requires you to establish the shared key, and people were concerned about having to configure it into the proxy. I'm aware of a number of designs here: - Configure it via some sort of remote configuration mechanism. - The proxy could send it to the server on its first request (might require some trickery on the server). - If you have a TLS channel between Proxy and Server you can use a TLS exporter. - If you have a H2 connection between the two, you can have the server provide it in a settings frame. - Use a signature by the proxy using its private key over something e.g., S(K, "Token binding"). If you use a mostly fixed string, then the server just needs to verify it once. Do people have other thoughts on this problem? Other good ways to establish the key? Other ideas for how to address it? -Ekr [0] I'd originally suggested HMACing, but that's actually not necessary, though obviously stronger. [1] Note that you could have a generic solution, like a header which listed all the injected headers, but with the same security mechanism.
Received on Monday, 17 July 2017 15:19:18 UTC