Re: Dealing with header injection through reverse proxies

On 17 Jul 2017, at 5:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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 —>

A few years ago I needed to solve this problem.

I needed a secure, typo-proof way of passing the original IP address from the frontend endpoints, through various reverse proxies, through various service layers which in turn were fronted with various reverse proxies, to an eventual service that cared what the IP address was.

In this scenario, it is trivial to misconfigure things and have the wrong IP address passed on, which was a problem for us.

What we had was a signed header:

X-Foo: SIGNATUREORERROR;value

The frontend endpoint would sign this header, turning X-Foo: value into the above.

Each layer that the header passed through that cared would then verify the header, and if the header verified successfully it would be passed through unchanged. If the header did not verify, the contents of the header was replaced with an error message like so and the value discarded:

X-Foo: error:signature-expired-or-whatever;

What this did was two things:

- Any value that couldn’t be verified was discarded, ie the part after the semicolon was made blank. This stopped developers ignoring the failed signatures.

- The error message was put there so that a bone could be thrown to whoever had to troubleshoot the header. The error would include the IP address of the node that discarded the value, and what the error was.

I can dig out the pattern we used, it solved a lot of practical problems with signing headers.

Regards,
Graham
—