Menu
Menu
Table of contents
Transport Layer Security TLS is a widely deployed security protocol that is used to protect data transmitted over the Internet. It prevents the interception of confidential information by cybercriminals. TLS is used to secure emails, website viewing and other web applications.
TLS encryption protocol is used to securely transmit Internet traffic that is supported by most operating systems. If you look at the address bar in your browser, you will see a closed padlock icon to the left of the address. This means that the connection between your device and the website you are currently on is protected by the TLS encryption protocol. It is also applied to organize secure sessions for most of today’s applications. File transfers over the web, IP telephony, video conferences, instant messengers, as well as basic elements of the Internet structure, such as DNS and NTP, all depend on TLS.
TLS was developed on the basic principles of the previously existing Secure Socket Layers (SSL) protocol, which was introduced in 1994. However, between the first SSL version 1.0, which did not receive mass adoption, and the version of SSL 3.0 that started to be used everywhere, five years passed. Therefore, the official date of the first release of TLS protocol specification is 1999, when RFC 2246 was published. Initially, TLS was a separate protocol deployed in parallel with SSL. But in 2015 SSL 3.0 was recognized as insecure and since then only use of TLS has been recommended by Internet Engineering Task Force, IETF .
Since TLS is designed to encrypt data in motion, it cannot be used to encrypt data at rest.
First version of TLS was based on the Secure Sockets Layer SSL protocol and the functions of these protocols were similar, ssl certificates were often called TLS certificates. Current versions of the protocol support compatibility with the legacy SSL protocol. Therefore, today the term SSL is used together with TLS – SSL/TLS – to describe the TLS protocol.
The current protocol version at the time of publication is TLS 1.3. This version was released in 2018 by the Internet Engineering Task Force (IETF). Today, this standardization organization manages the development of a new protocol. The previous version of TLS 1.2 is still in use and has not yet been deprecated, the full transition to TLS 1.3 is still not complete.
Despite the recognition of the SSL protocol as insecure, it continues to be used on older hardware and software. The same thing happens with legacy versions of the TLS protocol: TLS 1.0 and TLS 1.1. These versions of the protocol are considered insecure because they use the SHA-1 and MD5 hashing algorithms. Most modern web browsers by default do not open pages of sites that use outdated versions of the TLS protocol. However, nowadays the number of such sites is less than one percent of the total.
Until the mid-90s, most of the data on the Internet was transmitted without the use of encryption. Only such sensitive data as passwords and cardholder details were in form of encrypted traffic during transmission. However, later it turned out that the constant growth of services that are provided on the Internet and increasingly advanced hacking methods used by attackers, require greater responsibility in ensuring the security of data transmitted on the network. Currently, regulators recommend using encryption wherever possible when it comes to web applications that transmit any type of user data.
If TLS wasn’t used today, it’s most likely that online transactions, passwords, and other sensitive data would be protected in some other way. However, correspondence in instant messengers and e-mails, calls with IP-Telephony and videoconferencing could be easily intercepted. That’s why it’s mandatory to use TLS in client-server applications in order to be certain that transmitted data are protected by encryption algorithms and cannot be obtained by a third party. Using the TLS protocol you can ensure that data have not been spoofed by an attacker on the way from the sender to the recipient.
The TLS protocol implements a hybrid cryptographic approach: it uses both asymmetric and symmetric encryption algorithms. This improves the security of the algorithm while keeping the requirements for computing power at a low level.
Symmetric cryptography involves using the same encryption key for both encryption and decryption.
During a TLS handshake a secret key is generated to encrypt data between the TLS client and server. The secret key is used in a mathematical formula that is applied to the data to transform plaintext into unreadable ciphertext, and ciphertext back into plaintext.
The secret key is generated from the random text sent as a part of the handshake and is used to encrypt plaintext into ciphertext. The secret key is also used in the MAC (Message Authentication Code) algorithm, which is applied to determine whether a message has been altered.
The performance required for the implementation of such algorithms is not too high in comparison with asymmetric cryptography. However, it’s of the most importance that the encryption key must be transmitted in a secure form, otherwise if an attacker intercepts the key, he can easily decrypt data.
Asymmetric encryption algorithms use public and private keys. The public key is used for encryption and the private key is used for decryption of data. By doing so it is extremely difficult to recover the server’s private key, which, in turn, is easier to protect, since it doesn’t need to be transmitted. However, asymmetric cryptography is more demanding on computing power.
In TLS, asymmetric cryptography is used to encrypt the session key of a symmetric encryption algorithm. The recipient sends his public key to the sender. He encrypts the symmetric session key with it and sends it to the recipient. The sender then encrypts the data with a symmetric key and the recipient is able to decrypt the received data.
In cryptography, a certification authority or certificate authority (CA) is a trusted third party online service whose public key is widely known. Certification authorities verify the authenticity of client’s encryption keys using electronic signature certificates. Technically, the CA is responsible for managing user’s’ cryptographic keys. Public keys and other information about users are stored by certification authorities in the form of digital certificates.
When connecting to a web site server, most modern web browsers can use the server’s public key certificate to verify the digital signature released by the CA. Browser’s certificates are signed with public keys of the CA. In case of a problem while verifying the certificate, a warning will be shown stating that the connection may not be secure. This is possible due to the fact that public keys can be used to verify web servers digital certificates signed with CA private keys.
For a server’s TLS certificate to be trusted by a client, the client must be configured to trust the Certificate Authority (CA) that signed the server certificate. Many CAs do not sign with their root certificate, but instead with an intermediate certificate. Clients, however, may only trust the root CA. Therefore the server is often required to present a full certificate chain along with their TLS server certificate.
It is impossible for an ordinary user to compromise or replace the root certificate on his website. All existing options for a user to issue and use his own root certificate apply only for the period of local testing of his own web resource, when there is no technical difference if the legal public CA is used. To create a legitimate security key, you will need to become a “certificate authority” yourself. This is a troublesome and costly business, and it’s definitely easier to contact one of the existing organizations.
TLS was developed from the base of SSL. Despite support for earlier TLS versions, it does not interact directly with SSL. Also, SSL is now a no longer supported insecure protocol,, meanwhile a new version of TLS is being developed at the moment. In part, TLS can be called a descendant of SSL. TLS is a more secure protocol, as it uses modern more efficient and secure cipher suites, supports encryption key generation, and newer hashing algorithms.
Read also: SSL vs TLS – What’s the Difference?
TLS is used to secure the Hypertext Transport Protocol (http). Simply put, https is a TLS-secured http protocol. A combination of these two protocols is used for secure data transfer between sites and the browser, as well as in other web applications. In general, https can be seen on the address bar before the site name: if everything works correctly, you can see a closed padlock to the left of the address bar.
Since encryption was recognized as the default for transmitting data over a network, TLS has become common in website security and web applications security. Less than one percent of sites today do not use an up-to-date version of TLS. For example, google chrome browser doesn’t open such pages and notifies it’s users that it is not safe to visit similar sites. This may lead to reduced website traffic or web service usage.
The main problem when using TLS is the initial connection establishment (TLS handshake) between the client and the server. Establishing a connection takes time, processing power, and some memory capacity on both sides.
In order to reduce the connection establishment time, several approaches have been implemented. The first of them, TLS False Start, allows you to start a secure data exchange until the moment when the handshake process is completed. The second technology, TLS Session Resumption, makes it possible to very quickly establish secure connections between participants, if such connections have been established before.
After a connection is established, an insignificant computing resource is required to encrypt and decrypt the transmitted data, which can be neglected in modern realities.
In the TLS 1.3 protocol version, instead of four handshake stages there are two, and if the connection has already been established before, the connection will be established almost instantly without requiring the usual TLS handshake process.
The Transport Layer Security protocol has different types of benefits. The first of them is a benefit we get from direct protocol assignment. In other words, it’s the protection of transmitted data with strong cryptographic algorithms, secure authentication process, and privacy and data integrity checks made by TLS Record Protocol. The second benefit is a more detailed differences report in contrast to other transmission data protection protocols. TLS is most often compared to Internet Protocol Security (IPsec). Due to many qualitative differences, some organizations are moving away from IPsec entirely in favor of TLS:
Using the TLS protocol, you can provide data security at the application layer without the need of additional hardware or software. This is very convenient, as opposed to IPSec when you have to deploy hardware or separate software.
Despite everything mentioned above, the TLS protocol has its drawbacks as well. They are connected with both its architecture and with the history of its application. The ones worthy of being noted are:
TLS 1.3 was released in 2018. It took four years to develop it. This was due to the fact that it substantially differed from previous versions in the quantity and quality of changes. Much attention has been paid to known vulnerabilities and other issues of previous versions.
The main changes were made to those parts of the protocol that were related to security, privacy, and performance. Modifications in TLS cipher suites have made it much more difficult to decrypt intercepted https traffic by a third party.
Not only that, the handshake procedure has also been upgraded in TLS 1.3. In addition to speeding up the process of encrypting keys at the stage of establishing a connection, the sequence of actions itself has been reduced. If earlier during a TLS handshake protocol it took about three rounds of messaging, now this number has been reduced to one. At the same time, it became possible to transfer data before the end of the TLS connection establishment procedure.
TLS 1.3 was developed with a smooth transition from the old version in mind. The updated version works with the same certificates and keys as the previous version 1.2.
The problems of specific implementation differences apply to all data encryption systems. Transport Layer Security protocol is recognized as a secure algorithm and TLS 1.3 is not marked with any vulnerabilities. However, implementations of previous TLS versions of the algorithm were declared insecure for a reason. It’s also worth mentioning that attacks such as Compression Ratio Info-leak Made Easy (CRIME), Browser Exploit Against SSL/TLS (BEAST) and protocol downgrade attacks were implemented by updating the TLS version. Here are known examples of vulnerabilities in implementations of the TLS protocol:
It’s difficult to imagine the modern Internet and digital environment without the TLS protocol. However, the important part is not only its presence, but also the correct configuration of data in motion protection systems. Helenix is a company with many years of experience in developing, implementing and providing encryption systems for both: common scenarios and unique individual tasks. Learn more about our competencies or leave an inquiry in the Contact section.
TLS is a protocol widely used on the internet to protect data in motion. It operates using asymmetric and symmetric encryption as well as hash functions.
The TLS protocol is employed to protect data that applications send to each other over the Internet. Its main purpose is to prevent hackers from intercepting or spoofing data.
TLS is used in emails, when transferring files over the Internet, in IP telephony and video conferencing, during exchange of data between the browser and web sites, as well as in many other applications.
TLS is used in emails, when transferring files over the Internet, in IP telephony and video The most common protocol used in conjunction with TLS is the Hypertext Transfer Protocol (http). This protocol enables the browser to display the content of the website’s pages when requested by the browser.