Re: [Unbearable] Dealing with header injection through reverse proxies
John Bradley <ve7jtb@ve7jtb.com> Mon, 17 July 2017 16:34 UTC
Return-Path: <ve7jtb@ve7jtb.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 C9053131CB9 for <unbearable@ietfa.amsl.com>; Mon, 17 Jul 2017 09:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 hh3-X863L85M for <unbearable@ietfa.amsl.com>; Mon, 17 Jul 2017 09:34:12 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 5FCE1131CB2 for <unbearable@ietf.org>; Mon, 17 Jul 2017 09:34:02 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id f67so89710920wmh.1 for <unbearable@ietf.org>; Mon, 17 Jul 2017 09:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.28.46.132 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 smtp.gmail.com with ESMTPSA id 9sm51616wml.25.2017.07.17.09.33.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 09:33:59 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <AC7E03FF-F623-4071-9E64-FF0635E69D66@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 17 Jul 2017 18:33:56 +0200
In-Reply-To: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114228305cd230055485f723"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/IH6fLtt22dNUaIYdzu10aCuB8n0>
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: 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 <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 <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
- [Unbearable] Dealing with header injection throug… Eric Rescorla
- Re: [Unbearable] Dealing with header injection th… Cantor, Scott
- Re: [Unbearable] Dealing with header injection th… Ted Lemon
- Re: [Unbearable] Dealing with header injection th… John Bradley
- Re: [Unbearable] Dealing with header injection th… Willy Tarreau
- Re: [Unbearable] Dealing with header injection th… Brian Campbell
- Re: [Unbearable] Dealing with header injection th… Piotr Sikora
- Re: [Unbearable] Dealing with header injection th… Piotr Sikora
- Re: [Unbearable] Dealing with header injection th… Piotr Sikora
- Re: [Unbearable] Dealing with header injection th… Leif Johansson
- Re: [Unbearable] Dealing with header injection th… Joseph Salowey
- Re: [Unbearable] Dealing with header injection th… Graham Leggett
- Re: [Unbearable] Dealing with header injection th… Willy Tarreau