Re: [ftpext] Firewalls & FTP over TLS.

["Mark P. Peterson" <[e-mail]>]

Hi Alun,

I just have a couple comments regarding your SFTP comments.

> The "SFTP is a standard" complaint is galling, because of course, SFTP is
> not a documented standard, and pretty much requires reverse engineering in
> order to make it work.

What are the drafts drafted by J. Galbraith (VanDyke Software) and O. Saarenmaa
(F-Secure)?  I've been able to follow these drafts for each SFTP version from 3-6.
It isn't easy, but it is possible and doesn't require a lot of reverse engineering at
all, just testing just like FTP.

> I've been trying to push this message - that SFTP is flakey compared to FTP
> over TLS simply because SFTP essentially relies on each server / client author
> making tweaks to have it work with those they test with, rather than coding to
> a unified standard like FTP over TLS.

Flakey?  How so?  I've implemented a server which supports SFTP and have had
better compatibility than I've seen with many FTPS clients.  If one follows the
documentation to the letter and tests with several clients, they all seem to work
well.  Many clients base their code on putty, some implement their own, and
others rely on libraries.  Those based on putty usually exhibit the same behavior.

> Maybe that's not a problem for those of you with SFTP capabilities in your
> servers, but personally, I don't find that I want to implement an undocumented
> standard.

It's well documented, just not yet an RFC.  Sure the draft is expired but both
clients and servers have adopted the protocol widely and is in heavy use in the
Linux world.  Each version is documented well, the last that I know of is draft 13
which documents the latest version 6 of the protocol:

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

Since it is so widely adapted, why can't it become an RFC?

> The "Can't make FTP over TLS work through a NAT / firewall" is irritating
> too, partly because it seems to be mostly true. ....

Yes, and all the more reason to use a protocol that is easier for end-users to
implement, configure, and to use.  They are the reason we do what we do.

> Again, SFTP wins out here, because it works over one port, and one port only
> - although opening up port 22 (SSH) essentially says "allow anything",
> because SSH is used as a tunnel for multiple random protocols as well as SSH
> and SFTP.

Right, so let end-users make the choice what they want available via port 22 and
SSH2.

> Well, I've said it before, and got absolutely no response, so I'm asking
> again - why don't we use the default port as defined in RFC 959 and before?

IMO it's because FTP has been around so long and because FTP is implemented
on so many platforms, many of which are no longer being developed.  Most
implementations stick with the basics of 959, plain and simple (that goes for both
the client and server).

> So, who else supports MODE B for firewall / NAT traversal?

I am sorry to say I haven't had a chance looking at MODE B.  I can say your
distaste for SFTP, however, is at the very least intriguing.  It is a good
protocol, with some faults, yes, but they can be much more easily
addressed than with FTP.

Mark P. Peterson - President
http://www.RhinoSoft.com
Voice: [phone]
FAX: [phone]  



From: Alun Jones 
Sent: Thursday, December 23, 2010 9:55 PM
To: [e-mail] 
Subject: [ftpext] Firewalls & FTP over TLS.


I frequently find I have a hard time selling my FTP server into environments that are looking for a secure and standard file transfer server.

 

Not because it's not a good and standard implementation of FTP over TLS - I've found it to work very well with numerous clients.

 

The failure is twofold - one, because the perceived "standard" for this is SFTP, and two, because of the headache of getting FTP (and particularly FTP over TLS) to work through a firewall.

 

The "SFTP is a standard" complaint is galling, because of course, SFTP is not a documented standard, and pretty much requires reverse engineering in order to make it work. I've been trying to push this message - that SFTP is flakey compared to FTP over TLS simply because SFTP essentially relies on each server / client author making tweaks to have it work with those they test with, rather than coding to a unified standard like FTP over TLS. Maybe that's not a problem for those of you with SFTP capabilities in your servers, but personally, I don't find that I want to implement an undocumented standard.

 

The "Can't make FTP over TLS work through a NAT / firewall" is irritating too, partly because it seems to be mostly true. In MODE S, TYPE I transfers, the PORT command or PASV response have to be filtered and altered to open a port and/or change the IP address to make the connection work. The alternative is to open a wide swath of ports at the firewall, which security teams shy away from, and in many companies, outright prohibit.

 

Again, SFTP wins out here, because it works over one port, and one port only - although opening up port 22 (SSH) essentially says "allow anything", because SSH is used as a tunnel for multiple random protocols as well as SSH and SFTP. It would be really nice if FTP could work over predictable port numbers, especially if they were already opened by the firewall's usual operation.

 

Well, I've said it before, and got absolutely no response, so I'm asking again - why don't we use the default port as defined in RFC 959 and before?

 

An FTP (or FTP over TLS) client connecting from port U to port L and sending a RETR or STOR command (or equivalent) without a PORT or PASV (or EPRT, EPSV, etc) command will cause the server to connect from server port L-1 to client port U, and because of the nature of firewalls, they will generally have opened a hole (server:any => client:U) already.

 

Great, that works for the first transfer, because in MODE S, you close the TCP data connection to indicate the end of a transfer, and can't open a new socket (server:L-1 => client:U) for another two to four minutes.

 

Again, there's already an RFC 959 way of getting around this - instead of using MODE S, use MODE B. Then, although there's a slight penalty in terms of the chunk markers and restart markers, there's no issue with closing and re-opening connections in rapid-fire transfers of small files or directory listings, and it gets through a firewall and a NAT quite happily without having to provide external IP address mappings, UPNP, or large firewall holes.

 

While I've been able to test this with my own crappy test client (WFTPD Client hasn't had enough work put into it to be really good), it would be great to see this supported across multiple FTP clients and servers. IIS FTP server already supports MODE B, but I don't really have any idea as to how wide-spread support for MODE B is, or what features clients and servers expect to see, or get confused by. I know that one failing in my own server is a lack of support for restart markers (although it currently works if you specify byte counts, as if it was in MODE S).

 

Another thing that needs discussing for MODE B support is how ABOR should work - that's not exactly clear, either.

 

So, who else supports MODE B for firewall / NAT traversal?

 

Alun.

~~~~



--------------------------------------------------------------------------------


_______________________________________________
ftpext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ftpext