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

["Richard Backman, Annabelle" <[e-mail]>]

Relying on a fixed, random header name for security, even as a “defense in depth” measure, is dangerous. In order for this mechanism to be effective, the header name must be random (in the cryptographic sense) and must be kept secret. It needs to be withheld from request logs or error logs, either on the reverse proxy or on the service. It cannot be committed to code repositories. Including it as a signed header in request signing algorithms that require an explicit list of signed headers (such as AWS Signature Version 4<https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html>, draft-cavage-http-signatures<https://tools.ietf.org/html/draft-cavage-http-signatures-12>, draft-ietf-oauth-signed-http-request<https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request>) turns that signature metadata into a secret, meaning that it cannot be logged, etc. If signatures are sent to a central authority for processing, that authority must also know not to log the list of signed headers. I could go on, but I hope this is enough to express that there are SO MANY ways that header names can and will be revealed, and they aren’t always obvious.

What we are talking about is a message authenticity problem. The best practices for providing message authenticity involve applied crypto, e.g., an HMAC or digital signature over the header contents. If an implementation does that, then the random header name is unnecessary. This approach is immune to the sort of misconfiguration scenarios that have been discussed in this thread, as they would result in the reverse proxy failing to provide a properly signed header to the service.

–
Annabelle Richard Backman
AWS Identity


From: OAuth <[e-mail]> on behalf of Vladimir Dzhuvinov <[e-mail]>
Organization: Connect2id Ltd.
Date: Thursday, October 31, 2019 at 4:27 AM
To: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)


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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


--
[e-mail]<mailto:[e-mail]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>

--

Vladimir Dzhuvinov