I love you Neil.
--
Jim Manico
@Manicode
> On Oct 30, 2019, at 3:18 PM, Neil Madden wrote:
>
>
> If you can point out where I recommended disabling TLS or not bothering to
> strip headers from incoming requests, or anything else along those lines then
> please let me know. Otherwise, yes we
If you strip off the TLS, you *still* cannot pass messages around without
protecting them as if they had secrets because, well, the header name you are
using is secret. This is not a defense in depth.
___
OAuth mailing list
OAuth@ietf.org
https://www.i
If you can point out where I recommended disabling TLS or not bothering to
strip headers from incoming requests, or anything else along those lines then
please let me know. Otherwise, yes we’re done here.
> On 30 Oct 2019, at 17:19, Salz, Rich wrote:
>
>
> To quote your previous claim: "The
* To quote your previous claim: "There is no such thing as an unguessable
name."
Right. That doesn’t mean *I* have to guess it.
* Even if your deployment team had such staggeringly bad operational
security practices as to allow people to take packet captures from an internal
network a
On 30 Oct 2019, at 16:41, Salz, Rich wrote:
>
> I'm thinking of a uniformly random 16 byte name right now. Have at it.
> Cute but missing the point. I don’t have to guess it.
To quote your previous claim: "There is no such thing as an unguessable name."
> YOU have to securely deploy it across
* I'm thinking of a uniformly random 16 byte name right now. Have at it.
Cute but missing the point. I don’t have to guess it. YOU have to securely
deploy it across your proxy (however many staff), your backend (however many
staff), your application developers (however many), and perhaps yo
Combining responses to related messages (429 error):
On 30 Oct 2019, at 14:07, Salz, Rich 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 suc
* 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
On 30 Oct 2019, at 14:05, Torsten Lodderstedt wrote:
>> On 30. Oct 2019, at 14:56, Neil Madden wrote:
>>
>> On 30 Oct 2019, at 13:24, Justin Richer wrote:
>>>
>>> All of these problems can be solved, and I think solved better, by securing
>>> the connection between the proxy and the back-end.
> 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. You claim the name will never be exposed to untrusted
parties. How so? Y
> On 30. Oct 2019, at 14:56, Neil Madden wrote:
>
> On 30 Oct 2019, at 13:24, Justin Richer 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
On 30 Oct 2019, at 13:24, Justin Richer 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 t
+1
> On 30. Oct 2019, at 14:24, Justin Richer 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
>
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 th
Replies below.
> On 29 Oct 2019, at 19:13, Justin Richer wrote:
>
> I would argue that making this standard would actually increase the
> likelihood of developers getting this right, as now instead of following some
> copy-pasted recipe for NGINX or Apache that they found on the web, they cou
15 matches
Mail list logo
