Does FTPS (FTP+S) offer better security than SFTP on the server side?

Question

I had an exchange with some third party sysadmin yesterday regarding the setup of a file transfer interface between our servers.

I suggested using SFTP because our application has good support for it. My interlocutor absolutely wants FTP+S (FTP+TLS) which we currently don't support and would need to develop.

I argued that I did not see any real benefit in FTP+S over SFTP since both offer solid traffic encryption. SFTP is readily available and can be made even more secure with public key authentification. Last but not least, its single connection mode makes it much nicer to use behind corporate firewalls.

The sysadmin almost called me an idiot, stating that SFTP works on top of SSH which is a protocol designed for administration purpose, and that opening a SSH port for any other use than administration is clearly a bad idea because it opens a broad attack vector against the host system.

I am wondering if this argument is valid. There seem to be various ways to restrict a SSH session to only allow SFTP file transfer. There is the internal-sftp subsystem that comes with openSSH, where you can easily set up a chroot and disable TCP forwarding. I even heard about solutions that presumably allow users to connect via SFTP without requiring an entry in the passwd file... I do not see any clear problem with SFTP that you would not have with FTP+S, but I could be missing something?

So, despite of the restrictions that you can apply to SSH, is FTP+S a better option for file transfers, security wise?

Answer 1

From the security they provide in theory FTPS and SFTP are similar. In practice you have the following advantages and disadvantages:

• With FTPS client applications often fail to validate the certificates properly, which effectively means man in the middle is possible. With SFTP instead users simply skip information about the host key and accept anything, so the result is the same.
• But users and admins with more knowledge could make use of SSH keys properly and use these also for authentication which then makes SFTP much easier to use compared to using passwords. And if passwords are forbidden at all then this is also more secure because brute force password attacks are no longer possible.
• FTP uses dynamic ports for data connections and information about these ports is transferred in-band. This makes already plain FTP (without TLS) a nightmare when firewalls, NAT or similar is involved. With FTPS (FTP+TLS) this gets even worse because due to the encryption of the control connection helper applications on the firewall can no longer find out which ports need to be opened. This means that to pass FTPS you would need to open a wide range of ports which is bad for security(*). SFTP is much better because it uses only a single connection for control and data.
• FTP(S) servers often provide anonymous access and SFTP servers usually don't. Several FTP(S) servers also offer pseudo users, i.e. users taken from same database or similar which are not real users on the system. If you have proper users only anyway this does not matter.
• SFTP uses the SSH protocol and you have to configure the system properly to only allow SFTP access and not also SSH (terminal) access or even SSH forwarding. With FTP this is easier because FTP can do only file transfer anyway.

(*) Several comments do not really believe that having a wide range of ports open is bad for security. Thus let me explain this in more detail:

• FTP uses separate TCP connections for data transfer. Which ports are used for these connection are dynamic and information about these gets exchanged inside the control connection. A firewall which does not know which ports are in use currently can only allow a wide port range which maybe will be used sometimes FTP.
• These ports need to allow access from outside to inside because in FTP passive mode the client connects to some dynamic port on the server (i.e. relevant for server side firewall) and for FTP active mode the server connects to some dynamic port on the client (relevant for client side firewall).
• Having a wide range of ports open for unrestricted access from outside to inside is not what somebody usually considers a restrictive firewall which protects the inside. This is more similar to having a big hole in the door where a burglar might come into the house.
• To work around this problem most firewalls employ "helpers" for FTP which look into the FTP control connection to figure out which ports need to be opened for the next data connection. One example is ip_conntrack_ftp for iptables. Unfortunately with FTPS the control connection is (usually) encrypted so these helpers are blind and cannot dynamically open the required ports. This means either FTP does not work or a wide range of ports need to be open all the time.

Answer 2

The sysadmin raises a valid point. (but his interpersonal skills might need work)

SSH is a complex protocol, and openssh implements a lot of functionality. All this functionality offers attack vectors, and it is very hard to be sure that none of these vectors are exploitable.

Even if openssh is without bugs (which it isn't), knowing about all the right possibilities to close off unwanted functionality, and understanding how these options might interact takes significant effort in itself. And these interactions might change from version to version.

As an example, consider the following sshd_config snippet, which has the intention of limiting certain users to SFTP-only (we even thought of locking them to their home directories):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

And sure enough:

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

But wait...

ssh -N -L 9000:localhost:80 somehost

Whoops, I now have forwarded port 80 on somehost to port 9000 on my host. That means we can connect to port 80 on somehost as if we are coming from localhost. Probably not a big deal for port 80, but what about services that only listen on localhost, such as administrative services or databases?

And that's just TCP forwarding. At the very least, SSH also allows X11 forwarding and SSH-agent forwarding, and I don't even know the implications of those two.

We do use ssh/sftp a lot, because for our situation the advantages outweigh these risks. But it is a valid concern that should not be taken too lightly. We ended up with this for use cases where just sftp is enough:

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp

We hope this is adequate to ensure just sftp access, but we can't be completely sure. (suggestions welcome ;)

Answer 3

Both protocols have advantages and disadvantages, as explained very well in this comparison article.

This said, since the question is specifically regarding security, there are a few considerations that should be taken into account when choosing which protocol is best in certain specific conditions.

FTPS and FTPES use SSL or TLS to encrypt the control/data connections. The main advantage of these secure channels is that they use X.509 certificates, which contain much more information that a simple key pair (host name, email address, organization name, the ISSUER (CA), ...) and are therefore a lot easier to validate. But:

• SSL 1.0, SSL 2.0: deprecated long time ago (insecure)
• SSL 3.0: recently deprecated because of POODLE
• TLS 1.0: no longer acceptable for PCI compliance
• TLS 1.1: lacks some of the extensions of TLS 1.2, and has limited client support, no reason to use it
• TLS 1.2: current standard, so far considered secure/safe

And the above only covers the channel(s) encryption protocol, then there are safety considerations regarding the FTP protocol itself. The SITE command, for example, has been used over and over to perpetrate attacks, and the inherent design of the protocol itself requires to open and NAT multiple ports on your firewall (which can become a nightmare to manage). Furthermore, most firewalls are not able to properly NAT FTP-data connections unless the client requests and the server allows CCC (Clear Control Channel) which defeats part of the security by running the control connection unencrypted.

On the other hand we have SFTP, which is a subsystem of SSH. The main challenge here is that SSH keys are "just keys", they are not issued by a CA and no issuer statement or key-chain is included in them, therefore SSH server keys have to be expressively trusted by the client.

Someone may argue that configuring an SSH server to only allow SFTP (no shell, no commands, no forwarding tunnels, no X11) may be difficult. That actually depends: if you're running Linux and OpenSSH that might be true, but there's a plethora of SSH/SFTP servers out there that make this kind of configuration a breeze, so I wouldn't necessarily list this as a potential flaw, unless - as I said - Linux/OpenSSH are used.

A couple remarkable side advantages of SFTP, though, include:

• ECDSA key exchange: a 521-bit ECDS(X) key is equivalent to a 15,360-bit RSA key in terms of security, and requires 9 times less CPU cycles for signature calculation
• Inherent forward secrecy: the SSH protocol can renegotiate the actual channel encryption key in-session, and provides inherent forward secrecy, as opposed to any SSL/TLS-enabled server that require additional configuration work to accomplish this

So, ultimately the choice is really up to you guys, but the argument that the sysadmin was making is blatantly invalid, and if there is an existing SFTP server that is well configured (as explained) then there is no reason (especially no security-related reason) to switch to FTPS (or FTPES).

Answer 4

Many people bring up valid points about the differences between the two protocols. But I think for your purposes, the question is really "Is SFTP Secure enough?" rather than "which one is more secure"?. As you've said, you have other concerns than simply security.

This turns out to be a difficult problem to solve. SSH has been used extensively and studied extensively. There's no known protocol design flaws. However, security vulnerabilities often have nothing to do with the protocol, and everything to do with the implementation. After all, SMTP itself isn't "insecure", and is relatively simple in design, but 16 years ago the commmon SendMail application was one of the poster children of badly implemented software security, and had hole after hole in it.

The point being, even if the protocol is well designed and simple, the implementation can be a rats nest of complexity, add on features, and security nightmares.

So I think this is more about choosing a good IMPLEMENTATION rather than a good protocol. Either protocol is fine, and either implementation can be poorly implemented.

I'm not entirely familiar with FTPS, so I don't know if there's any well respected implementations of it. For SSH however, OpenSSH is generally regarded as high quality, and was designed with security in mind from the ground up (privledge separation, etc).

Answer 5

Like you, I thought both were almost the same as I went through the web looking for their differences.

However, in real life, it is another story. Below was my experience:

1. For my NAS, I turned on the FTPS functionality for 3 months. Firewall setup was ok. I just had to open up the FTP port and a few more ports used by FTPS transfer. So far so good, no big deal.

2. After 3 months, I figure, meh, may be I turn on SFTP protocol as well since it is more common and probably easier to manage. Then something interesting happened. 10 MINUTES after I open up the SFTP port, my NAS was under some bruise force attacks. The NAS automatically blocked the attacking IP after 10 failed password attempts and notify me by e-mail. Imagine if the attacker had control of thousands of computers all having different IPs, my NAS would not be able to stop them all. Also, if the staffs of our company decides to set up really easy password, then the person who uses the bruise force attack may eventually get into our system.

Now that I disabled the SFTP, the attacking stopped and I am happy that no one is trying to get into our file server any more.

Answer 6

No, SSH and SSL usually use the same cipher strenth. e.g: RSA and AES, but SSH can use DSA. But ssh uses port 22. but FTPs uses port 21 and 22 for FTP and FTP Data. tho it is in my opinion better configurable, you have to open 2 ports, which is not only impractical considering firewalls but also a potential security risk, because you have to open 2 ports.

Answer 7

The answer is kinda blunt either which way you go in your rhetoric. Server side means are controlled by the person giving the file and theoretically safer if one knows all security features.

A user side method would be the same but for the user. In these days we do not question the relationship of the two. Each must insure themselves of their abilities to protect themselves sufficiently. Users therefore turn to an option of firewalls.

Any option you choose for the user can easily be overruled by such means. Therefore we do not worry about the user (recipient). This rhetoric is obsolete now on this matter.

Your concern should be on your own securities. This would mean server side. You want control of information you release. How much concern after it is released is no longer prudent. It is simply not your responsibility beyond that point. Only what affects you as a consequence. If you have no data yet on this you have no consequence.

A truly controllable solution would be to use a FTP source with encryption all by your own design. Do not rely on any third parties. But this too is obsolete as it is hard to build your own libraries from start to finish.

Based on the terminologies you supplied inadequately you want a simple ssh ftp. For that all you can do is propose firewall rules and iptables configurations (if in Linux). You seem to be stuck with WYSIWYG either way you go.