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]>]

I agree wholeheartedly that an HMAC or even signature is preferable.
With HMAC vs signature having their relative pros / cons, in terms of
computation and key distribution. If a standard for that is created, and
I am a web application developer, I'll be able to handle the header
checks in the application layer code relatively easily. But I have much
less control over how / where the application is going to be deployed,
and if the reverse proxy has this header security implemented. Software
and cloud vendors can sometimes be significantly behind in such
developments. Even basic handling of self-signed client certificates has
been an issue for us in popular cloud environments.

With that in mind, the "secret" headers can be configured with most
currently available reverse proxy software. I see it as a useful
intermediate step, until a standard for authenticated headers gets
agreed on and eventually implemented in reverse proxies. Can you comment
on that from this perspective?

Over the years I have come to the conclusion that standards which can be
implemented in the application layer or as a simple config stand a
better chance. Standards which rely on other layers or on broad vendor
or developer support to become useful run the risk of not getting
adopted in practice. Token binding suffered from that.

Vladimir

On 31/10/2019 20:55, Richard Backman, Annabelle wrote:
>
> 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth