Hi Yoav,
Hi Brian, Valery
FTP comes in two varieties: active and passive.
True.
There is no issue in passive mode FTP with tcpinc, as the client opens all
the connections.
Not quite. For an active mode there is an issue if client is behind NAT.
For a passive mode there is an issue if server is behind NAT.
(Well, it's true that in passive mode client opens all connections, but
server still indicates the address and port the client should connect
to for data transfer in the control connection, and if the server is behind
NAT then
these values need to be adjusted by NAT). I admit that the situation
when server is behind NAT is more rare, than when client is behind NAT,
but it is not uncommon. Consider home network connected to the Internet
via ISP's NAT with FTP server installed that is accessible from the
internet.
Nowdays this setup is supported by most "off shelf" routers and
there are plenty of free dynamic DNS services that solve
the problem of non-staticness of IP address of the server.
For active, there is an issue with using tcpinc on the control connection,
but no issue for the data connection.
True. But note. that control connection transmits user name and password,
that may be of interest for attacker (unless it is anonymous ftp).
AFAIK (and according to Wikipedia) browsers implement passive FTP so
clicking on ftp:// links will work with tcpinc.
Agree. But there are many standalone clients that don't support passive mode
or don't use it by default. Moreover, some applications use ftp internally
(for example to get updates) and user often has no means to change the way
they do it.
Regards,
Valery.
Yoav
On Aug 21, 2014, at 10:41 AM, Brian Trammell <[email protected]> wrote:
> Hi Valery,
>
> Good points, all.
>
> Devil's advocate position: why not deprecate FTP for all deployments
> where security is at all important? Its design does not lend itself to
> operation without cleartext, and at the moment I can't think of an
> application for FTP for which there are not deployed and tested
> alternatives (e.g. scp, https) without the ports-in-cleartext drawback.
> Now, deprecating a protocol won't make it disappear, but we can
> certainly put a big warning sticker on it: "does not work with tcpinc,
> here are alternatives that do."
>
> > Seems to me that any attempt to solve this with protocol design (your
> > points 4, 5, 6) will replace one set of brittle corner cases with a
> more complex set of brittle corner cases. Best to admit it FTP doesn't
> work in an opportunistic-security* world and move on.
>
> Cheers,
>
> Brian
>
> Sent from my iPhone
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
