You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by CJ Ess <zx...@gmail.com> on 2015/05/03 02:15:29 UTC
ATS & Socks Support
I've spent some time looking into the SOCKs support in ATS (or maybe former
SOCKS support is more accurate)
SOCKS support is present in every ATS. The define that enables it is Here
<https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/I_Socks.h#L31>,
There
isn't an option to switch it on or off in configure.
Its not documented in recent ATS versions but you can piece together
information from Here
<http://mail-archives.apache.org/mod_mbox/trafficserver-users/201411.mbox/%3CCAE2_gsVvj=UJqEPYfEDxpUg_cp+dhs2_9oEeNmVNOeH6YFL=FQ@mail.gmail.com%3E>
, Here
<https://www.websense.com/content/support/library/web/v76/wcg_help/sokpvars.aspx>
, and Here <https://gist.github.com/piotrbulinski/9396189>. And there is an
open Jira to update the documentation Here
<https://issues.apache.org/jira/browse/TS-2513>
Once you get past that its really tough to trigger the code - I added these
entries to records.config:
CONFIG proxy.config.socks.socks_needed=1
CONFIG proxy.config.socks.default_servers=<socks_server_ip>:<socks_port>
And for added measure I added this line to socks.config:
dest_ip=0.0.0.0-255.255.255.255 parent="<socks_server_ip>:<socks_port>"
However, none of those items seemed to have any effect - all the outgoing
traffic from ATS still went direct, there were no connections to the socks
server. Eventually I resorted to forcing ATS to select the socks path Here
<https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/UnixNetProcessor.cc#L202>
.
It turns out that the socks code has issues with IPV6, and even if your not
using IPV6 but are on a host with IPV6 capability you fail an assert Here
<https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/Socks.cc#L65>.
And I'm not the first one to find that, see Here
<https://issues.apache.org/jira/browse/TS-2482>
And if you work around that then you eventually segfault (not sure where in
the code):
traffic_server: Segmentation fault (Address not mapped to object
[0x24])traffic_server - STACK TRACE:
/home/me/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac079]
/lib64/libpthread.so.0[0x38e340f710]
/home/me/ats/bin/traffic_server(_ZN18ParentConfigParams10findParentEP15HttpRequestDataP12ParentResult+0x28)[0x4e0f38]
/home/me/ats/bin/traffic_server(_ZN10SocksEntry10findServerEv+0x15a)[0x74118a]
/home/me/ats/bin/traffic_server(_ZN10SocksEntry4initEP10ProxyMutexP18UnixNetVConnectionhh+0x855)[0x742605]
It looks like the core issue is with how ATS selects the outgoing address
of Socks connections. Socks5 technically supports IPV6, but socks4/4a does
not, so when resolving names for Socks only IPv4 addresses should be
considered. However, most socks servers are capable of doing their own name
resolution and TOR (probably the most popular thing using socks right now)
would prefer to do its own name resolution, so the best solution might be
to pass through FQDNs which is supported by socks 4a and 5. Beyond that the
address we are connecting to is the address of the socks server and I don't
think that is being resolved for some reason.
BTW, the current SOCKS support hard codes the authorization parameters of
the socks server and thats probably sufficient for one person behind a
proxy, However, for more then one person behind a -caching- proxy that
probably not sufficient, if the server needs authorization we should
probably pass through the username:password from the Proxy-Authorization
details or return the client a 407 if not present/declined.
It looks like the closest anyone has come to fixing socks in recent times
was Here <https://issues.apache.org/jira/browse/TS-803>, I'm not sure how
his fix worked or if its still appropriate for the current ATS.
I'm hoping that there is enough here that someone more seasoned would be
inspired to look into it. I'll continue to look at it but I'm not familiar
with the code base so it could be a while before I can contribute much more
then analysis.
Re: ATS & Socks Support
Posted by CJ Ess <zx...@gmail.com>.
Good news! I have a fix for the wrong address issue and I've been
successful at opening a connection to the SOCKS proxy and getting a
response back. I can submit a patch as soon as I clean up my work.
However there are still some show stoppers - every SOCKS operation
(successful/unsuccessful) dies in an assert on a lock (stack trace below)
and it appears that with socks enabled there are some sort of ATS internal
connections to 127.0.0.1 that are now going to the proxy. There needs to be
some way to say those go direct. I think temporarily I could add 127/8 with
no_socks to socks.conf (plus that'll be a good way to see if that feature
still works)
On Sun, May 3, 2015 at 11:44 AM, CJ Ess <zx...@gmail.com> wrote:
> So I've worked with this a bit more and I've got it to the point that its
> reaching out to the socks server and making a request. The two issues I see
> now is that 1) any failure (server not up, server denies request, etc)
> results in a segv and 2) its requesting the wrong address from the server
> (it looks like ATS is requesting the IP/Port of its side of the connection
> to the socks server - which is how I know ATS will segv if the server
> denies the request)
>
>
> On Sat, May 2, 2015 at 8:15 PM, CJ Ess <zx...@gmail.com> wrote:
>
>> I've spent some time looking into the SOCKs support in ATS (or maybe
>> former SOCKS support is more accurate)
>>
>> SOCKS support is present in every ATS. The define that enables it is Here
>> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/I_Socks.h#L31>, There
>> isn't an option to switch it on or off in configure.
>>
>> Its not documented in recent ATS versions but you can piece together
>> information from Here
>> <http://mail-archives.apache.org/mod_mbox/trafficserver-users/201411.mbox/%3CCAE2_gsVvj=UJqEPYfEDxpUg_cp+dhs2_9oEeNmVNOeH6YFL=FQ@mail.gmail.com%3E>
>> , Here
>> <https://www.websense.com/content/support/library/web/v76/wcg_help/sokpvars.aspx>
>> , and Here <https://gist.github.com/piotrbulinski/9396189>. And there is
>> an open Jira to update the documentation Here
>> <https://issues.apache.org/jira/browse/TS-2513>
>>
>> Once you get past that its really tough to trigger the code - I added
>> these entries to records.config:
>> CONFIG proxy.config.socks.socks_needed=1
>> CONFIG proxy.config.socks.default_servers=<socks_server_ip>:<socks_port>
>> And for added measure I added this line to socks.config:
>> dest_ip=0.0.0.0-255.255.255.255 parent="<socks_server_ip>:<socks_port>"
>>
>> However, none of those items seemed to have any effect - all the outgoing
>> traffic from ATS still went direct, there were no connections to the socks
>> server. Eventually I resorted to forcing ATS to select the socks path
>> Here
>> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/UnixNetProcessor.cc#L202>
>> .
>>
>> It turns out that the socks code has issues with IPV6, and even if your
>> not using IPV6 but are on a host with IPV6 capability you fail an assert
>> Here
>> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/Socks.cc#L65>.
>> And I'm not the first one to find that, see Here
>> <https://issues.apache.org/jira/browse/TS-2482>
>>
>> And if you work around that then you eventually segfault (not sure where
>> in the code):
>> traffic_server: Segmentation fault (Address not mapped to object
>> [0x24])traffic_server - STACK TRACE:
>>
>> /home/me/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac079]
>> /lib64/libpthread.so.0[0x38e340f710]
>>
>> /home/me/ats/bin/traffic_server(_ZN18ParentConfigParams10findParentEP15HttpRequestDataP12ParentResult+0x28)[0x4e0f38]
>>
>> /home/me/ats/bin/traffic_server(_ZN10SocksEntry10findServerEv+0x15a)[0x74118a]
>>
>> /home/me/ats/bin/traffic_server(_ZN10SocksEntry4initEP10ProxyMutexP18UnixNetVConnectionhh+0x855)[0x742605]
>>
>> It looks like the core issue is with how ATS selects the outgoing address
>> of Socks connections. Socks5 technically supports IPV6, but socks4/4a does
>> not, so when resolving names for Socks only IPv4 addresses should be
>> considered. However, most socks servers are capable of doing their own name
>> resolution and TOR (probably the most popular thing using socks right now)
>> would prefer to do its own name resolution, so the best solution might be
>> to pass through FQDNs which is supported by socks 4a and 5. Beyond that the
>> address we are connecting to is the address of the socks server and I don't
>> think that is being resolved for some reason.
>>
>> BTW, the current SOCKS support hard codes the authorization parameters of
>> the socks server and thats probably sufficient for one person behind a
>> proxy, However, for more then one person behind a -caching- proxy that
>> probably not sufficient, if the server needs authorization we should
>> probably pass through the username:password from the Proxy-Authorization
>> details or return the client a 407 if not present/declined.
>>
>> It looks like the closest anyone has come to fixing socks in recent times
>> was Here <https://issues.apache.org/jira/browse/TS-803>, I'm not sure
>> how his fix worked or if its still appropriate for the current ATS.
>>
>> I'm hoping that there is enough here that someone more seasoned would be
>> inspired to look into it. I'll continue to look at it but I'm not familiar
>> with the code base so it could be a while before I can contribute much more
>> then analysis.
>>
>>
>>
>>
>
Re: ATS & Socks Support
Posted by CJ Ess <zx...@gmail.com>.
So I've worked with this a bit more and I've got it to the point that its
reaching out to the socks server and making a request. The two issues I see
now is that 1) any failure (server not up, server denies request, etc)
results in a segv and 2) its requesting the wrong address from the server
(it looks like ATS is requesting the IP/Port of its side of the connection
to the socks server - which is how I know ATS will segv if the server
denies the request)
On Sat, May 2, 2015 at 8:15 PM, CJ Ess <zx...@gmail.com> wrote:
> I've spent some time looking into the SOCKs support in ATS (or maybe
> former SOCKS support is more accurate)
>
> SOCKS support is present in every ATS. The define that enables it is Here
> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/I_Socks.h#L31>, There
> isn't an option to switch it on or off in configure.
>
> Its not documented in recent ATS versions but you can piece together
> information from Here
> <http://mail-archives.apache.org/mod_mbox/trafficserver-users/201411.mbox/%3CCAE2_gsVvj=UJqEPYfEDxpUg_cp+dhs2_9oEeNmVNOeH6YFL=FQ@mail.gmail.com%3E>
> , Here
> <https://www.websense.com/content/support/library/web/v76/wcg_help/sokpvars.aspx>
> , and Here <https://gist.github.com/piotrbulinski/9396189>. And there is
> an open Jira to update the documentation Here
> <https://issues.apache.org/jira/browse/TS-2513>
>
> Once you get past that its really tough to trigger the code - I added
> these entries to records.config:
> CONFIG proxy.config.socks.socks_needed=1
> CONFIG proxy.config.socks.default_servers=<socks_server_ip>:<socks_port>
> And for added measure I added this line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="<socks_server_ip>:<socks_port>"
>
> However, none of those items seemed to have any effect - all the outgoing
> traffic from ATS still went direct, there were no connections to the socks
> server. Eventually I resorted to forcing ATS to select the socks path Here
> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/UnixNetProcessor.cc#L202>
> .
>
> It turns out that the socks code has issues with IPV6, and even if your
> not using IPV6 but are on a host with IPV6 capability you fail an assert
> Here
> <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/Socks.cc#L65>.
> And I'm not the first one to find that, see Here
> <https://issues.apache.org/jira/browse/TS-2482>
>
> And if you work around that then you eventually segfault (not sure where
> in the code):
> traffic_server: Segmentation fault (Address not mapped to object
> [0x24])traffic_server - STACK TRACE:
>
> /home/me/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac079]
> /lib64/libpthread.so.0[0x38e340f710]
>
> /home/me/ats/bin/traffic_server(_ZN18ParentConfigParams10findParentEP15HttpRequestDataP12ParentResult+0x28)[0x4e0f38]
>
> /home/me/ats/bin/traffic_server(_ZN10SocksEntry10findServerEv+0x15a)[0x74118a]
>
> /home/me/ats/bin/traffic_server(_ZN10SocksEntry4initEP10ProxyMutexP18UnixNetVConnectionhh+0x855)[0x742605]
>
> It looks like the core issue is with how ATS selects the outgoing address
> of Socks connections. Socks5 technically supports IPV6, but socks4/4a does
> not, so when resolving names for Socks only IPv4 addresses should be
> considered. However, most socks servers are capable of doing their own name
> resolution and TOR (probably the most popular thing using socks right now)
> would prefer to do its own name resolution, so the best solution might be
> to pass through FQDNs which is supported by socks 4a and 5. Beyond that the
> address we are connecting to is the address of the socks server and I don't
> think that is being resolved for some reason.
>
> BTW, the current SOCKS support hard codes the authorization parameters of
> the socks server and thats probably sufficient for one person behind a
> proxy, However, for more then one person behind a -caching- proxy that
> probably not sufficient, if the server needs authorization we should
> probably pass through the username:password from the Proxy-Authorization
> details or return the client a 407 if not present/declined.
>
> It looks like the closest anyone has come to fixing socks in recent times
> was Here <https://issues.apache.org/jira/browse/TS-803>, I'm not sure how
> his fix worked or if its still appropriate for the current ATS.
>
> I'm hoping that there is enough here that someone more seasoned would be
> inspired to look into it. I'll continue to look at it but I'm not familiar
> with the code base so it could be a while before I can contribute much more
> then analysis.
>
>
>
>