[Unbearable] Dealing with header injection through reverse proxies

Eric Rescorla <ekr@rtfm.com> Mon, 17 July 2017 15:18 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C3DD3131C72 for <unbearable@ietfa.amsl.com>; Mon, 17 Jul 2017 08:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X_TnHEAfanLM for <unbearable@ietfa.amsl.com>; Mon, 17 Jul 2017 08:18:51 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 83CAC131C65 for <unbearable@ietf.org>; Mon, 17 Jul 2017 08:18:51 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id v193so48750381ywg.2 for <unbearable@ietf.org>; Mon, 17 Jul 2017 08:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=a1QZtylsJaAKOOi4Koi6Bj2w2fMkgUxiyUrh71JEAjE=; b=MyjhgOPN46LzPjyAqZhM/mUd2mTataT8srAmTHuXvuBv01si//+5SvlXGjc4DbzOt5 SKzslyFIa9IMf29Ladappw7MpqpSRgo5LLB3u6+FqQCQrOYIiAYPMmi++6eh4UFf/QwL F+LoKjY+xzT6gf4pHhkHoJIztXh8iPRp5cfGYFpFHdSI7xx7L4sTKMCNQMRUuQHOvhSn fyKiBNxzOqe96/eUUFq6XHOoRLVbFeFpTLvafCzMGGxQYc/8ud0w4NFQXd+evYqcZ3KT PWyx23Ap3ThKoG2O4neFdMiPnp/WcnvHZNBJ33ZGB87D2jp+48ZQDJFfHokVxKgLRXef CZig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=a1QZtylsJaAKOOi4Koi6Bj2w2fMkgUxiyUrh71JEAjE=; b=rhQgBBGJxkYVIvkMCq3//N4KprkfYZIwZOVqvXU0OijU9qfpPt3pOksoLJmt1ID9v/ 1ypsQdjBqcJFtCTrk7Ky2s0RRDv7kuJ9hMN+oI7RkQ6eWv2sCf9zr4u2rk9TaMrzvLRG HZM3jer9ttFdYBVaqmktPfLGNYb9aaTTMFzU4JrEjFbdfR4aZRNE6ArXSFBQp3vlK0xl ASsUHgSh9PvTEPTrKrBS8Q8b1gqa7C0F0XtBgukjLuzB/w37KZxg2H84d9LBQ8g/qFGB ZQLLhUZaW/b7WkJ2BLwRy16YO1+3+o0gJBt87g700beteqZVZtKBStSb2MyoPUfY04ax 5kUA==
X-Gm-Message-State: AIVw112AxJdhPslSGbOVFeCabBfB0MLw/9azkr4RDU0Mu0NxokgxOAKo GX+IO5ZPgtacKjc8zpAp/pgSqjQU4fMc
X-Received: by with SMTP id t2mr16537495ywg.44.1500304730543; Mon, 17 Jul 2017 08:18:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 17 Jul 2017 08:18:10 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Jul 2017 08:18:10 -0700
Message-ID: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b789284f6fe055484eabc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/EBq2lj0S8IOMQxYRy0jLCr8RAY4>
Subject: [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: Mon, 17 Jul 2017 15:18:54 -0000

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?


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