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

Brian Campbell <bcampbell@pingidentity.com> Tue, 18 July 2017 08:51 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE7131DC6 for <unbearable@ietfa.amsl.com>; Tue, 18 Jul 2017 01:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qQhO8M_F2xg for <unbearable@ietfa.amsl.com>; Tue, 18 Jul 2017 01:51:26 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A051131DD0 for <unbearable@ietf.org>; Tue, 18 Jul 2017 01:51:15 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id u5so8990552pgq.3 for <unbearable@ietf.org>; Tue, 18 Jul 2017 01:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IBnclmPkdguYMJx5DK8wwkO5W46KH70ZrpFZYtYSNOs=; b=nRhmn1An42NnqWSUHj+W5i6saM3dfWIQCK3n811lmmz6b2tT0SPllGkZFsCyCYpWxT QidHmOaWHZLvk6+/6yPBFfG+9Bahc9AwCg8VbKCkA1WNtdj44OijPplLTl7XV+QylYw9 vmLx0Vf1UTt646Ps0eWheU4KyqVzCE+jbzOtU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IBnclmPkdguYMJx5DK8wwkO5W46KH70ZrpFZYtYSNOs=; b=MfOGuZNC9XTMGpYcRB9x/IacEP1/wV4WsjGf6oVl9mnzQrYzgx1nfBRp2k98HweNo9 OnkgLSiFm0bWHZO0Wtw587R2aA7c6w3pLM6fZoFEv8anGuJRqZCDb3P2xVL4jaGcECuS bysUaTOSJWxAVGldFdR8Z3ywI0nFSU+jdtosHnpII+SunnFPJw/inWe8h4r9ufktQG9d VxIueWjA8mTHBPewaHLvqKfyITLgU2PtW4v8UThRk62mgvXTYwqrRbKNWS8pFfIu+jYC hZ+4HizK9s7wNXXaG2bHb+I4YEKK6HDUvXze2W/SX31rnzqU8zsWUArIUsCa/W2BBJxs aliw==
X-Gm-Message-State: AIVw110vgChfwBk47WZzxpc8zdz4EHTPYdLw/UFTQAU7gs+UqcMZ0Upe ETBmy7xNRxBQdJGaqF9gLg+1Y9zuLlVtwr+eHhGcTIJsr7Iit1bTvPo5gnR6mNfTWudlMJBjhWM TfqVPd8BR7jE=
X-Received: by 10.101.87.200 with SMTP id q8mr598743pgr.110.1500367875104; Tue, 18 Jul 2017 01:51:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Tue, 18 Jul 2017 01:50:44 -0700 (PDT)
In-Reply-To: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
References: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 18 Jul 2017 10:50:44 +0200
Message-ID: <CA+k3eCTRNebzWO-vf30sp6MZU=yL_rR62-PG8gwn2zW0VZAiaA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="089e08236ba03a7a2b0554939eff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/eBSsyL73mRkFeiMvMHkQVpGndOA>
Subject: Re: [Unbearable] Dealing with header injection through reverse proxies
X-BeenThere: unbearable@ietf.org
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.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 08:51:29 -0000

I perhaps didn't articulate it well in the meeting yesterday but I'd like
to reiterate that, in my opinion and I don't think I'm alone, it would be
very inappropriate for -tokbind-ttrp to define a one-off mechanism for the
origin server to detect client injection of the headers. The potential
problem of client header injection is not at all unique to the
functionality of that draft so the draft shouldn't define a unique
solution. It would be useful if there were a common standardized mechanism
for doing detecting/preventing client header injection that the
-tokbind-ttrp draft could refer to (the generic solution that Ekr mentions
in his [1] seems preferable precisely because it is generally applicable).
In the absence of a generic solution existing currently,
stripping/sanitizing the headers is the de facto means of dealing with the
situation in practice today, is sufficient when properly implemented, and
is normatively required by the text in -tokbind-ttrp. It's true that, if
the reverse proxy is defective/misconfigured, it doesn't fail safe but in
the context of -tokbind-ttrp that failure mode is far from catastrophic.
Such a failure loses the protections afforded by token binding, which is
not ideal, but it is the current state of just about everything on the web
today so it's not *that* bad.






On Mon, 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).  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
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*