Discover the magic behind TLS 1.2, the secure protocol supported by 99.9% of browsers. Learn how it can keep your data secure in transit. Explore what it does, where it’s used, and find out why you can’t do without it
In 2022, more than 85% of attacks analyzed by Zscaler ThreatLabz researchers were leveraging encrypted channels, including the secure socket layer (SSL) and the transport layer security (TLS). As cybersecurity evolves, so do bad guys. They’re always looking for new, creative ways to avoid detection and circumvent strong encryption.
With cyber threats lurking everywhere, the focus on more TLS secure protocols (like TLS 1.2) has become paramount for every organization. Amazon Web Services (AWS) announced that TLS 1.2 will become the minimum TLS protocol required by all its API endpoints by June 2023. The National Institute of Standards and Technology (NITS) also names TLS v1.2 in its standards as a minimum for government servers.
Want to protect your organization from data breaches and ensure you make the most of the protection offered by TLS 1.2? In our previous article on the different TLS versions, we gave you an overview of the TLS family, from the early TLS 1.0 to the latest 1.3. Now, we’ll take you on a deep dive into the most popular TLS protocol version to date. Ready to learn the nuts and bolts of TLS 1.2? Let’s rock and roll!
What Is TLS 1.2 and What Does It Do?
TLS 1.2 is one of the two main secure protocols in use for most websites. It creates a secure connection between two endpoints keeping your data transmitted over the internet private, and safe from snoopers. Published in 2008 by the Internet Engineering Task Force (IETF), it’s safer than its predecessors as it provides enhanced protection against attacks like POODLE and Heartbleed.
It’s the most widely supported protocol — TLS 1.2 is supported by 99.9% of browsers, versus 59.8% that support TLS 1.3, according to SSL Labs. What does this protocol do, exactly?
Let’s say you want to buy a smartphone online. Once you’ve selected your model, you enter your personal details (e.g., name, email address, postal address, telephone number) to complete the transaction. You then pay for it by typing in your credit card information. TLS 1.2 protects all those sensitive data during their transmission from your web browser to the server, to ensure that they aren’t intercepted or compromised by a malicious third party while in transit.
How? TLS 1.2:
- Encrypts the data transferred over the internet between two parties (e.g., web application and server). This helps to prevent cybercriminals from eavesdropping on your conversations or stealing your data in transit.
- Authenticates the identities of the two communicating parties. This helps you avoid impersonation attacks where a cybercriminal poses as a trusted person to steal sensitive information (e.g., CEO fraud).
- Verifies the integrity of the data being sent. This helps to ensure that your data hasn’t been modified in transit. Thus, helps you prevent man-in-the-middle attacks when a bad guy intercepts a message or a data transfer.
Curious to know what really happens behind the scenes? Read on!
How Does the TLS Version 1.2 Work?
Let’s go back to the example we just made. To buy your smartphone, the first thing you do is go to the website selling it. To do so, you’ve to connect with it. And that’s where it all begins — with the TLS handshake between your device (client) and the web server hosting the website.
During the handshake, your client and the web server will:
- Authenticate the server. To do so, they’ll use asymmetric cryptography (i.e., data are encrypted and decrypted using a public key and a private key) and the server’s TLS certificate, which was issued by a certified authority (CA). This process ensures that the connection is really being established with the intended recipient of the message.
- Negotiate the cipher suites. In other words, they agree on the cryptographic set of algorithms to utilize for secure communication (more on this in a minute).
- Generate session key. Both the client and the server establish a session key that’ll be used to symmetrically encrypt (i.e., the same key is used for encryption and decryption) the transmitted data once the encrypted connection is established.
It’s a bit like when two people from two different countries meet for the first time. As they speak different languages, they first establish a common language to use (the cipher suite), then they introduce each other (authentication). Let’s have a deeper look at these three major steps of the TLS 1.2 handshake.
1. Cipher Suite Negotiation in TLS V.1.2
In the first step, what’s often called the “client hello”, the client initiates communication and shows the server the supported cipher suites. In response, the server sends its SSL/TLS certificate over and picks its preferred ciphers from the list. It’ll then use that info to establish secure communications with the client (i.e., server hello).
What does a cipher suite look like? In TLS 1.2, every cipher suite is composed of four distinguished parts. Let’s take a common one as an example and analyze it bit by bit.
- Key exchange/generation algorithm. ECDHE or elliptic curve Diffie Hellman ephemeral, is an example of an algorithm the client and server will use to generate a symmetric encryption key. Other examples of key exchange algorithms include RSA, Diffie-Hellman (DH), and elliptic curve Diffie-Hellman (ECDH). We’ll learn more about those in a moment.
- Authentication/digital signature algorithm. ECDSA, or elliptic curve digital signature algorithm, is utilized by the server to create a digital signature. How? By encrypting two randoms and its pre-master secret with its private key. The client will then use the public key to verify the signature and authenticate the server. It’s a variant of the digital signature algorithm (DSA). Its key features? It’s more secure than RSA and, thanks to its shorter keys, it has a better performance.
- Data encryption/decryption ciphers. AES128-GCM, or advanced encryption standard in Galois counter mode (GCM), is a block cipher that’s used to encrypt and decrypt the data transmitted in blocks of a pre-determined size. Among other bulk ciphers we can find CHACHA20_and POLY1305, stream ciphers encrypting data bite by bite in a linear way, and older block ciphers like DES, Triple DES, and RC4.
- Data integrity/authentication. SHA256, also called secure hashing algorithm 256, creates a 256-bit digest (i.e., the fixed size value representing the content of the hashed message). It’s the method used to identify tampering or errors during data transmission and authenticate the message. SHA-256 is recommended and approved by the National Institute of Standards and Technology (NIST). Other TLS 1.2 hashing algorithms used include MD5 and SHA-1 (both deprecated) and the more recent SHA-384.
In simple terms, ECDHE is used during the key exchange, then the ECDSA is used for authentication, AES128-GCM for data encryption and decryption, and last but not least, SHA256 is the hashing algorithm used to verify the integrity of the message.
2. Authentication in TLS 1.2
The Cipher suite agreed, it’s now time to authenticate the server. How? The server sends its TLS certificate issued by a trusted certificate authority (CA) to the client. The certificate acts like a passport: it officially certifies that the server is really who it says it is.
The client checks the certificate’s authenticity (e.g., it was issued by a trusted certificate authority), its digital signature, and verifies that the server has the associated private key.
The algorithms that can be used for authenticating digital signatures are the Rivest-Shamir-Adelman algorithm (RSA) and the elliptic curve digital signature algorithm (ECDSA). Let’s have a look at their key differences.
|One of the oldest digital signature algorithms.||Replaces the old digital signature algorithm (DSA).|
|Based on asymmetric encryption.||Based on the mathematical representation of elliptical curves.|
|Requires Longer keys (e.g., 2048-bit).||Requires shorter keys (e.g., 521-bit)|
|Slower and vulnerable to attacks.||Faster and more difficult to breach due to its complexity.|
- RSA. One of the oldest, it can also be used for key exchange. It’s a simple asymmetric encryption algorithm that uses a public key to verify the private key digital signature. As it requires longer keys than ECDSA to guarantee an acceptable level of protection, it’s slower than the latter. Did you know that, according to research, 1 in every 172 digital certificates using RSA Keys is vulnerable to attacks?
- ECDSA. It replaces the old digital signature algorithm (DSA) and follows a similar procedure to the RSA, with some fundamental differences. Based on the mathematical representation of elliptical curves, it’s much more complex than RSA. The server creates a digital signature by encrypting two random parameters and a pre-master secret (i.e., Diffie- Hellman parameter) with its private key. The client uses then the public key to verify the private key digital signature. I know, it sounds complicated, but it uses smaller keys (e.g., 224 or 256-bit) than its predecessor making it much less expensive to compute.
3. Session Key Generation in TLS Version 1.2
And we’ve now reached the last part of the handshake, where the last ingredient of the magic formula is created. This is the session key that’ll be used by both the server and the client for secure data exchange.
Depending on the method chosen (RSA or Diffie-Hellman key exchange), the process differs slightly. Let’s take a quick look at these two key exchange/agreement methods:
The RSA Key Exchange
The client and server exchange two random large prime numbers, which are called randoms. After that:
- The client sends a pre-secret (i.e., a random string of bytes), encrypted with the public key to the server.
- The server decrypts the pre-secret message with its private key.
- Both the client and the server use the client random, the server random, and the pre-master secret to generate the master secret.
- Both use the master secret and other pseudo-random functions to calculate the session key. The handshake is completed.
The Diffie-Hellman Key Exchange
- The client and the server agree on two public variables, a prime modulus and a generator.
- They then each pick a private value (i.e., a key) to keep to themselves — they never share these values.
- Both parties compute new values locally on their individual ends. How? By combining their own private key with the public variable.
- They exchange the generated values with one another and add their private values to it locally, creating a shared secret.
- If the resulting values match, they can begin a secure data transmission.
What is the main advantage of the Diffie-Hellman key exchange? The shared value is never exchanged. This makes it really hard to steal because the data is never transmitted between the two parties. Want to get to know better the Diffie-Hellman key exchange? Don’t miss this interesting video from Computerphile:
Would you rather further explore how a TLS 1.2 session is negotiated? Check out Xargs’ interactive guide illustrating every single step in fine detail.
Where Is TLS V.1.2 Used?
What’s the first thing that comes up to your mind when I mention TLS? I guess secure web browsing. In fact, the majority of websites now use at least TLS 1.2 on top of the hypertext transfer protocol to secure data transmission over the network, resulting in the HTTPS (hypertext transfer protocol secure) protocol.
How do you know a website uses it? It’s easy. When visiting a website, have you ever noticed a small padlock in the browser address bar, followed by HTTPS in the URL (meaning the web address starts with https://)? Those are the two signals that the site has its connection secured with at least, TLS version 1.2.
But TLS 1.2 is used in combination of several other application protocols too, enabling you to secure also:
- Email transmission. Used on top of the SMTP protocol (e.g., STARTTLS), it’ll add encryption to your email in transit protecting them from attacks like SMTP injection. In this type of attack, a cybercriminal injects a malicious command during transmission that’ll be used to send spam, phishing, or steal sensitive information.
- Data download. Do you use the file transfer protocol (FTP) to download data from a server? TLS 1.2 on top of it (i.e., FTPS) will keep the credentials used to connect to the server and the download safe from prying eyes (e.g., no TCP/IP packets sniffing). Clients like FileZilla support it.
- Chat apps. Everybody uses chat apps nowadays. Whatsapp, Signal, Facebook Messenger, you name it. And nearly all of them support TLS 1.2 to keep your private chats secure. Did you know that Telegram opted for MTProto instead? Is it more secure than TLS? Apparently, it isn’t, based on the vulnerabilities identified by researchers in 2021.
- Internet of things (IoT). My nephew and his spouse just had a baby. Like all first-time parents, to make sure they can keep an eye on him all the time, they bought a high-tech, smart baby monitor with a gazillion of features and a dedicated app. How do you think all those precious, sensitive data about the parents and the newborn, going back and forth over the network are protected? With TLS 1.2. The same goes for all those IoT applications using Azure IoT Hub for example.
OK. Now we know how TLS 1.2 works and where it’s mostly used. We also know that its major advantage is security. But is there anything else that organizations supporting it can benefit from? And what about its downsides? These are the two questions we’re going to answer next.
The Good and Bad of TLS 1.2
Nobody/nothing is perfect, every rose has its thorn, and every silver lining has some tarnish. Yup. No matter how you put it, the yin and yang are always present, above all in the digital world. And our TLS version 1.2 is no exception.
So, why should your organization support TLS 1.2 if it isn’t perfect? Firstly, in cybersecurity perfection doesn’t exist. It’s simply impossible to achieve. But TLS 1.2 can grant your business a series of benefits, such as:
- Increase your organization’s level of trust and credibility. Why? Would you trust a website if, when you try to access it, your browser shows you the error message “Secure Connection Failed”? Because that’s what your customers would see if your websites support only previous TLS versions like TLS 1.0 or 1.1.
- Improve the ranking of your webpage in Google search pages. Google started including HTTPS (and therefore TLS) as a ranking signal nearly 10 years ago (2014) as a way to increase security and boost TLS adoption. Many years have passed, but if you want to make sure your website populates among the latest Google search results, implementing TLS 1.2 as a minimum is still a must.
- Align with all internet services like PayPal, and Stripe, already mandating TLS 1.2 or higher. Think about it — would you really trust a website supporting only deprecated TLS protocols with your credit card information? Very few would. Is your organization selling products and/or services online? Beware, a recent study forecasted the cost of online transaction fraud to merchants will surpass $48 billion in 2023.
- It’s used (and often required) by devices, servers, endpoints, and applications. Yup. It doesn’t matter if it’s the latest smartphone, Microsoft Azure active directory (Azure AD), or an API you developed. TLS 1.2 is the minimum requirement that’ll add another layer of security to your data transmission.
- Help you reach compliance with security and privacy regulations. I remember when the EU General Data Protection Regulation (GDPR) initially launched. Oh boy! Ensuring compliance was a big headache and took a lot of time and effort. Implementing TLS 1.2 will speed up the process a tad and help you tick off some of those missing items on your compliance list. By the way, this also applies to the Health Insurance Portability and Accountability Act (HIPAA, in case you’re in the health sector) and the Payment Card Industry Data Security Standard (PCI-DSS). While you’re at it, don’t forget to check the new PCI-DSS version 4.0 requirements!
- Minimize the risk of data breaches (and money loss). More than $5 million per incident — this is the average cost of a data breach in 2023 estimated by Acronis. TLS v.1.2’s more secure cipher suites and algorithms, and the fact that it isn’t vulnerable to several attacks (e.g., POODLE, BEAST, Heartbleed…) that plagued its predecessors make it a valuable addition to your data breaches protection arsenal.
All this sounds pretty reassuring. So, why did the IETF guys bother creating and launching another more recent version, TLS 1.3? Because, as we said before, TLS 1.2 has some downsides, too:
- Its handshake is slow, complex and relies on older algorithms. As described in our previous article, TLS version 1.2’s handshake is made of two round trips, while TLS 1.3 has only one. On top of that, it also relies on some old cryptographic algorithms that aren’t secure anymore. Can you imagine using it for IoT connections for example, where speed and security are everything? And with the number of connected IoT devices forecasted to reach more than 17 billion in 2023, sluggishness and security issues are a no go.
- It’s more secure than TLS 1.0 and TLS 1.1 but less secure than TLS 1.3. Wouldn’t be marvelous if every time you unlock your front door a new key (and matching lock) is magically generated? If you ever lose your house key and a burglar finds it he won’t be able to use it anyway. It was only working for one time. This is what perfect forward secrecy does in TLS 1.3, where it’s enabled by default. One new key is generated for every new session.
- Complexity doesn’t always pay off. TLS 1.2 uses a more complex cipher suite with a higher number of combinations (37), including also weaker encryption algorithms and ciphers. TLS 1.3 supports only five, the strongest ones. Sometimes less is more.
Maybe TLS 1.2 isn’t going to save the digital world, but overall it’s still considered a valid protection for all those endpoints and devices unable to support TLS 1.3. Now that you have a better knowledge of TLS version 1.2, ensure you make the most of the protection it offers!
Final Thoughts on What Is TLS 1.2? A Look at the Secure Protocol
To successfully protect your website and organization from data breaches, you’ll need to do more than simply purchase a digital certificate and hope for the best. As technology evolves, knowing the inside outs of the most widely supported TLS protocol has never been so crucial. It’ll enable you to adopt a more secure configuration for your web server that’ll reduce the risks of cyberthreats.
What are you waiting for? Put into practice what you’ve just learned:
- Prefer the cryptographically secure digital signature scheme ECDSA to the classic but vulnerable RSA.
- Deactivate the support of the now officially deprecated TLS 1.0 and 1.1.
- Implement TLS 1.2 everywhere to protect not only your website but also your emails, downloads, and private conversations via chat apps.
- Review your platforms, applications, and legacy systems that may still need to be upgraded to TLS 1.2.
- Set TLS 1.3 as an option so that browsers that support it can connect to your server using that more secure protocol, but leave TLS 1.2 as an option for those that don’t.
And remember: even if TLS 1.3 is already available and should be installed where possible, TLS 1.2 remains a valid alternative that’ll ensure data security and protection for your organization and customers alike.