Discussion:
[DISCUSS] Following redirects to 'localhost'
Derek Dagit
2018-08-06 21:48:07 UTC
Permalink
ATS can be configured such that when it receives a redirect (3xx) response
from an origin server, it will follow the redirect itself rather than
return the response to the client.

Consider the scenario when the redirect response contains a Location header
field with a destination of localhost.

In a forward-proxy scenario, where the origin server is "outside" the
network, redirects to the localhost are not desirable.

In the reverse-proxy scenario, where the origin server is "inside" the
network, redirects to localhost are generally not desirable either.
Exceptions to this might be when the origin serves requests from the same
host as the proxy, and as a convenience when writing functional tests such
that they can exercise redirect following without the need for a local DNS
setup.



We are considering changing the default behavior to stop following any
redirect when its destination is localhost (or its variants) when following
of redirects has been enabled.

A config would be added, with noticeable warnings, that would enable the
former behavior and allow redirects to be followed to localhost.



1. Does this seem like a good change to make?

2. How we would handle the redirect-to-localhost case under the new
behavior. Should we return a 403? A 500? Or should we return the redirect
response back to the client as-is?

3. Should we add a way to configure a sort of policy for when to follow
redirects and what response to return on no-follow, or should we have a
simple config boolean value and a standard behavior?


Looking forward to your input,
--
Derek
Alan Carroll
2018-08-06 22:50:10 UTC
Permalink
1. Yes.

2. I think a 403

3. We can add more sophisticated configuration later, if there turns out to
be a need.
Post by Derek Dagit
ATS can be configured such that when it receives a redirect (3xx) response
from an origin server, it will follow the redirect itself rather than
return the response to the client.
Consider the scenario when the redirect response contains a Location header
field with a destination of localhost.
In a forward-proxy scenario, where the origin server is "outside" the
network, redirects to the localhost are not desirable.
In the reverse-proxy scenario, where the origin server is "inside" the
network, redirects to localhost are generally not desirable either.
Exceptions to this might be when the origin serves requests from the same
host as the proxy, and as a convenience when writing functional tests such
that they can exercise redirect following without the need for a local DNS
setup.
We are considering changing the default behavior to stop following any
redirect when its destination is localhost (or its variants) when following
of redirects has been enabled.
A config would be added, with noticeable warnings, that would enable the
former behavior and allow redirects to be followed to localhost.
1. Does this seem like a good change to make?
2. How we would handle the redirect-to-localhost case under the new
behavior. Should we return a 403? A 500? Or should we return the redirect
response back to the client as-is?
3. Should we add a way to configure a sort of policy for when to follow
redirects and what response to return on no-follow, or should we have a
simple config boolean value and a standard behavior?
Looking forward to your input,
--
Derek
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
Leif Hedstrom
2018-08-06 23:16:37 UTC
Permalink
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location as is (i.e. retain the redirect), following redirects is a little unorthodox. Maybe since we are adding new configuration(s), maybe make it such that the behavior can be configurable either way?

Depending on if we add another configuration, or add on to the existing one, I’m thinking something in the line of

0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost


My vote would be for 1) to be the default, but I can live with 2) as well.

Question: The notion of “localhost” is a little vague here… I think there’s a number of other ways to reach “localhost”, rather than just localhost/127.0.0.1:

1) FQDNs
2) One of the possibly many IPs that are local to the box, including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)

I think there are many ways that someone could make a follow redirect loop back to itself, or a peering proxy.

Cheers,

— Leif
Derek Dagit
2018-08-07 00:25:14 UTC
Permalink
1. Yep

2. I see multiple possible answers as well...

3. ... and the 0,1,2-style config having either default sounds OK.

Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location as
is (i.e. retain the redirect), following redirects is a little unorthodox.
Maybe since we are adding new configuration(s), maybe make it such that the
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as well.
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect loop
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
Alan Carroll
2018-08-07 13:43:36 UTC
Permalink
I think it obvious the ultimate check should be "is the upstream address a
loopback address?". Textual comparisons are going to get hacked, we must
check the actual IP address that will be used.
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
.INVALID>
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location as
is (i.e. retain the redirect), following redirects is a little
unorthodox.
Post by Leif Hedstrom
Maybe since we are adding new configuration(s), maybe make it such that
the
Post by Leif Hedstrom
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as
well.
Post by Leif Hedstrom
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect
loop
Post by Leif Hedstrom
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
Alan Carroll
2018-08-07 13:44:51 UTC
Permalink
If you want to get fun, extend "ip_allow.config" to control what redirects
can be followed :-).
Bryan Call
2018-08-22 18:04:55 UTC
Permalink
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add non-routable IPs to the list too. I would create a configuration option called proxy.config.http.redirect_enabled and start with 0 as off and set proxy.config.http.number_of_redirections to 1 as the default.

When checking for localhost you should resolve the ip and check to see if it matches any of the IPs on the server. That could be a long list if there servers has many IP aliases. This still doesn’t block IPs used by other servers in the same network.

-Bryan
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location as
is (i.e. retain the redirect), following redirects is a little unorthodox.
Maybe since we are adding new configuration(s), maybe make it such that the
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as well.
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect loop
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
Derek Dagit
2018-08-22 18:37:39 UTC
Permalink
Post by Bryan Call
2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of how it
resolves?

This is why I went with "Return" by default rather than "Reject".
Post by Bryan Call
3. I like Lief’s proposal.
OK I can renumber the config values if necessary.
Post by Bryan Call
You might want to add another option to add non-routable IPs to the list
too.

We do prevent connections to the ANY address 0.0.0.0 globally in ATS
already (redirect or not). I can look at adding additional checks for
non-routable addresses.
Post by Bryan Call
I would create a configuration option called proxy.config.http.redirect_enabled
and start with 0 as off and set proxy.config.http.number_of_redirections to
1 as the default.

We have recently removed this config, seeing as it is redundant with
number_of_redirections. Are you proposing we bring this config back with a
new meaning and use it to configure the Follow/Reject/Return behavior?

Setting it to 0 according to Leif's proposal would default to the current
behavior, which we are saying is not recommended. Is this what you suggest
or were you thinking Reject or Return should be the default?
Post by Bryan Call
When checking for localhost you should resolve the ip and check to see if
it matches any of the IPs on the server.

OK will look at this too. I am not sure there is a good solution to handle
other servers or VIPs where the VIP is not mapped to a loop-back interface.
(If the VIP is mapped to the loopback, then this is covered by checks for
loopback. If it is not mapped to loopback, then I am not sure how we can
know to treat it specially aside from an additional config—and that starts
to sound like maybe a plugin should be handling such things.)



Thanks for the input. I'm fine with changing it.

The current Pull Request is up, but keeping the discussion here until we
settle on what we want to do.
https://github.com/apache/trafficserver/pull/4145
Post by Bryan Call
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add
non-routable IPs to the list too. I would create a configuration option
called proxy.config.http.redirect_enabled and start with 0 as off and set
proxy.config.http.number_of_redirections to 1 as the default.
When checking for localhost you should resolve the ip and check to see if
it matches any of the IPs on the server. That could be a long list if
there servers has many IP aliases. This still doesn’t block IPs used by
other servers in the same network.
-Bryan
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
INVALID>
Post by Derek Dagit
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location
as
Post by Derek Dagit
Post by Leif Hedstrom
is (i.e. retain the redirect), following redirects is a little
unorthodox.
Post by Derek Dagit
Post by Leif Hedstrom
Maybe since we are adding new configuration(s), maybe make it such that
the
Post by Derek Dagit
Post by Leif Hedstrom
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as
well.
Post by Derek Dagit
Post by Leif Hedstrom
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect
loop
Post by Derek Dagit
Post by Leif Hedstrom
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
--
Derek
Bryan Call
2018-08-23 23:19:14 UTC
Permalink
Inline

-Bryan
Post by Derek Dagit
Post by Bryan Call
2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of how it
resolves?
This is why I went with "Return" by default rather than "Reject".
Sounds good, that is what we are doing now with n+1.
Post by Derek Dagit
Post by Bryan Call
3. I like Lief’s proposal.
OK I can renumber the config values if necessary.
Post by Bryan Call
You might want to add another option to add non-routable IPs to the list
too.
We do prevent connections to the ANY address 0.0.0.0 globally in ATS
already (redirect or not). I can look at adding additional checks for
non-routable addresses.
Post by Bryan Call
I would create a configuration option called proxy.config.http.redirect_enabled
and start with 0 as off and set proxy.config.http.number_of_redirections to
1 as the default.
We have recently removed this config, seeing as it is redundant with
number_of_redirections. Are you proposing we bring this config back with a
new meaning and use it to configure the Follow/Reject/Return behavior?
Yes, if it is being enabled for different modes I would think it would be best to have it under and enabled option, This is how some other configuration options are done (e.g. proxy.config.log.logging_enabled).
Post by Derek Dagit
Setting it to 0 according to Leif's proposal would default to the current
behavior, which we are saying is not recommended. Is this what you suggest
or were you thinking Reject or Return should be the default?
Post by Bryan Call
When checking for localhost you should resolve the ip and check to see if
it matches any of the IPs on the server.
OK will look at this too. I am not sure there is a good solution to handle
other servers or VIPs where the VIP is not mapped to a loop-back interface.
(If the VIP is mapped to the loopback, then this is covered by checks for
loopback. If it is not mapped to loopback, then I am not sure how we can
know to treat it specially aside from an additional config—and that starts
to sound like maybe a plugin should be handling such things.)
Thanks for the input. I'm fine with changing it.
The current Pull Request is up, but keeping the discussion here until we
settle on what we want to do.
https://github.com/apache/trafficserver/pull/4145
Post by Bryan Call
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add
non-routable IPs to the list too. I would create a configuration option
called proxy.config.http.redirect_enabled and start with 0 as off and set
proxy.config.http.number_of_redirections to 1 as the default.
When checking for localhost you should resolve the ip and check to see if
it matches any of the IPs on the server. That could be a long list if
there servers has many IP aliases. This still doesn’t block IPs used by
other servers in the same network.
-Bryan
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
INVALID>
Post by Derek Dagit
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location
as
Post by Derek Dagit
Post by Leif Hedstrom
is (i.e. retain the redirect), following redirects is a little
unorthodox.
Post by Derek Dagit
Post by Leif Hedstrom
Maybe since we are adding new configuration(s), maybe make it such that
the
Post by Derek Dagit
Post by Leif Hedstrom
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as
well.
Post by Derek Dagit
Post by Leif Hedstrom
Question: The notion of “localhost” is a little vague here… I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect
loop
Post by Derek Dagit
Post by Leif Hedstrom
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
--
Derek
Derek Dagit
2018-08-24 01:52:57 UTC
Permalink
Thanks, working on it.
Post by Bryan Call
Inline
-Bryan
Post by Derek Dagit
Post by Bryan Call
2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of how
it
Post by Derek Dagit
resolves?
This is why I went with "Return" by default rather than "Reject".
Sounds good, that is what we are doing now with n+1.
Post by Derek Dagit
Post by Bryan Call
3. I like Lief’s proposal.
OK I can renumber the config values if necessary.
Post by Bryan Call
You might want to add another option to add non-routable IPs to the list
too.
We do prevent connections to the ANY address 0.0.0.0 globally in ATS
already (redirect or not). I can look at adding additional checks for
non-routable addresses.
Post by Bryan Call
I would create a configuration option called proxy.config.http.redirect_
enabled
Post by Derek Dagit
and start with 0 as off and set proxy.config.http.number_of_redirections
to
Post by Derek Dagit
1 as the default.
We have recently removed this config, seeing as it is redundant with
number_of_redirections. Are you proposing we bring this config back with
a
Post by Derek Dagit
new meaning and use it to configure the Follow/Reject/Return behavior?
Yes, if it is being enabled for different modes I would think it would be
best to have it under and enabled option, This is how some other
configuration options are done (e.g. proxy.config.log.logging_enabled).
Post by Derek Dagit
Setting it to 0 according to Leif's proposal would default to the current
behavior, which we are saying is not recommended. Is this what you
suggest
Post by Derek Dagit
or were you thinking Reject or Return should be the default?
Post by Bryan Call
When checking for localhost you should resolve the ip and check to see
if
Post by Derek Dagit
it matches any of the IPs on the server.
OK will look at this too. I am not sure there is a good solution to
handle
Post by Derek Dagit
other servers or VIPs where the VIP is not mapped to a loop-back
interface.
Post by Derek Dagit
(If the VIP is mapped to the loopback, then this is covered by checks for
loopback. If it is not mapped to loopback, then I am not sure how we can
know to treat it specially aside from an additional config—and that
starts
Post by Derek Dagit
to sound like maybe a plugin should be handling such things.)
Thanks for the input. I'm fine with changing it.
The current Pull Request is up, but keeping the discussion here until we
settle on what we want to do.
https://github.com/apache/trafficserver/pull/4145
Post by Bryan Call
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add
non-routable IPs to the list too. I would create a configuration option
called proxy.config.http.redirect_enabled and start with 0 as off and
set
Post by Derek Dagit
Post by Bryan Call
proxy.config.http.number_of_redirections to 1 as the default.
When checking for localhost you should resolve the ip and check to see
if
Post by Derek Dagit
Post by Bryan Call
it matches any of the IPs on the server. That could be a long list if
there servers has many IP aliases. This still doesn’t block IPs used by
other servers in the same network.
-Bryan
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
INVALID>
Post by Derek Dagit
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the Location
as
Post by Derek Dagit
Post by Leif Hedstrom
is (i.e. retain the redirect), following redirects is a little
unorthodox.
Post by Derek Dagit
Post by Leif Hedstrom
Maybe since we are adding new configuration(s), maybe make it such
that
Post by Derek Dagit
Post by Bryan Call
the
Post by Derek Dagit
Post by Leif Hedstrom
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the
existing
Post by Derek Dagit
Post by Bryan Call
Post by Derek Dagit
Post by Leif Hedstrom
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if
it’s
Post by Derek Dagit
Post by Bryan Call
Post by Derek Dagit
Post by Leif Hedstrom
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as
well.
Post by Derek Dagit
Post by Leif Hedstrom
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect
loop
Post by Derek Dagit
Post by Leif Hedstrom
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
--
Derek
--
Derek
Derek Dagit
2018-08-24 04:23:49 UTC
Permalink
OK I think we can converge on the PR now:
https://github.com/apache/trafficserver/pull/4145#issuecomment-415647049

I expect more iterations.
Post by Derek Dagit
Thanks, working on it.
Post by Bryan Call
Inline
-Bryan
Post by Derek Dagit
Post by Bryan Call
2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of
how it
Post by Derek Dagit
resolves?
This is why I went with "Return" by default rather than "Reject".
Sounds good, that is what we are doing now with n+1.
Post by Derek Dagit
Post by Bryan Call
3. I like Lief’s proposal.
OK I can renumber the config values if necessary.
Post by Bryan Call
You might want to add another option to add non-routable IPs to the
list
Post by Derek Dagit
too.
We do prevent connections to the ANY address 0.0.0.0 globally in ATS
already (redirect or not). I can look at adding additional checks for
non-routable addresses.
Post by Bryan Call
I would create a configuration option called
proxy.config.http.redirect_enabled
Post by Derek Dagit
and start with 0 as off and set proxy.config.http.number_of_redirections
to
Post by Derek Dagit
1 as the default.
We have recently removed this config, seeing as it is redundant with
number_of_redirections. Are you proposing we bring this config back
with a
Post by Derek Dagit
new meaning and use it to configure the Follow/Reject/Return behavior?
Yes, if it is being enabled for different modes I would think it would be
best to have it under and enabled option, This is how some other
configuration options are done (e.g. proxy.config.log.logging_enabled).
Post by Derek Dagit
Setting it to 0 according to Leif's proposal would default to the
current
Post by Derek Dagit
behavior, which we are saying is not recommended. Is this what you
suggest
Post by Derek Dagit
or were you thinking Reject or Return should be the default?
Post by Bryan Call
When checking for localhost you should resolve the ip and check to see
if
Post by Derek Dagit
it matches any of the IPs on the server.
OK will look at this too. I am not sure there is a good solution to
handle
Post by Derek Dagit
other servers or VIPs where the VIP is not mapped to a loop-back
interface.
Post by Derek Dagit
(If the VIP is mapped to the loopback, then this is covered by checks
for
Post by Derek Dagit
loopback. If it is not mapped to loopback, then I am not sure how we can
know to treat it specially aside from an additional config—and that
starts
Post by Derek Dagit
to sound like maybe a plugin should be handling such things.)
Thanks for the input. I'm fine with changing it.
The current Pull Request is up, but keeping the discussion here until we
settle on what we want to do.
https://github.com/apache/trafficserver/pull/4145
Post by Bryan Call
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add
non-routable IPs to the list too. I would create a configuration
option
Post by Derek Dagit
Post by Bryan Call
called proxy.config.http.redirect_enabled and start with 0 as off and
set
Post by Derek Dagit
Post by Bryan Call
proxy.config.http.number_of_redirections to 1 as the default.
When checking for localhost you should resolve the ip and check to see
if
Post by Derek Dagit
Post by Bryan Call
it matches any of the IPs on the server. That could be a long list if
there servers has many IP aliases. This still doesn’t block IPs used
by
Post by Derek Dagit
Post by Bryan Call
other servers in the same network.
-Bryan
Post by Derek Dagit
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above
works.
Post by Derek Dagit
Post by Bryan Call
Post by Derek Dagit
That might not be good enough for all deployments though.
INVALID>
Post by Derek Dagit
Post by Leif Hedstrom
Post by Alan Carroll
1. Yes.
Agreed.
Post by Alan Carroll
2. I think a 403
I can go either way. The HTTP way would be to just return the
Location
Post by Derek Dagit
Post by Bryan Call
as
Post by Derek Dagit
Post by Leif Hedstrom
is (i.e. retain the redirect), following redirects is a little
unorthodox.
Post by Derek Dagit
Post by Leif Hedstrom
Maybe since we are adding new configuration(s), maybe make it such
that
Post by Derek Dagit
Post by Bryan Call
the
Post by Derek Dagit
Post by Leif Hedstrom
behavior can be configurable either way?
Depending on if we add another configuration, or add on to the
existing
Post by Derek Dagit
Post by Bryan Call
Post by Derek Dagit
Post by Leif Hedstrom
one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if
it’s
Post by Derek Dagit
Post by Bryan Call
Post by Derek Dagit
Post by Leif Hedstrom
for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as
well.
Post by Derek Dagit
Post by Leif Hedstrom
Question: The notion of “localhost” is a little vague here
 I think
there’s a number of other ways to reach “localhost”, rather than just
1) FQDNs
2) One of the possibly many IPs that are local to the box,
including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect
loop
Post by Derek Dagit
Post by Leif Hedstrom
back to itself, or a peering proxy.
Cheers,
— Leif
--
Derek
--
Derek
--
Derek
--
Derek
Alan Carroll
2018-08-24 16:16:26 UTC
Permalink
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back the
old one, something like "proxy.config.,http.redirect.actions STRING".

The string would be of the format "tag[:action],tag[:action],...".

The tag would be one of the enumerations

* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.

The action must be one of

* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy response.

or omitted, in which case it is treated as "follow", although Derek would
prefer to require the action in all cases.

If a tag is omitted, it is treated as if it were "tag:return".

This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all other
redirects".
Bryan Call
2018-08-24 17:24:42 UTC
Permalink
I am OK with it. I would add a default tag, so you can specify what action to take by default if there is no match (e.g. routable:follow,default:reject).

-Bryan
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back the
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy response.
or omitted, in which case it is treated as "follow", although Derek would
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all other
redirects".
Derek Dagit
2018-08-24 18:31:42 UTC
Permalink
Sounds good let me take a look.
Post by Bryan Call
I am OK with it. I would add a default tag, so you can specify what
action to take by default if there is no match (e.g.
routable:follow,default:reject).
-Bryan
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back
the
Post by Alan Carroll
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy response.
or omitted, in which case it is treated as "follow", although Derek would
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all
other
Post by Alan Carroll
redirects".
--
Derek
Leif Hedstrom
2018-08-25 23:21:10 UTC
Permalink
Post by Derek Dagit
Sounds good let me take a look.
Post by Bryan Call
I am OK with it. I would add a default tag, so you can specify what
action to take by default if there is no match (e.g.
routable:follow,default:reject).
And we can make this overridable i hope?

— Leif
Post by Derek Dagit
Post by Bryan Call
-Bryan
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back
the
Post by Alan Carroll
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy response.
or omitted, in which case it is treated as "follow", although Derek would
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all
other
Post by Alan Carroll
redirects".
--
Derek
Derek Dagit
2018-08-27 17:45:29 UTC
Permalink
Leif, can we make this "overridable" in follow-on work?

This is a bit tricky because of custom parsing.
Post by Leif Hedstrom
Post by Derek Dagit
Sounds good let me take a look.
Post by Bryan Call
I am OK with it. I would add a default tag, so you can specify what
action to take by default if there is no match (e.g.
routable:follow,default:reject).
And we can make this overridable i hope?
— Leif
Post by Derek Dagit
Post by Bryan Call
-Bryan
INVALID>
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back
the
Post by Alan Carroll
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy
response.
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
or omitted, in which case it is treated as "follow", although Derek
would
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all
other
Post by Alan Carroll
redirects".
--
Derek
--
Derek
Leif Hedstrom
2018-08-27 19:57:49 UTC
Permalink
Post by Derek Dagit
Leif, can we make this "overridable" in follow-on work?
Sure.

— Leif
Post by Derek Dagit
This is a bit tricky because of custom parsing.
Post by Leif Hedstrom
Post by Derek Dagit
Sounds good let me take a look.
Post by Bryan Call
I am OK with it. I would add a default tag, so you can specify what
action to take by default if there is no match (e.g.
routable:follow,default:reject).
And we can make this overridable i hope?
— Leif
Post by Derek Dagit
Post by Bryan Call
-Bryan
INVALID>
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back
the
Post by Alan Carroll
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy
response.
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
or omitted, in which case it is treated as "follow", although Derek
would
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all
other
Post by Alan Carroll
redirects".
--
Derek
--
Derek
Derek Dagit
2018-09-17 15:51:03 UTC
Permalink
Post by Leif Hedstrom
Post by Derek Dagit
Leif, can we make this "overridable" in follow-on work?
Sure.
#4145 is merged.

Created https://github.com/apache/trafficserver/issues/4252 for the
"overridable" task.
Post by Leif Hedstrom
Post by Derek Dagit
Leif, can we make this "overridable" in follow-on work?
Sure.
— Leif
Post by Derek Dagit
This is a bit tricky because of custom parsing.
Post by Leif Hedstrom
Post by Derek Dagit
Sounds good let me take a look.
Post by Bryan Call
I am OK with it. I would add a default tag, so you can specify what
action to take by default if there is no match (e.g.
routable:follow,default:reject).
And we can make this overridable i hope?
— Leif
Post by Derek Dagit
Post by Bryan Call
-Bryan
INVALID>
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing
back
Post by Derek Dagit
Post by Leif Hedstrom
Post by Derek Dagit
Post by Bryan Call
the
Post by Alan Carroll
old one, something like "proxy.config.,http.redirect.actions
STRING".
Post by Derek Dagit
Post by Leif Hedstrom
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy
response.
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
or omitted, in which case it is treated as "follow", although Derek
would
Post by Derek Dagit
Post by Bryan Call
Post by Alan Carroll
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all
other
Post by Alan Carroll
redirects".
--
Derek
--
Derek
--
Derek
Loading...