FTP proxy chain with native ftp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

FTP proxy chain with native ftp

Sticher, Jascha
Hi,

we're currently upgrading our proxy environment to squid 3.5.23 (Debian Stretch) and would like to use the native FTP proxy feature to replace our old FTP proxy solution (frox).

Due to some design choices, we have a proxy hierarchy for HTTP as well as FTP traffic. Is there a way (yet) to tell my first squid instance to use another squid as a forward proxy with native FTP?

IIRC, the cache_peer directive always uses HTTP requests, so this seems as a dead end.



Mit freundlichen Grüßen / Kind regards,

Jascha Sticher

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: FTP proxy chain with native ftp

Alex Rousskov
On 12/12/2017 08:51 AM, Sticher, Jascha wrote:

> Is there a way (yet) to tell my first squid instance to use another squid as a forward proxy with native FTP?

> IIRC, the cache_peer directive always uses HTTP requests, so this seems as a dead end.

You are probably right. IIRC, the FTP client inside Squid does not
support FTP proxies. I am not aware of any work being done in that area.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: FTP proxy chain with native ftp

Amos Jeffries
Administrator
In reply to this post by Sticher, Jascha
On 13/12/17 04:51, Sticher, Jascha wrote:
> Hi,
>
> we're currently upgrading our proxy environment to squid 3.5.23 (Debian Stretch) and would like to use the native FTP proxy feature to replace our old FTP proxy solution (frox).
>
> Due to some design choices, we have a proxy hierarchy for HTTP as well as FTP traffic. Is there a way (yet) to tell my first squid instance to use another squid as a forward proxy with native FTP?
>
> IIRC, the cache_peer directive always uses HTTP requests, so this seems as a dead end.
>


The FTP traffic arriving at Squids ftp_port is converted from a stream
of FTP messages to a stream of HTTP messages for handling.

AFAIK those resulting HTTP messages can be routed through a cache_peer
same as any other HTTP traffic. BUT at very least the peer needs to also
have the same "native FTP" implementation to successfully convert them
from HTTP back to FTP native messages on the outgoing server connections
at the other side of the cache hierarchy.

There may be other internal state checks on the HTTP messages to make
them get the "native FTP" conversion on outgoing. So YMMV.

If the peer delivery does not work you may be required to do the same
workaround SSL-Bump sometimes requires. Do allow the front-end Squid to
re-FTP the traffic to the appropriate server then intercept it
independently into the backend with its own ftp_port accepting the
"native FTP" coming out of the frontend.

FYI: I do know there are conversion issues with FTP <-> HTTP
authentication recently uncovered and not yet resolved. So if you need
proxy auth at all staying with Frox would be better for now.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: FTP proxy chain with native ftp

Alex Rousskov
On 12/12/2017 09:56 AM, Amos Jeffries wrote:
> On 13/12/17 04:51, Sticher, Jascha wrote:
>> Is there a way (yet) to tell my first squid instance
>> to use another squid as a forward proxy with native FTP?


> The FTP traffic arriving at Squids ftp_port is converted from a stream
> of FTP messages to a stream of HTTP messages for handling.

> AFAIK those resulting HTTP messages can be routed through a cache_peer
> same as any other HTTP traffic.

I hope such routing is not possible today, but I do not know for sure.
AFAIK, no peer would be able to convert those wrapper HTTP messages back
into FTP. I hope the wrapper messages are always routed to FTP Client
code inside Squid using pinned Squid-FTP-server connections or something
like that.


> BUT at very least the peer needs to also
> have the same "native FTP" implementation to successfully convert them
> from HTTP back to FTP native messages on the outgoing server connections
> at the other side of the cache hierarchy.

* The "native FTP" Server implementation inside Squid does not convert
HTTP wrapper messages into FTP native messages. It converts FTP commands
into HTTP wrapper messages.

* The native FTP Client implementation inside Squid does the opposite
conversion, but it partners with the FTP Server implementation inside
Squid, not the HTTP Server implementation inside Squid.

* If wrapper HTTP messages reach a Squid peer, they will be handled by
the HTTP Server implementation inside peer Squid.

Thus, one cannot use another Squid to unwrap HTTP wrapper messages sent
by the child Squid, even if the routing code allows for those wrapper
messages to escape a Squid instance. The pieces required for everything
to work together are missing.


> Do allow the front-end Squid to
> re-FTP the traffic to the appropriate server then intercept it
> independently into the backend with its own ftp_port accepting the
> "native FTP" coming out of the frontend.

Good idea! Interception should work indeed. The "child" Squid will not
know what is going on, but both Squids will receive and send native FTP
traffic.


CHeers,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users