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 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. An Internet Engineering Task Force (IETF) standards track 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 than "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
