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

[Hans Zandbelt <[e-mail]>]

+10

On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov <[e-mail]>
wrote:

> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will  cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think Rich
> Salz had this concern).
>
> * The random chars part, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
> the way I see this is that stripping and setting the headers must be part
> of the implementation of the protocol itself, it should not be something
> left to a non-atomic piece of configuration by an administrator; I
> implemented it like this in the Apache implementation of Brian's TTRP spec
> [1] and have been doing this for the OIDC and OAuth Apache modules that set
> headers for backends to consume [2]; and yes, I have made mistakes [3], but
> IMHO it should not be a problem to use a well known header and make the
> implementer (not the admin) get it right by pointing this out in the spec,
> as is done for many other pitfalls
>
> Hans.
>
> [1]
> https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483
> [2]
> https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175
> [3] https://www.cvedetails.com/cve/CVE-2017-6413/
>
> On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <
> [e-mail]> wrote:
>
>> 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.
>>
>>
>> https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader
>>
>> 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
>>
>> --
>> Vladimir Dzhuvinov
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> [e-mail]
> ZmartZone IAM - www.zmartzone.eu
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu