ftp-proxy and TLS

[Marc Peters]

Hi.

I set up a firewall with openbsd and pf. i activated ftp-proxy in
inetd.conf as follows:

127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy
ftp-proxy

my pf-rules regarding the ftp-proxy are looking like this:

rdr pass on sis0 inet proto tcp from any to any port = ftp -> 127.0.0.1
port 8021

pass in on tun0 proto tcp from any to (tun0) port > 49151 user = 71 keep
state

when i try to ftp everything is working fine. but when i try to connect
to a host, which is running proftpd with TLS activated, ftp-proxy cuts
off when TLS begins to work (IIRC after submitting the username the
engine starts).

/var/log/daemon has this in it:
Aug 18 23:47:46 losraidonos ftp-proxy[15467]: accepted connection from
XXX.XXX.XXX.XXX:34817 to XXX.XXX.XXX.XXX:21
Aug 18 23:47:51 losraidonos ftp-proxy[15467]: got NUL byte from client -
bye!

i tested this with a linux-client from the internal-net, which is
capable of ftps.
is ftp-proxy capable of this too? do i need any options in inetd to
start ftp-proxy with? i looked through the man page, but didn't found
anything.
i know from squid, that it just lets the traffic through without
touching it, if it recognizes a encrypted link (SSL for instance).

TIA,
marc

[Henning Brauer]

Post by Marc Peters
when i try to ftp everything is working fine. but when i try to connect
to a host, which is running proftpd with TLS activated, ftp-proxy cuts
off when TLS begins to work

ftp-proxy does not support TLS.
moreover, when you think about it, ftp w/TLS encrypts the control
channel, it's the entire point that 3rd parties (like ftp-proxy) can't
see or modify what's gpoing on, so this cannot possibly work.

[Toni Mueller]

Hi,

Post by Henning Brauer
ftp-proxy does not support TLS.

ok.

Post by Henning Brauer
moreover, when you think about it, ftp w/TLS encrypts the control
channel, it's the entire point that 3rd parties (like ftp-proxy) can't
see or modify what's gpoing on, so this cannot possibly work.

I can't see why this must be so. HTTPS can be proxied with Squid which
"somehow" handles the crypto stuff after reading the client's "CONNECT
...", and digging into FTP+SSL suggests that the control channel could
be used to break end-to-end encryption into two pieces, originating or
terminating at the gateway machine. Eg. the client says "AUTH TLS" to
start negotiating SSL...


Best,
--Toni++

[Spruell, Darren-Perot]

Post by Henning Brauer

Post by Henning Brauer
moreover, when you think about it, ftp w/TLS encrypts the control
channel, it's the entire point that 3rd parties (like

ftp-proxy) can't

Post by Henning Brauer
see or modify what's gpoing on, so this cannot possibly work.

I can't see why this must be so. HTTPS can be proxied with Squid which
"somehow" handles the crypto stuff after reading the client's "CONNECT
...", and digging into FTP+SSL suggests that the control channel could
be used to break end-to-end encryption into two pieces, originating or
terminating at the gateway machine. Eg. the client says "AUTH TLS" to
start negotiating SSL...

But to my knowledge, squid has no idea what is happening inside of the HTTPS
session, since it is end-to-end encryption, and doesn't proxy the connection
like it does vanilla HTTP; i.e. it just passes the connection through and is
unable to do content inspection and so forth.

Similarly, how would ftp-proxy get around the same limitations? The client
will negotiate the TLS based on the certificate presented by the server; if
the FTP client is instead negotiating with ftp-proxy, it won't be carrying
on a conversation with the trusted certificate presenter. Part of the point
of the TLS security is to protect from MITM anyway.

Could be mistaken, but I think it just inherently isn't going to work.

DS

[Markus Wernig]

Toni Mueller wrote:

| I can't see why this must be so. HTTPS can be proxied with Squid which
| "somehow" handles the crypto stuff after reading the client's "CONNECT
| ...", and digging into FTP+SSL suggests that the control channel could
| be used to break end-to-end encryption into two pieces, originating or
| terminating at the gateway machine. Eg. the client says "AUTH TLS" to
| start negotiating SSL...

Hi

Squid is different. Usually, it doesn't do SSL itself, but just passes
the connection on.
With FTP the problem is that there's information exchanged over the
control channel that is used in establishing the data channel (esp. the
PORT command in active or the ip address + port tuple in passive mode).

You might be able to code around that by terminating two distinct
sessions on the gateway, and have the gateway read the data channel, but
then you would as well break authentication (i.e. certificates can't be
checked anymore as the proxy needs to present its own certs and accept
the original client's and server's ones). And if there's a stateful
firewall or other stateful device between the proxy and server, it'll
just not know the ports negotiated on the control channel and drop the
data channel even if configured to allow ftp (except for the rare case
where a firewall admin will have opened ports 1024-65536).

Plus, afaik there'n no provision in the FTP protocol for proxied
connections, but that problem isn't specific to ssl'ed connections.

[Toni Mueller]

Hi,

Post by Markus Wernig
Squid is different. Usually, it doesn't do SSL itself, but just passes
the connection on.

it does, however, talk SSL to the outside server.

Post by Markus Wernig
You might be able to code around that by terminating two distinct
sessions on the gateway, and have the gateway read the data channel,

I dimly remember reading about devices which proceed like that. While
I agree that these break parts of end-to-end security, they are touted
to put an end to corporate espionage and malware infiltration over
channels where you otherwise have no way of protecting your network (it
would be just too easy to put malware on an SSL-secured site and avoid
any virus scanners etc). I am also a bit undecided about the usefulness
of such devices. Eg. I like to have my borders secured by OpenBSD, but
I also like to have FTP access secured by SSL, thus making
password-sniffing a bit more difficult. Having to chose between no
firewall at the border on the one side and no SSL on the FTP server on
the other is no satisfacory answer.


Best,
--Toni++

[Simon Farnsworth]

Post by Toni Mueller
Hi,

Post by Markus Wernig
Squid is different. Usually, it doesn't do SSL itself, but just passes
the connection on.

it does, however, talk SSL to the outside server.

Not normally. The standard HTTPS conversation from Squid's point of view is:

<client connects to proxy>
<client sends>CONNECT www.openbsd.org:443 HTTP/1.1
<client sends>Host: www.openbsd.org:443
<squid connects to TCP port 443 of host www.openbsd.org>
<squid sends>200 OK
<squid sees data flowing through the tunnel, and has no idea what it is, or
even if it's SSL>

For all Squid knows, you're not using SSL at all; you could just be sending
plain HTTP. You can confirm this by running a server on TCP port 443 that's
not SSL (e.g. SSH, or even telnet); if you then go through the CONNECT
malarky, you'll get through to the remote server despite the complete lack of
SSL.

Further, SSL is designed to stop a proxy in the middle from eavesdropping. If
you manage to do so, you've broken SSL, and it's basically useless for most
purposes (there is no technical difference between your "authorised" proxy
sniffing the traffic to do good things like FTP proxying of FTP+SSL, and my
unauthorised proxy sniffing the traffic to get your online banking details).

There's only two ways to get FTP+SSL past a firewall that would otherwise
filter it:

1) Drop firewalling for a range of ports used for FTP+SSL connections. For
example, open 65000-65535 for incoming, and configure your endpoints to listen
there (clients in the case of active FTP, servers in the case of passive).
2) Write a man-in-the-middle proxy, that talks FTP+SSL to the remote end,
decrypts it, then talks FTP+SSL to the local end. The local end then needs to
be configured to accept the proxy's certificate for everything, and can't
validate the remote certificate (it has to trust the proxy to do that).

Both are problematic, which is why SFTP was invented.
--
Simon Farnsworth

[demime 1.01d removed an attachment of type application/pgp-signature]

[Markus Wernig]

Toni Mueller wrote:
| Hi,
|
| On Thu, 01.09.2005 at 19:29:57 +0200, Markus Wernig
<***@wernig.net> wrote:
|
|>Squid is different. Usually, it doesn't do SSL itself, but just passes
|>the connection on.

| it does, however, talk SSL to the outside server.

No, the client does.
|
|
|>You might be able to code around that by terminating two distinct
|>sessions on the gateway, and have the gateway read the data channel,
|
|
[...] I am also a bit undecided about the usefulness
| of such devices.
Erm ... wasn't it you to suggest "that the control channel could
be used to break end-to-end encryption into two pieces, originating or
terminating at the gateway machine"? As said above, it would be
technically feasible.

| Eg. I like to have my borders secured by OpenBSD, but
| I also like to have FTP access secured by SSL, thus making
| password-sniffing a bit more difficult. Having to chose between no
| firewall at the border on the one side and no SSL on the FTP server on
| the other is no satisfacory answer.
|
Hmm, considered using sftp?

The main reason why FTPS hasn't been adopted as a standard like FTP is
actually the fact that it kept to FTP's original design (separate
control and data connection, dynamic port allocation) while introducing
encryption, which is still fine if there are no stateful devices in the
path. It simply doesn't work anymore in the internet of today.
Take away the concept of splitting control and data over two distinct
TCP sessions, and FTPS will probably see the same success as FTP.
<rant>As to the reasons why FTP uses the design it does, the only thing
that comes to my mind right now is shortcomings in the network stacks of
the systems of that time like - say - the absence of the "select" or
"fork" system calls or of other multiplexing capabilities.
</rant> But I suppose there were better reasons which I simply can't
envision at the time :-)

/m

[Kevin]

Post by Simon Farnsworth
There's only two ways to get FTP+SSL past a firewall that would otherwise
1) Drop firewalling for a range of ports used for FTP+SSL connections. For
example, open 65000-65535 for incoming, and configure your endpoints to listen
there (clients in the case of active FTP, servers in the case of passive).
2) Write a man-in-the-middle proxy, that talks FTP+SSL to the remote end,
decrypts it, then talks FTP+SSL to the local end. The local end then needs to
be configured to accept the proxy's certificate for everything, and can't
validate the remote certificate (it has to trust the proxy to do that).

2b) Use TLSWrap, http://tlswrap.sunsite.dk/
To quote the web site "TLSWrap is a TLS/SSL FTP wrapper/proxy for UNIX
and Windows, allowing you to use your favourite FTP client with any
TLS/SSL-enabled FTP server. "

Basically, this does cleartext FTP on the inside and talks TLS to the Internet.

Kevin Kadow

[Toni Mueller]

Hi,

Post by Markus Wernig
[...] I am also a bit undecided about the usefulness
| of such devices.
Erm ... wasn't it you to suggest "that the control channel could
be used to break end-to-end encryption into two pieces, originating or
terminating at the gateway machine"? As said above, it would be
technically feasible.

yes, I said that that is the idea I have about how to do it. The remark
about the "usefulness" was directed towards the implicit break of trust
from the client's perspective because, as someone else already said,
the client has to trust the proxy for everything (and checking
certificates would need to be part of the proxy).

Post by Markus Wernig
Hmm, considered using sftp?

Hmmm... not quite. The "usual" application I had in mind when talking
about this is people updating their web sites on some servers which
offer (or enforce) FTP+SSL, and where I control only one end, not the
other.


Best,
--Toni++