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

John Bradley <> Mon, 17 July 2017 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9053131CB9 for <>; Mon, 17 Jul 2017 09:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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 hh3-X863L85M for <>; Mon, 17 Jul 2017 09:34:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FCE1131CB2 for <>; Mon, 17 Jul 2017 09:34:02 -0700 (PDT)
Received: by with SMTP id f67so89710920wmh.1 for <>; Mon, 17 Jul 2017 09:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iAnoFHZGiXAIT1HDxYajY54CyLv9+c7nKC4rMPLaSM8=; b=EG9YJNSyZ1Zpaukis86h6NPWTUfag1N6Yyjgj2BcS2UFIj41yFQ/piXqOwh9+wRbvs 3+YMZnvieW+i8V+xBHm65RdTFjEEzIikFReu2FrK/eVVXle4PNVv3NNv3dCx43UvfZ+9 kyqmdoyRhrtBK/j6ueTJHXp6b/6ZvbBrE/hmkcUiqTl97Jj+0Wt3yXeQb4iD6lK+RRH6 2pOTXwOV3c0aHjs0Z5CuHGh1dm5eiYW9GPWKCHVHe8bb/JOktOTyBdt764a1y9fGfkB7 a89mccU3X7hsuxAuc5j7XEysAAkAkhje4JeR7HKL4yddAICmoQGElzF58dUN+D67S7TF Gvhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iAnoFHZGiXAIT1HDxYajY54CyLv9+c7nKC4rMPLaSM8=; b=NFMavy3UvxbWKFEJy0cuPVWcIVJzopuU4a8x2VL4JXd5HQqbGqcJxoCZxMZrwP3Vap brbWujVBxqvPruTaUzZTjNZHx9J67ybVY4XVyPdzMvcAOMjIOKQVn8lMuZF6DyswqJTN So1BbmJvh+8NZ5jRVp/dxwCZl54Ds6QwV+BOANbl5bz5gtEIS2YzUpy2LDzizB4Fhrn5 xUGUTamUloyFm0UG//2DiM7HdlCDZnLyOSiE2tx8cyJMkpOE3vctoxMSFITm833wOMw8 JJbtCeiNOgbLMDNbV555yjkQpS9pgS2Lky8JMqFslEpkaiZldjopAObSWl2Xj2gBOZnJ hv0A==
X-Gm-Message-State: AIVw113/3QWzbKLCFDkbWkrj2NMlto9w5yC8Kn3TUapoycDxA89fheFy EzhQOAb85pOXycAo
X-Received: by with SMTP id u126mr5415109wmu.48.1500309240550; Mon, 17 Jul 2017 09:34:00 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:184:31a1:58c5:f51b:f835? ([2001:67c:1232:184:31a1:58c5:f51b:f835]) by with ESMTPSA id 9sm51616wml.25.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 09:33:59 -0700 (PDT)
From: John Bradley <>
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 17 Jul 2017 18:33:56 +0200
In-Reply-To: <>
Cc: HTTP Working Group <>, IETF Tokbind WG <>
To: Eric Rescorla <>
References: <>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114228305cd230055485f723"
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:34:15 -0000

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