Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

Vladimir Dzhuvinov <> Thu, 31 October 2019 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DE501200FE for <>; Thu, 31 Oct 2019 03:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eMkulxBuW2DI for <>; Thu, 31 Oct 2019 03:36:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2ECE51200F6 for <>; Thu, 31 Oct 2019 03:36:54 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id Q7owiFuyIyg8JQ7oyiMO47; Thu, 31 Oct 2019 03:36:52 -0700
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Vladimir Dzhuvinov <>
Openpgp: preference=signencrypt
Organization: Connect2id Ltd.
Message-ID: <>
Date: Thu, 31 Oct 2019 12:36:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------110BC3B770F4B2B4411903F1"
Content-Language: en-US
X-CMAE-Envelope: MS4wfIll0R9Jh/8PW0sdT8G/D286d9BV/SRFUwZi0bkafbmgqedxFlem7LRV7Y4jvCaYjSg/ZyNAl39TiUJcbbVxIh5Tr2D7hCM2cDcuypUhuW93LWbvD1BG BvobKTZcQdb3gv3UgStCKvgXfcqSORt22giMUtvudAi/jmseSfnQXq6U
Archived-At: <>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2019 10:36:56 -0000

> All in all, I am in favor of this being defined in one standard way,
> in addition to secure communication between proxies and backends being
> standardized — but this latter bit really seems like a separate problem.
>  — Justin

-1 for devising a well known header

+1 for a simple way to authenticate a reverse proxy with a web server

With a well known name, in a attack this will get probed first. The well
known header name doesn't guarantee a correct config. And if we have a
new standard for sec headers that must be stripped automatically from
inbound HTTP requests, we cannot expect that will get implemented in all
reverse proxy software overnight.

Because a correct config is not practical as the only line of defense,
when we implemented mTLS we decided to add a length (>= 32 chars) and
randomness check to the header config. I saw some concerns that this may
cause deployment issues. Nobody has complained about that so far.

Regarding mistyping, this can be an issue, but has little to no effect
if a long random header gets misstyped (from the inbound strip
directive). With a well known header this will result in a immediate
security hole, which can theoretically go unnoticed.

Here is an example Apache httpd config, to illustrate my point:

RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"

(the first line strips the inbound headers)


Vladimir Dzhuvinov