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.
>
>
>
> –
>
> Annabelle Richard Backman
>
>
WS Identity
>
>
>
>
>
> *From: *OAuth on behalf of Vladimir Dzhuvinov
>
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"oauth@ietf.org"
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Revers
On 31 Oct 2019, at 18:55, Richard Backman, Annabelle
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
* Relying on a fixed, random header name for security, even as a “defense
in depth” measure, is dangerous.
Thank you. +1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Thanks for this note. According to the abstract the advertising is
intended for "request headers for proactive content negotiation"
(Accept-*), which should exclude all other types of header. I looked at
the Security Considerations and wrote to the author with the suggestion
to note that
How about requiring reverse proxies to automatically scrub all inbound HTTP
headers that start with "Sec-"?
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07
Making a header value “secret” will not protect anything.
___
OAuth mailing list
+10
On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov
wrote:
> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix
This is a good story.
How about requiring reverse proxies to automatically scrub all inbound
HTTP headers that start with "Sec-"?
If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
* The "Sec-" prefix will cause new compliant reserve proxies to
automatically scrub the inbound
> On 30. Oct 2019, at 15:15, Neil Madden wrote:
>
> 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
the way I see this is that stripping and setting the headers must be part
of the implementation of the protocol itself, it should not be something
left to a non-atomic piece of configuration by an administrator; I
implemented it like this in the Apache implementation of Brian's TTRP spec
[1] and
> All in all, I am in favor of this being defined in one standard way,
> in addition to secure communication between proxies and backends being
> standardized — but this latter bit really seems like a separate problem.
>
> — Justin
-1 for devising a well known header
+1 for a simple way to
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
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
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:
* 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
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
* 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
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
* 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
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
> 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?
> 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
+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
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
+1 to Justin's and Brian's comments, I am interested to contribute and I
will try and be there in person as well
Hans.
On Tue, Oct 29, 2019, 22:56 Brian Campbell wrote:
> +1 to pretty much everything Justin said there.
>
> With some facilitating assistance from Ben it looks like there's now an
+1 to pretty much everything Justin said there.
With some facilitating assistance from Ben it looks like there's now an
agenda slot for this in the upcoming secdispatch meeting in Singapore. I'll
attempt to articulate the situation and see if there's interest in finding
a home for the perspective
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 could turn on a
standard setting that would take care of both stripping out
I mean the cert that the ORIGINAL client presented to the proxy.
From: Rifaat Shekh-Yusef
Date: Tuesday, October 29, 2019 at 7:57 AM
To: Rich Salz
Cc: Neil Madden , Brian Campbell
, oauth
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was
Re: I-D Action: draft-ietf
Maybe I misunderstood what you meant by "client-cert". If you meant the
proxy client certificate, then that is obviously not enough. You seem to
suggest that you meant the remote client certificate to be installed on the
proxy to be used with the backend system; if this is the case, then this
When working on the Token Binding TTRP draft I guess I saw the advantage as
being the simplicity or setting, sanitizing, and reading an independent
header that's only conveying the token binding info about the TLS
connection between the "outside" client/browser and the proxy, (which is
the
* To avoid the misconfiguration issue Neil raised, you probably need both:
a client-cert and a signature over the certificate being forwarded,
I am not so sure. One can argue that transport-level identity should be
secured by transport-level. But installing a client certificate on a
On Mon, Oct 28, 2019 at 12:48 PM Salz, Rich wrote:
> Sorry for jumping into this late.
>
>
>
> Client <--> proxy <--> backend
>
>
>
> The C/P side is protected by TLS. There must be similar protection on the
> P/B side, such as client-cert, or a signature over the certificate being
> forwarded,
Sorry for jumping into this late.
Client <--> proxy <--> backend
The C/P side is protected by TLS. There must be similar protection on the P/B
side, such as client-cert, or a signature over the certificate being forwarded,
right?
___
OAuth mailing
While there are some benefits to standardizing headers for this kind of
communication, there are some significant downsides - particularly when using
headers to communicate critical security information like certs. It is *very*
easy to misconfigure a reverse proxy to not strip Forwarded (or
Ok, then we are on the same page.
The reason I am asking is that I have a use case where I need such a
mechanism.
What is the advantage you see for defining a new HTTP header over extending
RFC7239?
Regards,
Rifaat
On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell
wrote:
> I don't think
I don't think there's anything beyond defining something to carry the
client certificate information (including the format and encoding). And it
could well be a new RFC7239 parameter. Or it might just be a new HTTP
header on its own.
On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef
wrote:
>
Thanks Brian,
I guess my question is: given RFC7239 and the fact that it is
straightforward to secure the channel between the terminating reverse proxy
and the backend service in a cluster, is there anything, from a standard
perspective, that we need to do beyond defining a new parameter to carry
On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef
wrote:
>
> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell
> wrote:
>
>>
>> I did look at RFC7239 when doing that and it could have been made to work
>> but felt the fit wasn't quite right and would have been more cumbersome to
>> use than not.
On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell
wrote:
> Few thoughts, comments, & questions.
>
> I've always kind of assumed that the ship had already sailed on doing
> anything standards related with this because implementations out in the
> wild like Apache, NGNIX, IIS, etc. were already
Few thoughts, comments, & questions.
I've always kind of assumed that the ship had already sailed on doing
anything standards related with this because implementations out in the
wild like Apache, NGNIX, IIS, etc. were already providing ad hoc solutions
and had been doing so for a long time. But
42 matches
Mail list logo
