SSL (“Secure Sockets Layer”) was the first widely-deployed technology used to secure TCP sockets. Its use in HTTPS (HTTP over SSL) allowed the modern age of “ecommerce” to take off on the world wide web and it has also been incorporated into common file transfer protocols such as FTPS (FTP over SSL) and AS2.
In modern usage, “protected by SSL”, “secured by SSL” or “encrypted by SSL” really means “protected by TLS or SSL version 3, whichever gets negotiated first.” By 2010 clients and servers knew how to negotiate TLS sessions and will attempt to do so before trying SSL version 3 (an older protocol). Version 2 of SSL is considered insecure at this point and some clients and servers will attempt to negotiate this protocol if attempts to negotiate TLS or SSL version 3 fail, but it is rare that negotiation falls through to this level.
SSL depends on the use of X.509 certificates to authenticate the identity of a particular server. The X.509 certificate deployed on an SSL/TLS server is popularly referred to as the “server certificate”. If the name (CN) on the server certificate does not match the DNS name of a server, clients will refuse to complete the SSL/TLS connection unless the end user elects to ignore the certificate name mismatch. (This is a common option on web browsers and FTP clients.) If the server certificate is expired, clients will almost always refuse to complete the SSL/TLS connection. (Ignoring certificate expiration is usually not an option available to end users.) Finally, if the server certificate is “self signed” or is signed by a CA that the client does not trust, then most clients will refuse the connection. (Browsers and FTP clients usually have the option to either ignore the CA chain or import and trust the CA chain to complete the negotiation.)
Optional X.509 client certificates may also be used to authenticate the identity of a particular user or device. When used, this certificate is simply referred to as a “client certificate.” File transfer servers either manually map individual client certificates to user codes or use LDAP or Active Directory mappings to accomplish the same goal. File transfer servers rarely have the ability to ignore expired certificates, often have the ability to import a third-party CA certificate chain, and often have the ability to permit “self-signed” certificates.
Whether or not client certificates are in use, SSL/TLS provides point-to-point encryption and tamper protection during transmission. As such, SSL/TLS provides sufficient protection of “data in motion”, though it provides no protection to “data at rest.”
SSL/TLS connections are set up through a formal “handshake” procedure. First, a connecting client presents a list of supported encryption algorithms and hashes to a server. The server picks a set of these (the combination of algorithms and hashes is called a “ciphersuite”) and sends the public piece of its X.509 server certificate to the client so the client can authenticate the identity of the server. The client then either sends the public piece of its X.509 client certificate to the server to authenticate the identity of the client or mocks up and sends temporary, session-specific information of a similar bent to the client. In either case, key exchange now occurs.
When you hear numbers like “1024-bit”, “2048-bit” or even “4096-bit” in relation to SSL, these numbers are referring to the bit length of the keys in the X.509 certificates used to negotiate the SSL/TLS session. These numbers are large because the exchange of keys in asymmetric public-key cryptography requires the use of very large keys, and not every 1024-bit (etc.) number is a viable key.
When you hear numbers like “80-bit”, “128-bit”, “168-bit” or even “256-bit” in relation to SSL, these numbers are referring to the bit length of the shared encryption key that is negotiated during the handshake procedure. This number is dependent on the algorithm available on clients and servers. For example, the AES algorithm comes in 128-bit, 192-bit and 256-bit editions, so these are all possible values for software that supports AES.
The three most important implementations of TLS/SSL today are Microsoft’s Cryptographic Providers, Oracle’s Java Secure Socket Extension (“JSSE”) and OpenSSL. All of these libraries have been separately FIPS validated and all may be incorporated into file transfer software at no charge to the developer.
BEST PRACTICE: The SSL/TLS implementation in your file transfer clients and servers should be 100% FIPS validated today. More specifically, the following file transfer protocols should be using FIPS validated SSL/TLS code today: HTTPS, FTPS, AS1, AS2, AS3 and email protocols secured by SSL/TLS. Modern file transfer software supports the optional use of client certificates on HTTPS, FTPS, AS1, AS2 and AS3 and allows administrators to deny the use of SSL version 2. If you plan to use a lot of client certificates to provide strong authentication capabilities, research the level of integration between your file transfer software, your enterprise authentication technology (e.g., Active Directory) and your PKI infrastructure.