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

[Neil Madden <[e-mail]>]

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, draft-cavage-http-signatures, 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