Blog

Managed File Transfer and Network Solutions

SSL vs TLS - Know The Difference

Posted by John Carl Villanueva on Wed, Sep 16, 2015 @ 09:39 AM

Overview

SSL and TLS have many similarities. That's why, in most software applications, they're configured together as "SSL/TLS". However, they do have several differences as well, which is what we're going to talk about now.


A brief discussion on the similarities

SSL (Secure Socket Layer) and TLS (Transport Layer Security) are very similar in many aspects. They both:

  • protect data privacy through data-in-motion encryption;
  • provide server and (optionally) client authentication; 
  • check for message integrity using message authentication codes; and
  • perform a preliminary handshake process wherein the two communicating parties negotiate for a common cipher suite.

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:

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. 

Absence of a no_certificate error alert in TLS

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. 

 

TLS has more Alert descriptions

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

  • Close Notify,
  • Unexpected Message,
  • Bad Record MAC,
  • Decompression Failure,
  • Handshake Failure,
  • No Certificate,
  • Bad Certificate,
  • Unsupported Certificate,
  • Certificate Revoked,
  • Certificate Expired,
  • Certificate Unknown, and
  • Illegal Parameter.

TLS added 19 more to that (although "No Certificate" was removed). 

Additional Alert Descriptions only found in TLS  

  • Decryption Failed,
  • Record Overflow,
  • Unknown CA (Certificate Authority),
  • Access Denied,
  • Decode Error,
  • Decrypt Error,
  • Export Restriction,
  • Protocol Version,
  • Insufficient Security,
  • Internal Error,
  • User Canceled,
  • No Renegotiation,
  • Unsupported Extension,
  • Certificate Unobtainable,
  • Unrecognized Name,
  • Bad Certificate Status Response,
  • Bad Certificate Hash Value,
  • Unkown PSK, and
  • No Application Protocol.

 

TLS uses HMAC for message authentication

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.

 

TLS uses a pseudorandom function to generate the key material

To generate the key material, TLS uses an HMAC-based psuedorandom function (PRF). SSL doesn't.

 

TLS has a simpler way of arriving at the CertificateVerify message

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)

 

Different set of cipher suites

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.

 

Related articles

How To Set Up A HTTPS File Transfer

What is an SSL File Transfer?

How To Create A Client Certificate

 

 

Topics: Security, Secure File Transfer