TLS stands for Transport Layer Security. It is a cryptographic protocol used to secure data sent over a network, like internet traffic. General use cases include securing email, VOIP, online transactions, file transfers, and instant messages. TLS is designed to prevent data from being eavesdropped on or tampered with. It protects the integrity of private communications and sensitive information, including browsing habits, personal correspondence, online chat, conference calls, passwords, account numbers and other financial data, and social security numbers.
TLS secures the transmission and delivery of data. It does not secure data at endpoints and it does not encrypt data. It is a security protocol for HTTPS connections and not for insecure HTTP connections.
TLS is the successor of the Secure Sockets Layer (SSL) protocol. Netscape originally developed SSL in 1994 to secure its browser, Netscape Navigator. The last version of SSL was SSL 3.0. The first version of TLS, released in 1999, is based on SSL 3.0.
The terms SSL and TLS are often used interchangeably. This is because the first version of TLS, 1.0, was initially developed as SSL version 3.1. This means that, unless specifically stated otherwise, what is marketed today as an SSL certificate usually uses the TLS protocol. The term SSL is still used because people are more familiar with it. The term SSL/TLS is often used to describe the protocol.
The latest version of TLS is TLS 1.3, published in 2018 by the Internet Engineering Task Force (IETF). The IETF is an international standards organization originally tasked with orchestrating the development of the new protocol.
SSL 3.0 was officially deprecated in 2015. However, TLS provides backward compatibility for some older devices using SSL.
Apple, Microsoft, and Google will stop supporting TLS 1.0 and TLS 1.1 in 2020. This is partly because these TLS versions use outdated technologies, including algorithms like SHA-1 and MD5. Initially, websites using old TLS versions will display an error message. Eventually, all access to websites using deprecated TLS versions will be blocked.
Most of today’s web applications use TLS 1.2. The adoption of TLS 1.3 is expected to take time. Google has estimated that less than one percent of websites rely on TLS 1.0 or 1.1. There are workarounds, for example the LS_FALLBACK_SCSV extension, for legacy applications that are not compatible with TLS technology.
TLS has three primary functionalities and one de facto functionality:
- Encryption – Conceals data transferred between two parties, typically a client server and a web application. This prevents eavesdropping.
- Authentication – Certifies the identities of two parties communicating over the internet. This prevents impersonation attacks.
- Integrity – Verifies that the data being sent across a network has not been tampered with on its journey. This prevents man-in-the-middle attacks. The integrity is ensured by using a certificate issued by a trusted certificate authority (CA).
- Replay prevention – This protects against brute force attacks and man-in-the-middle attacks.
TLS is used to secure application layer protocols like FTP, HTTP, and SMTP, for example. These protocols provide most of the functions used to communicate on the internet, like sending emails, chatting, or downloading data.
TLS enables the authentication of digital identities. Typical enterprise use cases include single sign on (SSO), the verification of devices in an IoT network, digitally signed documents, email encryption to protect sensitive business information, and network access authentication.
TLS encryption helps protect internet applications from cyberattacks and data breaches. The protocol is the secure connection standard for most popular browsers.
Google Chrome recently started to warn users accessing HTTP pages that these pages are not secure. For businesses, the concern is that this could result in reduced customer trust. Therefore, Google, Apple, and Microsoft encourage the use of at least TLS 1.2.
TLS 1.0 and 1.1 are vulnerable to CRIME, BEAST, FREAK, LogJam and POODLE attacks, but TLS 1.2 and TLS 1.3 provide enhanced protection during data transfers. In addition, the Payment Card Industry Data Security Standard (PCI-DSS) requires at least TLS 1.2 for compliance.
TLS 1.2 and 1.3 support the latest cipher suites and algorithms, and have removed hash functions that are not secure, for example SHA-1 and MD5.
A TLS handshake initiates a TLS session. It is not the secure session event itself. The TLS handshake does not encrypt data but it does determine the encryption method. Data encryption takes place in a session, using the shared secret generated during the TLS handshake.
The TLS handshake begins with the negotiation of a TLS version and the selection of an appropriate cipher suite. A cipher suite is a combination of algorithms. Each algorithm has a task, for example, encryption, authentication, and key exchange. The server selects what key exchange algorithm will be used up front.
The handshake uses asymmetric encryption to initiate a connection. This encryption method has some overhead in terms of resources. A public key is used for encryption and a private key is used for decryption. In TLS, the key pair is used to create a shared key, sometimes called a shared secret, pre-master key, or master key. Once the handshake has been successfully completed, the session uses the shared key, or session key, to encrypt data in further messages between the client and the server. The session then uses symmetric encryption. This has a much lower overhead than asymmetric encryption and is more efficient.
An SSL/TLS handshake consists of the following messages and steps: ClientHello, ServerHello, Certificate (optional), ServerKeyExchange, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, ChangeCipherSpec, and Finished. Previous to TLS 1.3, the handshake is as follows.
- The client sends a list of all available TLS versions to the server. The preferred version is the latest version. The client also sends a list of suggested cipher suites. The client generates a random number that is used later. The client also checks to see whether this is a resuming session.
- The server confirms which options are acceptable for the connection. It also generates a random number that is used later.
- The server sends a signed digital certificate to authenticate itself to the client. Its public key is embedded in the certificate. When creating a TLS connection, the client checks for a valid certificate that has been signed by a trusted CA. A self-signed or invalid certificate will throw a warning message.
- The server sends a message saying that it is finished.
- The client creates a pre-master key and sends it to the server. The pre-master is encrypted with the server's public key. This key is extracted from the certificate previously provided by the server. Because this is asymmetric encryption, only the server can decrypt the message. After the server has received the pre-master key, it uses its private key to decrypt it. This process affirms that both parties are who they say they are. After the server has received the pre-master key, both server and client compute a master key using the previously generated random numbers and the pre-master key.
- The client sends its computed master key to the server. The client agrees to use the master key from now on. It changes the encryption method to symmetric.
- The client sends a message saying that it is finished.
- The server verifies that its computed master key is the same as the client’s. The server agrees to use the master key from now on. It changes the encryption method to symmetric.
- The final Finished message from the server is the first encrypted message that is transmitted using the shared secret. The shared secret, which is a session key, is also used in the Message Authentication Code (MAC) algorithm to verify that a message has not been altered.
As of TLS 1.3, the protocol is more efficient. The client makes a guess as to the best cryptographic protocol for the connection and shares its key in the first message it sends to the server. TLS 1.3 uses the elliptic-curve Diffie–Hellman (ECDH) protocol. ECDH is a key agreement protocol that enables a client and a server to share a secret key or to create a new secret key over a channel that is not secure.
TLS 1.3 was introduced to reduce the use of unsafe technologies like outdated algorithms, enable backward compatibility with older versions of the protocol, speed up connections, improve security, and use newer techniques like allowing fewer, more trusted cipher options.
TLS 1.3 ended the support of some outdated algorithms and ciphers, like the DES algorithm, RC4 cipher, SHA-1 hashing, CBC cipher, MD5 algorithm, RSA key exchange, and some (but not all) Diffie-Hellman encryption methods. TLS 1.2 supports 37 cipher suites. TLS 1.3 supports only five cipher suites.
Traditionally, one of the most popular ways to exchange secure session keys was the RSA encryption algorithm. RSA has been somewhat discredited because it does not provide an ephemeral (temporary or session-specific) key mode, something that is required for Perfect Forward Secrecy (PFS). PFS ensures that if an attacker saves encrypted information and somehow manages to steal the associated private key, they will still not be able to decrypt the information.
Four new features in TLS 1.3 help to speed up the TLS handshake. TLS Session Resumption checks whether a server and a client have communicated before, and if they have, some security checks are skipped. TLS False Start allows a server and a client to start transmitting data before the TLS handshake is finalized. The TLS 1.3 handshake requires only one round trip, instead of the two used in TLS 1.2. In TLS 1.2 and earlier versions, the first round trip includes the meet-and-greet steps. The second round trip includes the exchange of keys and the change of the encryption type from asymmetric to symmetric. Finally, Zero Round Trip Time Resumption (0-RTT) enables the generation of a master resumption key.
For website owners, TLS may appear to negatively affect the performance of their website. For example, in the event of high-volume traffic or reduced computing resources, TLS may appear to contribute to longer website loading times. A potential vulnerability is that TLS may sometimes allow a misconfigured server to choose a weak encryption method. The initial implementations of TLS could spark a temporary drop in traffic as the website may need to be reindexed. In addition, older add-ons and plugins may not be HTTPS compatible.
For general internet users, misunderstanding how certificates work may play a part in perceived TLS failures. For example, attackers can take advantage of expired or untrusted certificates. Although a browser will display a warning that a certificate is expired or untrusted, some users may ignore this warning.
TLS may mistake a firewall for a man-in-the-middle attack. Designed to provide comprehensive end-to-end encryption and security, TLS prevents network security tools from inspecting traffic to detect potential malware. To prevent a man-in-the-middle attack, the client is prevented from inspecting its own data and from ensuring that it is free of malware. The means to do this inspection is via a middlebox, but the middlebox can be mistakenly identified by TLS as a man in the middle and can sometimes prevent legitimate access to the server. The financial industry has lobbied for changes to the way middleboxes work.
TLS is also vulnerable to downgrade attacks. RSA is a key exchange algorithm used by all versions of TLS except version 1.3. RSA determines how a client and a server will authenticate their credentials during the TLS handshake with the goal of negotiating a shared secret. However, RSA is vulnerable to side-channel attacks. These kinds of attacks are indirect and unintended. They are usually a result of a faulty implementation of a cryptography system, which unintentionally allows the leakage of information that an attacker can use to discover the private key for a conversation. This can be compared to a thief challenged by the security system of your car. Instead of trying to break into the car on site where the alarm will alert you, the thief simply loads the vehicle onto a flatbed truck, takes it somewhere else, and breaks in there.
Despite those weaknesses, TLS is indispensable in online communication. Regular updates of the protocol ensure further improvements in security and performance.
- https://www.wst.space/ssl-part1-ciphersuite-hashing-encryption/
- https://www.networkworld.com/article/2303073/lan-wan-what-is-transport-layer-security-protocol.html
- https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/
- https://www.internetsociety.org/deploy360/tls/basics/
- http://techgenix.com/ssl-tls-disadvantages/
- https://www.openssl.org/~bodo/ssl-poodle.pdf
- https://owasp.org/www-project-cheat-sheets/cheatsheets/Transport_Layer_Protection_Cheat_Sheet
- https://www.thesslstore.com/blog/apple-microsoft-google-disable-tls-1-0-tls-1-1/
- https://duo.com/decipher/browsers-will-block-sites-using-old-versions-of-tls-in-march
- https://www.symantec.com/connect/articles/tls-13-its-out-there-are-you-ready
- https://www.thesslstore.com/blog/tls-1-3-everything-possibly-needed-know/
- https://www.thesslstore.com/blog/tls-1-3-handshake-tls-1-2/
- https://owasp.org/www-chapter-london/assets/slides/OWASPLondon20180125_TLSv1.3_Andy_Brodie.pdf
- https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/
- https://security.stackexchange.com/questions/73244/can-we-have-https-without-certificates