SSL and TLS have many similarities. That's why, in most software applications, they're configured together as "SSL/TLS". However, there are several differences between SSL and TLS well, which is what we're going to talk about now.
SSL (Secure Socket Layer) and TLS (Transport Layer Security) are very similar in many aspects. They both:
The similarities are closest between the first version of TLS (TLS 1.0) and the last version of SSL (SSL 3.0). In fact, TLS v 1.0 is often considered SSL v 3.1. The former even had the ability to downgrade an ongoing connection to SSL 3.
So how does TLS differ from SSL? What we have below is by no means an exhaustive list but here are some of the key differences.
If you'd like a closer look, you can test drive JSCAPE yourself by requesting a free trial here.
Note: All of our comparisons will be between TLS and SSLv3.0 because version 3 is the only SSL version that's still (relatively) widely used.
In SSLv3.0 (refer to RFC 6101), a client would typically respond with a no_certificate alert message whenever the server requested a certificate for authentication but it (the client) had none to give. In TLS, this alert is no longer necessary. However, the client must (especially in TLS 1.2 - RFC 5246) send a certificate message containing no certificates.
Whenever a problem is encountered during the course of a SSL or TLS connection, the party who discovers the problem would send out an alert message.
SSLv3 had 12 of these messages.
SSL Alert Descriptions
TLS added 19 more to that (although "No Certificate" was removed).
Additional Alert Descriptions only found in TLS
SSL performs message integrity checks (to determine whether a message has been altered) through Message Authentication Codes (MACs) that use either MD5 or SHA. TLS, on the other hand, uses HMAC, allowing it to work with a wider variety of hash functions; not just MD5 and SHA.
To generate the key material, TLS uses an HMAC-based psuedorandom function (PRF). SSL doesn't.
In cases wherein the server requests for a client certificate (to authenticate the client), the client is supposed to send a follow-up message some time after sending the Certificate message (the message that contains the client certificate). In TLSv1.2, this message must be sent right after the ClientKeyExchange message.
This follow-up message, known as the CertificateVerify message, would enable the server to verify that the client certificate in fact originated from the actual client and not an impostor.
This CertificateVerify message is actually a signature of the previous handhsake messages signed using the client certificate's corresponding private key. Because the server would have already had the corresponding public key (which accompanied the client certificate sent earlier) in its possession, it would be able to verify the signature.
In TLS, everything that's needed to construct the CertificateVerify message can be found in the previous handshake messages. It wasn't the same in SSL, which, in addition to the handshake messages, also required the master secret and a couple of other values known as pad_1 and pad_2 (see RFC 6101, section 5.6.8)
Another difference between TLS and SSL are their collection of cipher suites. SSL cipher suites typically begin with SSL_, while TLS cipher suites begin with TLS_. Notably missing in TLS are the FORTEZZA cipher suites, which are supported in SSLv3. On the other hand, notably present in the later versions of TLS (more specifically, starting at TLSv1.1) are the AES cipher suites. The Advanced Encryption Standard (AES) ciphersuites were integrated into TLS by virtue of RFC 3268.
I'm pretty sure there are several other differences but these are the ones that really stand out for us. If there are those you think we should add, feel free to let us know.