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 <[e-mail]>]

> 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