Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are both cryptographic protocols that help secure communications over a computer network. There are many similarities between the protocols used in SSL and TLS, so much so that many applications configure their implementation together as "SSL/TLS."
Both types of certificates are machine identities that are used for data encryption and authorization and verification. But SSL and TLS do differ from one another in some respects.
Machine identities have two specific functions:
- Authentication and Verification: TLS and SSL certificates have information about the authenticity of details around the identity of a host or site. When you click on the padlock displayed or check the trust mark the certificate chain details prove where the certificate is generated from.
- Data Encryption: TLS and SSL certificates enable encryption, which means that the sensitive information exchanged via the web site cannot be intercepted and read by anyone other than the intended recipient.
A TLS/SSL certificate is most reliable when issued by a trusted Certificate Authority (CA). The CA has to follow very strict rules and policies about who may or may not receive an SSL Certificate. So, when you have a valid SSL certificate from a trusted CA, there is a higher degree of trust.
The Difference between SSL and TLS
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols that safeguard the communication on networks. Initially, SSL was employed to establish secure connections between devices or applications. Despite its utility, SSL came with certain security shortcomings. To address these flaws and enhance the security landscape, TLS was introduced. As an improved version of SSL, TLS not only rectifies the vulnerabilities associated with SSL but also offers superior authentication methods and sustains secure, encrypted communication pathways. The shift to TLS signifies an evolution in ensuring safe and reliable data transmission over the internet.
Both SSL and TLS protocols were necessary components of the X.509 certificates, which are machine identities used by applications or browsers to create secure, encrypted connections or communications across the internet or within a network. As such, they are used to establish trust and authenticate the identity of another machine before sharing credentials or data with that machine over the internet.
Aside from the obvious SSL vulnerabilities that TLS addressed, SSL and TLS protocols work quite differently, especially for functions such as authenticating messages, sending alert messages and recording protocol. They also differ in terms of the strength of their encryption and the SSL/TLS handshake process that’s performed at the beginning of a connection when the client and server first interact with each other.
Functional differences between SSL and TLS
Although SSL and the initial versions of TLS do not share many differences, they implement message authentication in a different way.
A message is authenticated via SSL by utilizing a brief piece of data known as a message authentication code (MAC), which ensures a message's validity and integrity. TLS employs a keyed-hash message authentication code (HMAC), or MAC, which is generated using a secret cryptographic key and a cryptographic hash function.
TLS is frequently also referred to as "By Program" or "implicit" security since it requires a program to establish an unsafe connection first before using special commands to activate encryption. This is distinct from "By Port" or "explicit" security in SSL, or an explicit connection to a port that anticipates a session to commence with security negotiation.
TLS 1.3 is the version where we can witness the most changes, except for the removal of the backward compatibility with the previous versions. TLS 1.3 enhances TLS 1.2 in a variety of ways:
- Removed support for SHA-224 and MD5, two vulnerable hashing methods.
- Abandoned the use of RSA key exchanges. Only Diffie-Hellman key exchanges, which provide forward secrecy, are used in TLS 1.3.
- Compared to TLS 1.2, handshake negotiation is less latent.
The origins of SSL protocols
In the early 1990s, researchers at Netscape Communications wanted to develop a protocol for securing communications between clients and server applications over an unprotected network. This desire gave birth to the first version of SSL in 1994. As explained by Venafi's knowledge base, SSL works by using a short piece of information called a message authentication code (MAC) to authenticate a message. This MAC therefore helps to ensure the integrity and authenticity of a message.
SSL has gone through two major updates as of this writing. Version 2.0 of the protocol arrived in 1995, whereas SSL 3.0 arrived in 1996. The designers of SSL released the two new versions with backward compatibility to ease the burden of adoption. But this effort, not to mention the overall design of the protocol, has hampered the ability of SSL to provide secrecy, integrity, and authenticity.
In 2014, SSL 3.0 suffered a huge blow when the National Institute of Science and Technology declared in a report (PDF) that the protocol was "not approved for use in the protection of Federal information." The nail in the coffin arrived later that year with the discovery of the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. Under this exploit, an attacker abuses how blocks of data are encrypted under a specific type of encryption algorithm within the SSL protocol to decrypt content within an SSL session.
Today, many consider SSL 3.0 to be an old encryption standard and TLS to be its successor. The Internet Engineering Task Force (IETF), which develops internet standards, tracks the protocol first defined in 1999. TLS uses a keyed-hash message authentication code (HMAC), or a MAC calculated using a cryptographic hash function and a secret cryptographic key. Most of the time, TLS is also known as "By Program" or "implicit" security, where a program connects insecurely first then uses special commands to enable encryption. Dr. Erik Kangas explains this is different from "By Port" or "explicit" security (SSL), or an explicit connection to a port that expects a session to start with security negotiation.
TLS has undergone three revisions: TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018). In 2011, the IETF removed backward compatibility with SSL 2.0. Some TLS implementations remain backward compatible with SSL 3.0. That's because while the protocols don't interoperate, the differences separating SSL 3.0 and TLS 1.0 aren't major. However, TLS 1.3 was not built as an evolution of TLS 1.2, but from the ground up it was redesigned to disable legacy features and speed up performance on a secure connection. Instead of negotiating an encryption model, the server provides the encryption key with TLS 1.3. By sidestepping downwards compatibility, TLS 1.3 aims to eliminate the threat of downgrade attacks, which force the server to use an older, less secure protocol.
TLS and SSL both help to encrypt data that's exchanged over the web. As such, organizations can purchase certificates for servers that support the protocols. They must then make sure they secure these certificates and don't allow them to expire.
(This post has been updated. It was originally published on February 12, 2019.)
Related posts
