SSL Overview

Secure Socket Layer (SSL) is a protocol for encrypting and decrypting data across a secure connection from a client to a server with SSL capabilities. EFT is responsible for sending the client a certificate and a public key for encryption. If the client trusts EFT's certificate, an SSL connection can be established. All data passing from one side to the other will be encrypted. Only the client and EFT will be able to decrypt the data.

EFT supports SSL for client and server authentication, message integrity, and confidentiality. You can configure EFT's security features to verify users' identities, allows users to verify your identity, and to encrypt file transfers. The key to understanding how SSL works is to understand the elements that take part in the process.

FTPS is an enhancement to standard FTP that uses standard FTP commands (and protocol) over secure sockets. FTPS adds SSL security in both the protocol and data channels. FTPS is also known as FTP-SSL and FTP-over-SSL. You might also see the term SSL used in conjunction with TLS. SSL has been merged with other protocols and authentication methods into a new protocol known as Transport Layer Security (TLS). EFT employs SSL/TLS to perform FTPS to keep your data secure. Refer to EFT Specifications for information about the OpenSSL version used in this version of EFT.

EFT's SSL implementation uses all the SSL configuration made on the Server > Security tab for all SSL operations, including Event Rules.

Elements that Work Together to Establish a Secure SSL Connection:

Client: The client needs to be an FTP client with SSL capabilities.
Certificate: Certificates are digital identification documents that allow both servers and clients to authenticate each other. Server certificates contain information about your company and the organization that issued the certificate (such as Verisign or Thawte) while client certificates contain information about the user and the organization that signed the certificate. You can choose to either trust or distrust a certificate. In some cases, the client's certificate must be signed by EFT's certificate to open an SSL connection.
Session Key: The client and EFT use the session key to encrypt data. It is created by the client via EFT’s public key.
Public Key: The client encrypts a session key with EFT’s public key. It does not exist as a file, but is produced when a certificate and private key are created.
Private Key: EFT's private key decrypts the client's session. The private key is part of the public-private key pair.
Certificate Signing Request: A Certificate Signing Request (CSR) is an unsigned copy of your certificate. A certificate signing request is generated each time a certificate is created. A certificate signing request has a .csr extension. This file is used when you need to have your certificate signed. Once the .csr file is signed, a new certificate is created and replaces the unsigned certificate.

NOTE: Certain browsers check expiration and other data about the certificate to ensure you have a secure connection. Browsers like Chrome will tell you if you have a valid certificate when you click on the padlock icon next to the URL:

SSL must first be enabled on the Server and Site, and then can be enabled in the Settings Template and/or for each user. EFT provides administrators the ability to specify the symmetric key cipher(s) and the ordering of those ciphers for establishing SSL sessions. EFT validates inbound SSL sessions, and allows or denies connections based on specified or approved ciphers.

EFT supports two levels of authentication with SSL:

High - EFT is configured so that it contains a certificate, but does not require a certificate from the FTP client.
Highest - EFT is configured so that it provides a certificate and also requests a certificate from the client. EFT compares the client certificate to a list contained in its Trusted Certificates database. EFT either accepts or rejects the connection based upon a match.