Transport Layer Security (TLS) is an encryption protocol for securing data transmission between clients and servers. TLS was formerly known as SSL or Secure Sockets Layer.
Under the TLS protocol, the web browser and server get an individual trusted certificate. When the connection between the two parties starts, they exchange a secure key for the connection. The key is known to both the client and server and decrypts all data sent over the connection.
The TLS Handshake Protocol is the foundation of TLS. It allows a client and server to establish a secure connection using asymmetric and symmetric encryption. Asymmetric encryption means that two keys — the public and private keys — are used for every transaction. In symmetric encryption, we use only a session key. It is labeled symmetric because both the client and server use this key to encrypt and decrypt data.
To better understand how the protocol functions, it is essential to examine how clients and servers initially establish a TLS handshake.
The handshake begins when the client sends the server a message. The message includes several components, including the protocol’s version number (for example, TLS 1.2) and the cipher suite that the client can support. A cipher suite is an encryption algorithm.
The web server, which has a list of cipher suites that it supports, uses the client’s cipher list to choose the cipher suite used in all communication with the client.
Then, the server sends back a response to the client. This response includes the certificate that the webserver has attached. The essential component of the certificate is the public key for the server, which the client can now use to encrypt data and send it back to the server. The server can then decrypt data using its private key.
When the client receives the certificate, it checks its validity to ensure that the certificate is neither false nor revoked. Once the client has the public key, it generates a secret key based on specific values from the public key. Then, it encrypts the secret key with the public key and sends this back to the server. This process is called a key exchange. After the key exchange completes, the client closes the communication.
The server receives the secret key and decrypts it using its private key. The client and web server calculate and generate the same symmetric encryption key based on the decrypted secret key. This is known as the session key.
During this crucial exchange process, the client and server exchange a change cipher spec message, which signals the shift from asymmetric encryption to symmetric encryption. Finally, the server closes its side of the communication.
At this point, the handshake has been successfully established. Any data exchanged between the client and web server will be encrypted with the symmetric key.
When a computer requests a web page via HTTP, that request is unencrypted and insecure by default. The request — and the server’s response — might pass through half a dozen (or more computers) as it crosses and recrosses the Internet. All of those computers can view the exact page you’ve requested, along with the page’s complete contents.
In the early days of the web, this wasn’t a problem. Most websites were built to distribute academic papers, so there was little need for encryption or privacy.
This quickly changed when the public began using the Internet. Once the novelty of reading primitive websites faded, general users sought to use the Internet for activities like shopping and banking. This underscored a looming issue: Most people would be hesitant to share sensitive financial information without security.
The World Wide Web and its insecure HTTP requests didn’t have a way to solve this problem. Netscape, Inc. — the company that created the most popular web browser of the time — quickly realized that better security would be critical to the future of the web. Users would feel significantly more confident using the web for security-sensitive functions if connections were encrypted to preserve the data in transit.
As a result, Netscape created SSL in 1994, giving users the ability to make encrypted HTTPS requests.
Eventually, SSL was rebranded as TLS for non-technical reasons, and SSL 3.0 was upgraded to TLS 1.0. TLS 1.1 was later developed in April 2006. Its current version, TLS 1.3, was released in August 2018.
We can think of SSL as the origin of TLS. If not for the rebranding mentioned earlier, TLS 1.0 could have easily been called SSL 4.0.
However, TLS is designed with security in mind. It enables us to maintain secure encryptions, data integrity, and authentication practices. It also fixes some critical vulnerabilities in SSL 3.0.
In SSL 3.0, for example, handshake messages aren’t protected. This means that a man-in-the-middle attacker can seize a server’s response and modify it, tricking the browser into believing that the server will only support the weaker SSL cipher suites. This causes the browser to establish a connection protocol with much more inadequate security.
A man-in-the-middle attacker can quickly terminate sessions in SSL 3.0. These attackers can send a TCP FIN packet that closes the session, leaving the server uncertain whether the termination was authorized. Also, SSL 3.0 used MD5 for message authentication. This algorithm is known to be unstable, insecure, and unsuitable for use in modern contexts.
Finally, and most importantly, the Internet Engineering Task Force (IETF) deprecated older versions of SSL and TLS because they contain critical vulnerabilities. SSL 2.0 deprecated in 2011, followed by SSL 3.0 in 2015. Running a website that only supports old SSL versions will result in warnings from web browsers.
Payment processors also require that TLS1.2 or TLS1.3 be available on our sites’ servers and payment gateways. Without one of these protocols, payments will not be processed.
Finally, TLS 1.3 eliminates outdated cryptographic algorithms, enhances security over older versions, and secures client-server communication by encrypting as much of the handshake as possible.
SSL is the precursor to TLS. SSL 1.0 was never released because of several security flaws. The final version of SSL — SSL 3.0 — was released in 1996, after which it was rebranded as TLS. Subsequent releases have included TLS1.1, TLS1.2, and the most recent version, TLS1.3.
TLS comprises multiple protocol layers, with the handshake layer being the most important. It permits the website or web API and a client to authenticate each other and use encryption algorithms so a secure session between the client and website/API can be established.
All web browsers, servers, and HTTP client libraries should be configured to enable TLS 1.3 for optimal data encryption and security.
