Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: 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]>]

The comparison the bearer tokens is illustrative of the problems I and others are pointing out:

  *   Bearer tokens are embedded in the value of the header, not the header itself, which partially alleviates the concern I raised regarding request signing algorithms.
  *   Bearer tokens are typically relatively short-lived, providing some mitigation against exfiltration through logs.
  *   Bearer tokens are typically dynamically generated, and are therefore less likely to be embedded in source code or config files in a project’s repository.
  *   Bearer tokens are called tokens, and are presented as secrets and are always expected to be treated as secrets.

The random header name is effectively an infinite-lifetime, statically defined bearer token presented in a way that does not at all make clear and obvious that it is a secret that must be protected, and in fact makes it more likely that it will be revealed, rendering it useless. And like all bearer tokens, even under ideal conditions it by definition CANNOT BE USED TO AUTHENTICATE THE SENDER.

There is a certain amount of irony in the idea of the security of a Mutual TLS deployment ultimately coming down to a bearer-token header name passed between the reverse proxy and the protected service. 😂

> if you forget to validate the signature *nothing fails*

Replace the HMAC with encryption and you solve that problem, as it forces the service to decrypt the value using the correct key in order to access the client certificate data. Whether or not that’s worth doing is something we can debate in the context of an actual proposal.

–
Annabelle Richard Backman
AWS Identity


From: Neil Madden <[e-mail]>
Date: Thursday, October 31, 2019 at 1:17 PM
To: "Richard Backman, Annabelle" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

On 31 Oct 2019, at 18:55, Richard Backman, Annabelle <richanna=[e-mail]> 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.

Just like any other bearer token.. I mean this is the *OAuth* WG, right? Where we regularly recommend people send bearer tokens in headers? I don’t really understand how that can be considered secure to send over the internet to a cloud service, but suddenly becomes insecure when done inside the firewall within a datacenter between a reverse proxy and an app server.

I mean, are people honestly suggesting that randomizing header names introduces *new* vulnerabilities that aren’t present when you use a well-known name? “Dangerous” even!


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.

I agree that HMAC signatures are generally better, but which reverse proxies support signing headers?

Actually HMAC signatures do have one significant downside compared to using a random header name - if you forget to validate the signature *nothing fails*. If you mess up the name of a random header then your app doesn’t see any credentials and fails noisily.

— Neil