> On 30. Oct 2019, at 15:15, Neil Madden <neil.mad...@forgerock.com> wrote: > > On 30 Oct 2019, at 14:05, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: >>> 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. > > Being able to impersonate A suggests that the attacker is already on the > trusted side of the network and that you are employing zero additional > network security controls between the RP and service A and B (e.g., TLS, > firewalls, VLAN/switches, etc). Remember, this is intended to mitigate > against accidental misconfiguration of the RP and header spoofing tricks > coming from the external network. I'm not suggesting it as an alternative to > basic network security on the trusted network.
Is there such a thing as a trusted network? I’m not sure what you mean but micro services call each other so network segregation would not help to prevent replay of a leaked security header. But (see below) different secret headers can be used to mitigate the threat I raised (at least limit the impact to an individual service). > >> 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. > > Do you have an example? I checked back and it seems I had misunderstood. It’s possible to use different secret header names, one per proxy-to-service connection. > The RPs and load balancers I'm familiar that support multiple backends all > support sending different headers to each of them. Again though, security > against attackers inside the trusted network is not part of what the solution > is preventing. > > Again, authenticating the *connection* from the RP to the backend services is > good, but is completely orthogonal to authenticating the headers themselves. > > -- Neil > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
