Combining responses to related messages (429 error):
On 30 Oct 2019, at 14:07, Salz, Rich <rs...@akamai.com> wrote:
>
>> But an unguessable header name is *simple* and effective and works right now
>> with widely implemented functionality.
>
> You mean like admin/admin for administrator access? There is no such thing
> as an unguessable name.
I'm thinking of a uniformly random 16 byte name right now. Have at it.
> You claim the name will never be exposed to untrusted parties. How so? You
> are now telling administrators to treat a *name* as securely as they treat a
> *key* (or password). If it must be protected like key material, then use it
> like key material.
Again, this is a defense in depth measure. A config file is fine.
> The proxy-backend should be TLS, ideally authenticating the proxy.
I agree - but completely irrelevant to the current discussion, which is about
how the backend distinguishes security-critical headers that the proxy set from
security-critical headers that were sneaked past the proxy by a client (through
misconfiguration or parsing bug).
> On 30 Oct 2019, at 14:18, Salz, Rich <rs...@akamai.com> wrote:
>
> Again, authenticating the *connection* from the RP to the backend services is
> good, but is completely orthogonal to authenticating the headers themselves.
>
> I strongly disagree. Authenticating the sender allows the receiver to make a
> trust decision in the provenance and quality of the data it gets from the
> sender. Do you disagree with that?
Yes, see:
https://en.wikipedia.org/wiki/Confused_deputy_problem
<https://en.wikipedia.org/wiki/Confused_deputy_problem>
https://en.wikipedia.org/wiki/Cross-site_request_forgery
<https://en.wikipedia.org/wiki/Cross-site_request_forgery>
https://en.wikipedia.org/wiki/Server-side_request_forgery
<https://en.wikipedia.org/wiki/Server-side_request_forgery>
and so on and so on. Authenticating the other side of a communication pipe is
not sufficient to authenticate the origin of the data contained within those
messages. The whole point of a proxy is that it forwards requests from clients.
In the face of misconfigurations and parsing bugs the backend cannot
distinguish headers that were set by the proxy from headers that were spoofed
by the client. *This is the entire problem I have been discussing*.
-- Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
