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

Ted Lemon <> Mon, 17 July 2017 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDEA1128BC8 for <>; Mon, 17 Jul 2017 09:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SFFUUp_uLlNA for <>; Mon, 17 Jul 2017 09:07:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3671131C8F for <>; Mon, 17 Jul 2017 09:07:24 -0700 (PDT)
Received: by with SMTP id e199so17506607pfh.2 for <>; Mon, 17 Jul 2017 09:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Y+I0XNy2hTfNUR9epvidYPjbK7ZXNQcUVFlkEjxXpE=; b=r7PNjbtcdKEEc5sEJmj457pQuIBpipWUDagUi1J1Ob5Zjx3vjIxMOWPquD9BGi82ru CHmmpnpWeHKUaN+Vwh6WjZ0HvvbrpDdPY+e5SuhWAfQ9sXDXlK7b17F+lJZNZ5LxFg7x PGkfc3lWw7uVc8CGAOUyP5WXGJQ4N1L41MdZWVzIQp/zC26sJ9YXFdQI0Bodn7vPfosB T8nOtUZMVUKFNhsoYFXHWW3abujPMvxAhxCDoMdQuPxc4PJpXko+2J7J0YzYK5hSwRWJ Cy+L1rlpdS6wZCI2jW54Xh5q4jV8+so3X/H4rWjay6B4QZDGSDTbGg0LYB5cKIbCZzaS rgxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Y+I0XNy2hTfNUR9epvidYPjbK7ZXNQcUVFlkEjxXpE=; b=R5THRehuk6OdvLDMqJ4ik/UrcuR2orDyq5WqY0fVG4flyG77/OkM3GmWXccwWEMxPJ 3ZfDOJvPsFzjYVa/pHPyRTiILbpK77+pQ984InorAovS049EaT1io/RpBQI2eHdiEy8n kR7BywcHwFI0DeKZUumcqNXs4rgFsJIU5GwjJmhZHUHf7FCe5VsnC5jnYtmIBm2LS7xD HvyHYBABxAJSRpWOFZt3oow9a/CN1QOMfKzPylpX0v1tWtWriIEZ6ec2AXsUYMzwfSMj 7snudWDT/oA6WLXMaYfGn/d2qMTwmPSJZ1d3tXd9zs6O2I5yYNuclfXAeDetej8fA6/c 7pOg==
X-Gm-Message-State: AIVw110/xZf6IkNgKb0VcRFrYxIVLhHsXl9K6F180uUAMbmzUgdG7cWN aHslC/NWe1W9aWTID6mWnX7nSRT3h8X8
X-Received: by with SMTP id q4mr20115468pfq.143.1500307644540; Mon, 17 Jul 2017 09:07:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 17 Jul 2017 09:06:44 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Lemon <>
Date: Mon, 17 Jul 2017 18:06:44 +0200
Message-ID: <>
To: Eric Rescorla <>
Cc: HTTP Working Group <>, IETF Tokbind WG <>
Content-Type: multipart/alternative; boundary="001a1145cd5e34fd8f0554859873"
Archived-At: <>
Subject: Re: [Unbearable] Dealing with header injection through reverse proxies
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jul 2017 16:07:27 -0000

I was reluctant to go to the mic to say this because I'm very much an
innocent customer of this work, not an expert on the topic.   But from my
perspective, while I see and value the ability to do this (I happen to use
nginx), I am very uncomfortable with the problem you described, ekr--I
would much rather that this failed safe than failed insecure.   So I don't
really feel qualified to say "yes, we should do what you have proposed, and
here's how I would do it," but I am definitely rooting for that to happen.

On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla <> 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
>  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