Re: [Unbearable] Dealing with header injection through reverse proxies

It would be good if the new mechanism could also be applied to existing reverse proxy headders like SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAINn without breaking the existing parsing.

That might lead to a preference for a header that lists the injected headers as a possibility.

John B.

 
> On Jul 17, 2017, at 5:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 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 <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.
> 
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable