Overview

SSL (Secure Sockets Layer) can be used in conjunction with FTP to provide increased security over standard FTP. This chapter provides an overview of the SSL protocol and describes how SSL works within WS_FTP.

SSL is a protocol for encrypting and decrypting data sent across direct internet connections. When a client makes an SSL connection with a server, all data sent to and from that server is encoded with a complex mathematical algorithm that makes it difficult to decode anything that is intercepted.

The following is a step-by-step illustration of how SSL works.

Step 1. The client makes the initial connection with the server and requests that an SSL connection be made. If Implicit SSL is used, the initial connection will be encrypted. If Explicit is used, the initial contact will be unencrypted.

Step 2. If the server is properly configured, the server will send to the client its certificate and public key.

Step 3. The client compares the certificate from the server to a trusted authorities database. If the certificate is listed there, it means the client trusts the server and will move to step 4. If the certificate is not listed there, the user must add the certificate to the trusted authorities database before going to step 4.

Step 4. The client uses that public key to encrypt a session key and sends the session key to the server. If the server asks for the client's certificate in Step 2, the client must send it at this point.

Step 5. If the server is set up to receive certificates, it compares the certificate it received with those listed in its trusted authorities database and either accepts or rejects the connection.

If the connection is rejected, a fail message is sent to the client. If the connection is accepted, or if the server is not set up to receive certificates, it decodes the session key from the client with its own private key and sends a success message back to the client, thereby opening a secure data channel.

The key to understanding how SSL works is in understanding the parts that make SSL itself work. The following is a list of these parts and the role each plays.

• Client. In this case, the client is Progress WS_FTP Professional.
• Certificate. The Certificate file holds the identification information of the client or server. This file is used during connection negotiations to identify the parties involved. In some cases, the client's certificate must be signed by the server's certificate in order to open an SSL connection. Certificate files have the .crt ending.
• Session Key. The session key is what both the client and the server use to encrypt data. It is created by the client.
• Public Key. The public key is the device with which the client encrypts a session key. It does not exist as a file, but is a by-product of the creation of a certificate and private key. Data encrypted with a public key can only be decrypted by the private key that made it.
• Private Key. The private key decrypts the client's session key that is encrypted by a public key. The private key file has the .key ending. Private keys should NEVER be distributed to anyone.
• Certificate Signing Request. A certificate signing request is generated each time a certificate is created. This file is used when you need to have your certificate signed. After the Certificate Signing Request file is signed, a new certificate is made and can be used to replace the unsigned certificate.