Transport Layer Security

Table of Contents

The encryption protocol

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 introduction

The protocol was originally called the 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 interchangeably in practice. However, protocol versions SSL 1.0-3.0 and TLS 1.0 and 1.1 are outdated and insecure and should no longer be used. The current version of the protocol is TLS 1.3.

TLS connects asymmetric and symmetric encryption methods (hybrid encryption protocol) to enable two parties to communicate encrypted over a network. If content is not encrypted during transfer, there is a possibility that other participants (e.g. network operators or other parties with access to the data traffic) may read or change this content.

Encryption in two steps

TLS handshake

In order for 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 purpose. These confirm the identity and properties of a public key of the certificate holder, provided the certificate is issued and certified by a trustworthy certification authority. In most cases, the crypto system is used for this step RSA employed.

After authentication has taken place by checking the certificate, an asymmetric cryptographic process is used again, through which the partners agree on a shared, secret key, which can then be used to further encrypt the data traffic. This is usually what happens here Diffie-Hellman protocol for use. The Diffie-Hellman key exchange allows 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 exchanging keys. This private information will not be transmitted and must remain strictly confidential. A potential attacker cannot use the public information used to agree on the secret shared key to calculate or guess the shared secret key in a realistic time.

The Diffie-Hellman protocol is particularly useful when used to encrypt content on the Internet using the Https standard, because the usual communication partners in this context, a web server and a client (or its Internet browser), generally do not have any information about each other and therefore cannot have a common key in advance with which they could encrypt content symmetrically.

Exemplary representation of the Diffie-Hellman protocol
Exemplary representation of the Diffie-Hellman protocol
Secure data exchange in your company!
IT security from ProSec!
Go to page

Once a shared secret key has been agreed upon, it 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 these methods, content is both encrypted and decrypted with one key, the encryption is therefore reversible and therefore symmetrical. The currently most popular symmetric cryptosystem is the Advanced Encryption Standard (AES) with this information can be encrypted with keys with a length of 128 bits (AES-128), 192 bits (AES-192) and 256 bits (AES-256). The longer the key used, the more secure the encryption is. This algorithm is also often used with TLS, but other encryption methods can also be used.

Message Authentication

In addition to encryption, Message Authentication Codes (MACs) are also used. These serve to ensure the integrity and authenticity of the information, as 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 upon during the TLS handshake. Since only the two communication partners have both information (algorithm and secret key), only these two parties can generate corresponding HMACs from their data to be transmitted. If the received code differs from the self-calculated and expected code, this indicates an unwanted change in communication due to manipulation or errors.

Cipher Suites

For TLS, there are various so-called cipher suites that standardize the use of certain encryption and authentication procedures. These suites specify which procedures are used for the following steps of the protocol:

  1. Key exchange (e.g. Elliptic Curve Diffie-Hellman Ephemeral)
  2. Authentication (e.g. RSA)
  3. Encryption (e.g. AES)
  4. Hash and message authentication code (e.g. SHA384)

 

Example Cipher Suite:
ECDHE–RSA–AES256-GCM–SHA384

  • Key Exchange (Elliptic Curve Diffie-Hellmann Ephemeral)
  • Authentication (certificate check by RSA)
  • Encryption of communication
  • Hash process to check integrity

As part of the TLS handshake, the communication partners agree on a chiper suite, which is then used subsequently.

TLS 1.3

With the current standard of the TLS 1.3 protocol, part of the protocol has been firmly defined. This is necessary for key exchange Elliptic Curve Diffie-Hellmann Ephemeralprocedures can be used. This has the advantage that so-called “forward secrecy” is provided because the generated key is only valid for one session at a time. If a single key becomes 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. By specifying the key exchange procedure, the TLS handshake can run faster.

Transport Layer Security

Another change with version 1.3 is a significant reduction in the number of permitted cipher suites. While there were 1.2 different suites in version 293, some of which are unsafe, in version 1.3 there are currently only 5 approved suites, 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 process to check integrity

Applications of TLS

TLS is used for encrypted transmission of various protocols. The best-known example is HTTPS, the encrypted version 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 transferring such data from forms without encryption.

Further fields of application include the protocols POP3S, SMTPS or IMAPS for the transmission of emails or SIPS for encrypted transmission of VOIP communication. There are numerous other applications for TLS.

Over the last ten years, the use of TLS and SSL has increased significantly. A large proportion of websites on the World Wide Web are now secured via 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 deployment is different from the application of the protocol as previously described. Because the transmission of audio and video signals in real time, which is necessary for VoIP and other services, is carried out using the RTP (Real-Time Transport Protocol), which is based on UDP (User Datagram Protocol), this is “direct” encryption Protocol is not possible through TLS because TLS is only possible with TCP. TLS is used here to encrypt the communication content in a “detour”, so to speak.

The connection establishment of RTP traffic

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 symmetrical encryption of RTP traffic. In this case we speak of SRTP (Secure Real-Time Transport Protocol). The transmission of the communication content is subsequently encrypted.

In most cases, no end-to-end encryption

However, it should be noted 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 subsequently encrypts the data transmission to the recipient. At least the provider decrypts the data. The ability to decrypt data and therefore view and evaluate it is often desired.

In Germany, for example, the TKG (Telecommunications Act) provides for the possibility for law enforcement authorities to request and view unencrypted communication data. Telecommunications service providers are legally obliged to provide this opportunity to view communications.

Newsletter Form

Become a Cyber ​​Security Insider

Get early access and exclusive content!


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!
OTHER CONTRIBUTIONS

Table of Contents

PSN_KU_Cover
NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!