SSLFTPClient Class

public class SSLFTPClient : ExFTPClient

Public Class SSLFTPClient
	Inherits ExFTPClient

public ref class SSLFTPClient : public ExFTPClient

type SSLFTPClient = 
    class
        inherit ExFTPClient
    end

Inheritance

Object    FTPClient    ExFTPClient    SSLFTPClient

SSLFTPClient supports SOCKS (4, 4A, and 5) and FTPS (implicit and explicit).

FTPS: SSLFTPClient supports standard FTP and the two types of FTPS, explicit and implicit. The default is explicit FTPS. The type may be selected using the IsImplicitFTPS flag.

Explicit FTPS: The FTP client connects in plain (non-SSL) mode and operates in this mode until the AUTH command is issued by means of the >Auth(string) method. This will cause the client and server to negotiate an SSL connection. Once complete, all commands sent from the client to the server, and their corresponding replies will be secure.

Example

// create an explicit FTPS client
SSLFTPClient ftp = new SSLFTPClient();
ftp.RemoteHost = "192.168.10.123";

// Turn off server validation (ONLY do this when testing)
ftp.ServerValidation = SecureFTPServerValidationType.None;

// connect to the server
ftp.Connect();                        

// switch to secure command channel
ftp.Auth(SSLFTPClient.AUTH_TLS);

// log in
ftp.Login("test", "test");

// get a file
ftp.Get("file.txt", "file.txt");

// close the connection
ftp.Quit();

This example uses no client authentication and does not attempt to verify server certificates (which should always be done in production systems).

Implicit FTPS is an older form of FTPS which uses pure SSL connection, i.e. SSL sessions are established immediately upon socket connection for all FTP channels.

Example

// create an implicit FTPS client
SSLFTPClient ftp = new SSLFTPClient();
ftp.RemoteHost = "192.168.10.123";

// Turn off server validation (ONLY do this when testing)
ftp.ServerValidation = SecureFTPServerValidationType.None;

// Select implicit FTPS
ftp.IsImplicitFTPS = true;

// connect to the server
ftp.Connect();                        

// log in
ftp.Login("test", "test");

// get a file
ftp.Get("file.txt", "file.txt");

// close the connection
ftp.Quit();

Like the previous example, this example uses no client authentication and does not attempt to verify server certificates (which should be done in production systems).

SSL Certificates - Server Validation: The examples above used no server validation. This is only normally acceptable only when testing. To be secure applications should always validate the server that they're communicating with. If the ServerValidation property is set to SecureFTPServerValidationType.Automatic or SecureFTPServerValidationType.AutomaticIgnoreHostName then SSLFTPClient will attempt to validate the server's certificate. In explicit FTPS this occurs when the Auth(SecurityMechanism) method is invoked, whereas in implicit FTPS, it occurs upon connection. Windows Internet security services are used to validate the certificate. This means that one of the following must be true

1. CA certificate – The server's certificate must have been issued by a CA (Certificate Authority) whose certificate is in the Windows certificate store.
2. Non-CA certificate – The server's certificate must be in the Windows certificate store. A certificate may be installed on the system using the Internet Properties settings, which may be accessed from the Windows Control Panel.

SSL Certificates - Client Validation: Some FTPS servers require a client certificate to be presented at the time security information is exchanged. To enable this feature you must set the ClientCertificate property. Certificates may be loaded using a range of static methods in SSLFTPCertificate.

Server Compatibility: The most severe barrier to server compatilibilty is the lack of FTPS support on the server. Most FTP servers can be configured to support FTPS, but some only support SFTP (SSH File Transfer Protocol), which in fact is not FTP in the conventional sense. SFTP is not supported by SSLFTPClient.

The second most common server incompatibility problem is caused by differing level of adherence to the standard for how SSL/TLS sockets should be closed. By default SSLFTPClient will attempt to close sockets in the standards-compliant way. While this is the most secure, it occasionally will cause hanging as it waits for a response from the client which never arrives. The ServerCompatibility property is provided for controlling this behaviour. If you experience hanging when a data-transfer is complete then you should first try SecureFTPCompatibilityFlags.SSLDisableDataWaitOnClose and, if the problem still occurs, SecureFTPCompatibilityFlags.SSLDisableDataClosure. If you experience hanging as you close your secure FTP session then you should first try SecureFTPCompatibilityFlags.SSLDisableControlWaitOnClose and, if the problem still occurs, SecureFTPCompatibilityFlags.SSLDisableControlClosure.

Cipher-Suites: A cipher-suite is a set of algorithms that is used for various aspects of SSL security. For a client and a server to be able to communicate, they must be able to agree on a particular cipher-suite. Different types of servers recognize different cipher-suites, so it is usually up to the client make sure that it shares at least one cipher-suite with the server that it is trying to communicate securely with. By itself, this fact would imply that the client should simply enable all possible suites in order to increase the chances of overlap. However, this is not necessarily wise since some cipher-suites, esp. those which adhered to the (now defunct) US export restriction,s are relatively easy to break, whereas some others are trusted as currently being virtually unbreakable.

This library supports many cipher-suites (SSLFTPCipherSuite) so it should be possible to find a suitable cipher-suite in most cases. Cipher-suites are configured on the client using the CipherSuites property.

SOCKS: SOCKS may be used for FTPing through firewalls. For this to be possible a SOCKS proxy must be available, and a user account must be set up on that proxy. SSLFTPClient supports all the popular versions of SOCKS - 4, 4A, and 5.

The SOCKS features are controlled entirely through the SocksContext property. If it is null (the default) then SOCKS is not used. To use SOCKS, the property must be set to an instance of Socks4Context or Socks5Context. For example, for SOCKS4:

Reference