In seeking the technical differences between TLS and SSL I uncovered many web pages which glossed over the topic and lacked any true answer or technical detail. Like this one which basically describes SSL on Yahoo Q & A.
This page, though vague, at least states that they are different standards and TLS uses stronger encryption mechanisms.
Many web sites claimed TLS was basically the same as SSL since it is based on SSL. If this were true, why would the IETF bother to create a new version and give it a different name on top of that? This made no sense.
Additionally why are most banks switching to TLS and requiring those who communicate with them via email to use it if there is no difference?
I ended up pulling up the IETF web site and pulling up the actual standard to take a look at what it had to say:
RFC Number 4346: TLS 1.1
In short, SSL3.0 and TLS are different according to a few blurbs I pulled out of the above TLS 1.1 Standard document:
_____________
IV
Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit IV in order to prevent the attacks described by [CBCATT]. We recommend the following equivalently strong procedures. For clarity we use the following notation....
__________
The SSLv3 specification was not clear about the encoding of public-key-encrypted data, and therefore many SSLv3 implementations do not include the length bytes, encoding the RSA encrypted data directly in the ClientKeyExchange message.
This specification requires correct encoding of the EncryptedPreMasterSecret complete withlength bytes. The resulting PDU is incompatible with many SSLv3 implementations. Implementors upgrading from SSLv3 must modify their implementations to generate and accept the correct encoding. Implementors who wish to be compatible with both SSLv3 and TLS should make their implementation's behavior dependent on the protocol version.
Implementation Note: It is now known that remote timing-based attacks on SSL are possible, at least when the client and server are on the same LAN. Accordingly, implementations that use static RSA keys SHOULD use RSA blinding or some other anti-timing technique, as described in [TIMING].
__________
When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS...
[Goes on to list ciphers]
______
In previous versions of SSL, CBC mode was used properly EXCEPT that it used a predictable IV in the form of the last block of the previous ciphertext. This made TLS [I think they mean SSL since talking about PREVIOUS versions] open to chosen plaintext attacks. This version of the protocol is immune to those attacks. For exact details in the encryption modes proven secure, see [ENCAUTH].
____________
By the way if you're using SSL 2.0 - get rid of it ASAP and you may want to use TLS enforcement from Postini or another provider in your email solution:
Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make TLS-capable clients and servers fall back to Version 2.0. This attack can occur if (and only if) two TLS-capable parties use an SSL 2.0 handshake.
_____________
And as a final note...
For TLS to be able to provide a secure connection, both the client and server systems, keys, and applications must be secure. In addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used. Short public keys, 40-bit bulk encryption keys, and anonymous servers should be used with great caution. Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage.
