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

Piotr Sikora <> Tue, 18 July 2017 09:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B018131945 for <>; Tue, 18 Jul 2017 02:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 2td4TEGgFLSu for <>; Tue, 18 Jul 2017 02:16:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9150E131DC8 for <>; Tue, 18 Jul 2017 02:16:18 -0700 (PDT)
Received: by with SMTP id 64so16287487uae.2 for <>; Tue, 18 Jul 2017 02:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4zo8+Cj3pVLpcov7TmNNdLREt2rSh7lrsbGkJ7JC5Io=; b=NhDS4k92Cdy7otfUCKAvLkzUl78Zgcvp/6/KGQuRI8oA9cAtv2tFCYB8MfOgnxSD// kYRdabn94V78GWOwGPmjMy0ZLZS7RjVUXtKE+E4+4c8vB/5SlyK7EmujQkIMFeAGECyo I2dLcsMzSG2yXutQ1TghC/LeavM1IarQcK0x3DLBs7ll3LXKsvrRTInX1wvoqCJBB6K3 xr72GDR8rUPhGl39f/JpIOfQ91l4pLZ36jZZx4FFckj69MBjqK+gDhU9D9cqNGKl5aL+ uV3yAERVrQnmvs6tysz3WlJ62G18m4+11kgRZcaqKv1BVni3ZrlnOwv//QJUUb4vysNW qhlA==
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=4zo8+Cj3pVLpcov7TmNNdLREt2rSh7lrsbGkJ7JC5Io=; b=K2km8C4hzNJ15sEvsMU5wzMTgARtnf0MxhzHXeYrXN/NTd7hirf3g44veCwppoGTMs hXD0vFFseKKCHRP8xdsE4VR3y+8Upy+YM2B3mdtVy/p3kV3b8Wa50u9fjXWyC51Uz2S0 F3o3BTJ29thcu4SvQC/XEHmgqbNsKZmzsAb5YABMKvgeK6Kfg6f/+A7CVCF3rtaMhOOf YrPFBPKeAmsVMbSSQKUtzNpfCRL5iCwjRABnbrZkIHNTC5IS1H71UldSzQ7nMv4+jB4/ xuvc63kDZWZCSHr1YST5wsQhIU3MeBUABFcEdUgUhg2tVtjMBOCQEFSG/TwOmZ9LjLpP 2vtw==
X-Gm-Message-State: AIVw112sXefSKgsxJBB6BvBwHK2d0GX02WYPy4Mfap6phrJF/QoPn70e G23u07hO59BVzsB+UeH1XjTbnl8ru1QK
X-Received: by with SMTP id h77mr320486vkd.14.1500369377475; Tue, 18 Jul 2017 02:16:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jul 2017 02:16:16 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Piotr Sikora <>
Date: Tue, 18 Jul 2017 11:16:16 +0200
Message-ID: <>
To: Patrick McManus <>
Cc: Eric Rescorla <>, HTTP Working Group <>, IETF Tokbind WG <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 18 Jul 2017 09:16:20 -0000

Hey Patrick,

> If the problem can be reduced to the above then I think there are some http
> features that are worth considering if you're willing to look at it as a
> single hop requirement:
> a] if the proxy->server link is h1 then the x-client-certificate name can be
> included in the Connection header sent to the server (and the server can
> enforce this property). Any naive proxy receiving that same combination from
> a malicious client would remove the request-header of the same name before
> forwarding it on to the server and then generate its own Connection header.

This would work... but only in a single-hop deployments.

> b] if the proxy->server link is h2 then you can inject connection-specific
> information into the stream with an extension frame type (and the server can
> enforce this property). You don't need to negotiate it with SETTINGS (which
> is nice, because that's a round trip.) and these frames are hop to hop
> (proxies that don't understand a frame type MUST drop them).

Putting "internal" headers into a new HTTP/2 frame instead of mixing
them with client headers in the HEADERS frame is the idea that I've
been toying for a while now, mostly for multi-hop proxy deployments.

However, it's unclear whether the backend server should receive only
client headers (which wouldn't solve this particular issue) or both,
and how should this work with "internal" headers crossing
organizational boundaries (i.e. CDN terminating TLS and forwarding
"X-Client-Certificate" header to the origin server).

Also, this requires end-to-end HTTP/2, which is pretty much
non-existent nowadays, since most proxies don't support HTTP/2 to
backends (yet).

Having said that, this is something that I definitely want to see
done, regardless of whether it's the right solution for this
particular issue or not.

Best regards,
Piotr Sikora