Transport Layer Security (TLS) / Secure Sockets Layer (SSL) is an encryption protocol that is used for secure and confidential data transmission in networks (e.g. the Internet).
The protocol was originally called Secure Sockets Layer. With the introduction of TLS 1.0, the term Transport Layer Security was introduced. The terms TLS and SSL are often used synonymously in practice. The protocol versions SSL 1.0-3.0 as well as TLS 1.0 and 1.1 are out of date and insecure and should no longer be used. The current version of the protocol is TLS 1.3.
TLS combines asymmetrical and symmetrical encryption methods (hybrid encryption protocol) in order to enable two parties to encrypt communication over a network. If content is not encrypted during the transfer, there is a possibility that other participants (e.g. network operator or other parties with access to the data traffic) read or change this content.
A session is encrypted in two steps:
Step 1: TLS-Handshake
In order for the communication to be considered secure, at least one of the communication partners must confirm their identity using an asymmetric cryptographic process. When communicating on the Internet, this is usually the server. So-called public key certificates are usually used for this. These confirm the identity and properties of a public key of the certificate holder, provided the certificate is issued and authenticated by a trustworthy certification authority. In most cases, the RSA cryptosystem is used for this step.
After the authentication has been carried out by checking the certificate, an asymmetric cryptographic process is used again, through which the partners agree on a shared, secret key that can then be used for further encryption of the data traffic. As a rule, the Diffie-Hellman protocol is used here. The Diffie-Hellman key exchange allows the communication participants to calculate a common key from this data by exchanging unencrypted data. Both partners have a different private part as the basis for the key exchange. This private information is not transmitted and must absolutely remain secret. A potential attacker cannot use the public information that is used to agree the secret shared key to calculate the shared secret key or to guess it in a realistic time.
The Diffie-Hellman protocol is therefore particularly useful for encrypting content on the Internet via the HTTP standard, because the usual communication partners in this context, a web server and a client (or its Internet browser) usually have no information about each other and thus cannot have a common key in advance with which they could encrypt content symmetrically.
Exemplary representation of the Diffie-Hellman protocol
As soon as a shared secret key has been agreed, this can be used to encrypt the actual content of the communication in order to then transmit it. A symmetrical encryption method can be used for this. With this method, content is both encrypted and decrypted with a key, the encryption is therefore reversible and therefore symmetrical. The currently most common symmetrical cryptosystem is the Advanced Encryption Standard (AES) with which information can be encrypted with keys of length 128 bits (AES-128), 192 bits (AES-192) and 256 bits (AES-256). The longer the key used, the more secure the encryption. This algorithm is also frequently used with TLS, but other encryption methods can also be used.
In addition to encryption, Message Authentication Codes (MACs) are also used. These are used to guarantee the integrity and authenticity of the information, since an attacker could otherwise change content unnoticed without being able to decrypt it. With TLS, a hash-based message authentication code (HMAC) is usually used for this. A hash algorithm (e.g. SHA-384) and the shared key are used. The hash algorithm used is agreed during the TLS handshake. Since only the two communication partners have both information (algorithm and secret key), only these two parties can generate appropriate HMACs from their data to be transmitted. If the received code deviates from the self-calculated and expected code, this indicates an unwanted change in communication due to manipulation or errors.
There are various so-called cipher suites for TLS which standardize the use of certain encryption and authentication methods. These suites dictate which procedures are used for the following steps in the protocol:
- Key exchange (e.g. Elliptic Curve Diffie-Hellman Ephemeral)
- Authentification (e.g. RSA)
- Encryption (e.g. AES)
- Hash and Message Authentication Code (e.g. SHA384)
Example Cipher Suite:
ECDHE – RSA – AES256-GCM – SHA384 </ span >
- Key exchange (Elliptic Curve Diffie-Hellmann Ephemeral)
- Authentification (certificate verification by RSA)
- Encryption of communication
- Hash method for checking the integrity
As part of the TLS handshake, the communication partners agree on a Chiper Suite, which is then used.
With the current standard of the TLS 1.3 protocol, part of the protocol has been firmly defined. The Elliptic Curve Diffie-Hellmann ephemeral method must be used for key exchange. This has the advantage that so-called “forward secrecy” is given because the generated key is only valid for one session. If a single key is known, it can only be used to decrypt the communication of a single session and not all of the data traffic exchanged up to that point. The TLS handshake can run faster by specifying the procedure for key exchange.
Exemplary representation of the TLS 1.3 single round trip handshake
Another change in version 1.3 is a significant reduction in the number of permitted cipher suites. While there were 293 different suites in version 1.2, some of which are unsafe, there are currently only 5 approved suites in version 1.3, all of which are currently considered safe. This greatly simplifies the selection of the suites used or accepted.
Example Cipher Suite: TLS 1.3:
TLS_ AES_256_GCM _ SHA384
- Encryption of communication
- Hash method for checking the integrity
Applications of TLS
TLS is used for encrypted transmission of various protocols. The best-known example is HTTPS, the encrypted variant of the Hyper Text Transfer Protocol (HTTP). This is used, for example, for encrypted access to websites. When transmitting sensitive data, such as log-in forms, the use of TLS encryption is often mandatory. Modern browsers also warn against such data from forms being transmitted without encryption.
Other fields of application are the POP3S, SMTPS or IMAPS protocols for the transmission of e-mails or SIPS for the encrypted transmission of VOIP communication. There are many other uses for TLS.
In the last ten years the use of TLS and SSL has increased significantly. In the meantime, a large number of websites on the World Wide Web are secured using TLS / HTTPS. This has a positive effect on data protection and IT security for Internet users.
VoIP & video telephony encryption
TLS is also used for encryption in today’s increasingly widespread services for Internet-based telephony and video telephony (e.g., so-called web conferences). However, this use differs from the application of the protocol as described earlier. Because the transmission of audio and video signals in real-time, which is necessary for VoIP and other services, is carried out by the protocol RTP (Real-Time Transport Protocol), which is based on UDP (User Datagram Protocol), “direct” encryption of this protocol by TLS is not possible, because TLS is only possible with TCP. TLS is used here to encrypt the communication content via a “detour”, so to speak.
The SIP (Session Initiation Protocol) protocol is used to establish a connection for RTP traffic.
This regulates the establishment, operation and termination of the connection. Unlike RTP, SIP can be encrypted with TLS, which is then referred to as SIPS. By using SIPS it is possible to agree on a common, secret key which can then be used for the symmetrical encryption of the RTP traffic. In this case, SRTP (Secure Real-Time Transport Protocol) is used. The transmission of the communication content is then encrypted.
In most cases no end-to-end encryption
It should be noted, however, that in most cases there is no end-to-end encryption, because SRTP can only guarantee an encrypted connection from an end device to the service provider (e.g. the telephone provider). The user has no influence on whether the provider also subsequently encrypts the data transmission to the recipient. At least the provider decrypts the data. The possibility of decrypting data and thus viewing and evaluating it is often desired.
In Germany, for example, the TKG (Telecommunications Act) provides for the possibility of law enforcement authorities requesting and viewing unencrypted communication data. Telecommunication service providers are legally obliged to enable this possibility of viewing communication.