Bitvise SSH Server: Compatibility with FTPS Clients
In SSH, compatibility rarely comes at the expense of security. Therefore, when used with clients supporting SSH, SFTP and SCP, Bitvise SSH Server attempts to be compatible with the widest possible variety of file transfer clients.
Bitvise SSH Server also supports FTPS - FTP over TLS/SSL. The FTP protocol has a longer history than SSH and is originally rooted in an insecure, unencrypted design. FTPS clients vary greatly in the security measures they support for FTP. Therefore, Bitvise SSH Server is compatible with FTPS clients more selectively than in the case of SSH, SFTP and SCP clients.
To be compatible with Bitvise SSH Server, an FTPS client must:
Support explicit TLS started using AUTH TLS at the beginning of the FTP control connection.
Use FTP passive mode.
Support TLS for data connections, and use TLS resume functionality for data connections.
Enabling FTPS
FTPS is available in Bitvise SSH Server versions 8.xx and newer. Older versions do not support FTPS.
FTPS is disabled in the SSH Server by default. An administrator may prefer to use Bitvise SSH Server for only SSH, SFTP or SCP.
FTPS requires at least one additional port. If there is another FTP server on the system, it may be using that port already.
In SSH Server versions 8.xx, you can enable FTPS in Easy settings, on the Server settings tab. Alternately, you can configure FTPS bindings in Advanced settings, under Bindings and UPnP.
TLS session resumption vs. FTP data port range
The SSH Server uses TLS session resumption as a mandatory security mechanism for FTPS data connections. This is the only way to securely associate an FTPS data connection with the correct control connection.
A legacy alternative used by FTP servers is to use a range of ports for data connections. The server then associates the data connection to the control connection based on the port number to which the client connects.
This port range mechanism is insecure. It allows a man-in-the-middle attacker to continuously attempt connections to ports in the server's data port range. Even the largest possible port range is very small compared to secure cryptographic key sizes. This attack is very likely to succeed. The attacker can use it to receive an entire file which was intended for an authenticated user, or to upload a file impersonating the user.
The SSH Server does not support the port range mechanism. The SSH Server uses a single FTP data port, and requires TLS session resumption for security.
Compatible FTPS Clients
We cannot guarantee compatibility between all versions of Bitvise SSH Server and each client. However, our testing has confirmed that the following FTPS clients were compatible with Bitvise SSH Server at some point:
| Product | Version | Platform | Notes |
|---|---|---|---|
| 3D-FTP | 9.07 | Windows | Client did not verify FTPS certificate |
| AnyClient | Windows | ||
| Auto FTP Manager | 6.01 | Windows | |
| Beyond Compare | 4.1.6 build 21095 | Windows | |
| cURL | Linux | ||
| Cyberduck | 5.0.11.20753 | Windows | |
| Directory Opus | 11.19 | Windows | |
| Far Manager | v3.0 build 4747 | Windows | |
| Fetch | Mac | ||
| FileZilla | 3.38.1 | Windows | |
| FlashFXP | 5.4.0 build 3939 | Windows | |
| FTP Manager Lite | 2.1 | Windows | |
| IBM SSL FTP Client | IBM i | We did not test directly. A user indicates it works. | |
| iGetter | v3.2.0 | Windows | We did not test directly. The developer indicates it works. |
| SmartFTP | 8.0.2242 | Windows | |
| Steed (FTP) | 1.2.0.1147 | Windows | |
| Total Commander | 8.52a | Windows | |
| Transmit | Mac |
Semi-Compatible FTPS Clients
We were able to use the following FTPS clients with Bitvise SSH Server after adjusting client settings:
| Product | Version | Platform | Notes |
|---|---|---|---|
| CuteFTP | 9 | Windows | Enable Global Options > Security\SSL Security > Reuse cached session for data connection |
| lftp | Linux | In ~/.lftp/rc, add line: set ftp:ssl-protect-data yes | |
| WinSCP | 5.13.6 (Build 9061) | Windows | SFTP and SCP work. For FTPS, if the SSH Server is behind NAT, then in Advanced settings, Override FTP passive address must be configured for the FTP binding. FTPS fails with WinSCP on older Windows because in that case it does not use TLS resume for data connections. We recommend using WinSCP in SFTP mode. |
| WS_FTP | Windows | Enable Site options > Advanced\SSL > Reuse SSL session |
Incompatible FTPS Clients
We were not able to use the following FTPS clients with Bitvise SSH Server:
| Product | Version | Platform | Notes |
|---|---|---|---|
| Beyond FTP | 3.3.01 | Windows | SSH (SFTP) worked, FTPS did not work due to incompatible algorithms. When we checked, it was last updated in 2010. |
| BitKinex | 3.2.3 | Windows | Client would disconnect before completing SSL negotiation. When we checked, it was last updated in 2010. |
| Core FTP (LE) | 2.2 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS resume for data connections. When we checked, it was last updated in 2016. |
| Commander One | Mac | SSH (SFTP) worked, FTPS did not work | |
| CrossFTP | 1.97.8 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS resume for data connections. When we checked, it was last updated in 2016. |
| ExpanDrive | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS resume for data connections. When we checked, it was last updated in 2016. Client did not verify SSH host keys or FTPS certificates | |
| FTP Commander (Deluxe) | Windows | Disconnected at authentication stage. | |
| FTP Voyager | Windows | SSH (SFTP) worked, FTPS did not work due to incompatible algorithms. When we checked, it was last updated in 2014. | |
| FTP Rush | v2.1.8 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS resume for data connections. When we checked, it was last updated in 2011. Client did not verify SSH host keys or FTPS certificates |
| Interarchy | Mac | SSH (SFTP) worked, FTPS did not work | |
| Syncplify.me FTP! | 1.0.11.31 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS for data connections |
| Sysax FTP Automation | 1.0.11.31 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS resume for data connections. When we checked, it was last updated in 2016. |
| WebDrive | 2018.0 | OSX | SSH (SFTP) worked, FTPS did not work |
| WebDrive | 3.2.3 | IOS | SSH (SFTP) worked, FTPS did not work |
| WISE-FTP | 9 | Windows | SSH (SFTP) worked, FTPS did not work because it did not support TLS for data connections. Client did not show fingerprint during SSH host key verification; did not verify FTPS certificate by default |
| Yummy FTP | Mac | SSH (SFTP) worked, FTPS did not work |
Technical details for TLS resume
In order for Bitvise SSH Server to accept an FTPS data connection, the data connection must successfully resume the TLS session associated with the corresponding control connection.
The TLS implementation used by Bitvise is Microsoft Schannel, which is a feature of Windows. This means the TLS implementation is relatively opaque to Bitvise. We do not have control over the implementation details, and its behavior will depend on the version of Windows on which the SSH Server is running, as well as patches you have applied.
Any registry settings you configure for Microsoft Schannel will also apply to FTPS connections handled by Bitvise SSH Server. However, Schannel configuration will not affect connections that use SSH, SFTP, or SCP.
To successfully resume TLS on the data connection, your TLS implementation must support a TLS resume mechanism which is compatible with Microsoft Schannel. This is currently a resume that reuses the session ID in the ClientHello. (The other mechanism is the TLS "session_ticket" extension. Schannel currently supports this as client, but not as server.)
Since October 2019, the Microsoft Schannel implementation will no longer resume TLS sessions unless they use the Extended Master Secret extension. Therefore, support for this extension is required for a successful resume.