Blog - Channel Partner
The evolution of TLS and new Azure requirements
![The evolution of TLS and new Azure requirements](/images/news/1781/_thumb3/the-evolution-of-tls-and-new-azure-requirementsblog-image.jpg)
Most of us know TLS (Transport Security Layer) as a common household name already. While researching the history of SSL (Secure Socket Layer), you might have come across the different versions of the protocols and how it has evolved.
Just in short, for those that need an easier way to understand this - a web server and a user’s web browser can communicate securely by using encryption protocols such as SSL and TLS. These protocols use public and private keys to establish a secure session between the server and the browser. TLS is a newer version of SSL that has some differences in how it generates secret keys and MAC functions and has more alert codes for error handling.
Some History
As Netscape was released back in 1995, the first stable version of SSL was introduced. However, as more and more vulnerabilities were found and while the well-known browser evolved, a more secure version had to be designed to accommodate the latest threats. These versions ranged from SSL 2.0 up to SSL 3.0. Google even used SSL 3.0 until 2014 until their security team found the major vulnerabilities the protocol opened their browser to.
TLS emerged in 1999 as a new protocol to improve upon SSL 3.0. The changes between the two protocols are not very drastic, but they are enough to prevent SSL 3.0 and TLS 1.0 from working together. SSL 3.0 is considered less secure than TLS. A newer version of TLS was introduced in 2006, followed by another one in 2008, and finally the latest one since 2015. The current version of TLS is 1.3, which has more security features than SSL 3.0. TLS aims to prevent attacks and reduce risks on each version by adding more protection mechanisms.
SSL 3.0 has many security flaws that make it obsolete. One of the most serious ones was discovered by a Google team in 2014 as mentioned earlier and it was named POODLE. This vulnerability could allow an attacker to decrypt encrypted data sent over SSL 3.0. POODLE is a vulnerability that exploits the SSL 3.0 fallback mechanism that clients and servers have. This means that the attacker can force the use of SSL 3.0 and then decrypt some parts of the session data. By doing this repeatedly, the attacker can get a lot of information from the server and client communication. POODLE can affect any system that supports SSL 3.0 with ciphers that use cipher-block chaining mode.
What’s the difference?
SSL and TLS are often seen as similar, but they are not exactly the same. They both use encryption to protect the data that is transmitted over the internet, but TLS is an improved and more secure version of SSL. TLS is the preferred option for ensuring the security of online transactions. A server can support multiple versions of SSL and TLS at the same time.
The security vulnerabilities of SSL 3.0 have been known for a long time, and they required a better solution. Like any other technology upgrade, there are some changes in each version, but the result is the same for the user. SSL or TLS are usually interchangeable terms unless they specify the different versions of the protocol.
End of Support for TLS 1.1 on Azure
There is no known vulnerability in the Microsoft version of older TLS versions, but TLS 1.2 and 1.3 provide better security with features like perfect forward secrecy and stronger cipher suites. To avoid any disruption or security risks, make sure that your resources that connect to Azure services use TLS 1.2 or later before 31 October 2024. This is the deadline for retiring TLS 1.1 and earlier versions from Azure. Please contact your Surestep Ambassador team at This email address is being protected from spambots. You need JavaScript enabled to view it. to look at more innovative and secure ways to provide your customer with cloud-based solutions.