> On 30. Oct 2019, at 14:56, Neil Madden <neil.mad...@forgerock.com> wrote: > > On 30 Oct 2019, at 13:24, Justin Richer <jric...@mit.edu> wrote: >> >> All of these problems can be solved, and I think solved better, by securing >> the connection between the proxy and the back-end. That way the back end >> will be able look not only for a specific header, but verify that the header >> came from the proxy itself. An obscure header name is one way to do that, >> but it has a lot of issues with it, especially since it’s likely to be >> selected once during set-up and never changed throughout the lifetime of the >> deployment. I think there are likely much better solutions here, and they’d >> address this issue without things getting weird. > > The issue has nothing to do with the security of the connection between the > proxy and the backend. It is to do with data origin authentication of the > headers themselves. All of the headers arrive at the backend over the same > connection, but only some of them were created by the proxy. There are > undoubtedly better alternatives - e.g. using a shared secret to compute a > HMAC over security sensitive headers and include that as an additional header > or field. But an unguessable header name is *simple* and effective and works > right now with widely implemented functionality. > > There's no need for the header name to ever change - the secret is not > exposed to untrusted parties
If the proxy sends certs via an header X to service A and B and someone impersonates A it will find out the secret and use it to inject certs in a connection towards B. We have learned that it is sometime hard to use different secret header names for the same purpose with different request targets. In those cases, a way to authenticate the proxy might by a good solution. > and is a defense-in-depth rather than a primary defense. I also don't know > why you consider this a "weird" solution - it's a simple pragmatic solution > to a fairly widespread class of security vulnerabilities. It also has the > benefit that it forces the backend to "validate" the secret, because it won't > find the header if it gets it wrong, whereas it is much easier to forget to > validate a HMAC tag. I'll take simple and weird over missing and broken any > day. > >> >> And one of the best things about a standard is that you’re still free to >> completely ignore it if you want to, so people can and will keep following >> whatever proprietary patterns they want to. But at least a standard >> mechanism would give us a way to say to newcomers and veterans alike “No >> really, here’s a way that we all agree works and has these properties”. > > I'm not arguing against a standard, just against a standard that makes it > harder to mitigate known security vulnerabilities. > > -- Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
