TLS – Transport Layer Security is a protocol used to authenticate and encrypt internet connections. TLS is a separate layer between TCP and the protocols of the application and presentation layer. As a rule, the aim is to guarantee the authenticity of the server contacted by means of a certificate and to encrypt the connection between client and server.
Although TLS is commonly used, the term SSL is still common. Often both terms are used synonymously.
TLS (version 1.0) has its origins in SSL, which was developed by Netscape in the 1990s for the “Netscape Navigator” browser. The further development of SSL was ended with version 3. Then the IETF (Internet Engineering Task Force) took over the further development and standardization. This resulted in the TLS (Transport Layer Security) standard in 1999.
TLS is identical to SSL except for a few details. The differences between TLS version 1 and SSL version 3 are sufficient, however, that both are incompatible with each other. TLS uses HMAC to authenticate the data and generates the keys with the PRF function.
As a minimum standard, the BSI, as the authority responsible for the security of the federal IT systems, prescribes TLS 1.3 or TLS 1.2 with Diffie-Hellman key exchange.
TLS in the OSI layer model
In the OSI layer model, TLS is arranged on layer 5, the session layer. In the DoD layer model, which is used for TCP / IP, TLS is assigned on the transport layer as transport encryption over TCP and below the application protocols. TLS works completely transparently. In theory, all conceivable application protocols can use TLS for encryption. However, each application protocol must explicitly master TLS.
For example, the unencrypted HTTP (Hypertext Transfer Protocol) becomes the encrypted HTTPS (Hypertext Transfer Protocol Secure). It is also possible to retrieve encrypted emails from the POP server via TLS or to send them encrypted to the SMTP server. Here, too, the protocols have a “Secure” addition (SMTPS, POPS, IMAPS).
TLS is not limited to HTTPS or other communication protocols. Processes such as EAP-TLS, EAP-TTL, PEAP and also the LDAP protocol use TLS.
Application example: HTTPS
TLS is an optionally activatable security component for HTTP and is therefore intended for websites that process confidential data. For example with online banking or online shopping. These websites usually automatically establish an encrypted connection between the browser and the web server. The user only notices this when a lock or key symbol is displayed in the status bar or the address line changes color.
How TLS works
Part of TLS is the certification (1.) of the public key, the authentication of the server (2.), the validation of the transmitted certificate (3.) and the subsequent encrypted transmission of data between sender and recipient.
Certificates are used for authentication. Among other things, to solve the problem of distributing authentication information and to authenticate identities. The aim here is to be able to determine the authenticity of the remote station beyond any doubt so as not to establish a connection with a wrong remote station.
An encryption consists of the encryption of the data at the sender and the decryption of the data at the recipient. With TLS you work with two different keys for encryption and decryption. The so-called key pair consists of a private key and a public key. The public key of the recipient is known to the sender. He uses it to encrypt the data. However, the encrypted data can then no longer be decrypted with the public key.
This requires the private key, which can only be known to the recipient and must therefore be kept secret. Only the server with the appropriate private key is able to decrypt the encrypted data (asymmetrical encryption method or
Before the sender is allowed to encrypt data, however, he has to determine beyond any doubt whether the public key that he receives from the recipient actually belongs to the recipient to whom he wants to send the encrypted data. A connection encrypted using TLS does not offer any protection if it is not ensured that the public key comes from the server to which an encrypted connection is to be established.
This is where the certificate comes into play, with which a server and its public key are authenticated. In order to underline the validity of the public key, the server operator and domain owner can issue a certificate that includes, among other things, the domain name, the public key, an expiration date and which authority has confirmed the trustworthiness.
The recipient uses the certificate to authenticate himself to the sender or the server to the client. At the same time, the client can check the certificate (validation) and thus determine its trustworthiness (authenticity).
Certificate in the browser view
TLS works with PKIX certificates or with a public key infrastructure according to X.509v3. The certificates link an identity to a public key that is used for authentication and encryption.
There are a total of three types of certificates, which differ in the amount of testing required for certification and thus guarantee a correspondingly different level of authenticity.
- Domain Validated Certificate (DV)
- Organization Validation Certificate (OV)
- Extended Validation Certificate (EV)
The most common certificates are DV and EV certificates. While DV certificates can be obtained for a few euros or even free of charge, the considerable amount of testing required for EV certificates adds up to several hundred or even thousands of euros. However, one can assume a higher level of trustworthiness with EV certificates.
It is not so easy for the user to recognize which certificate is used for an encrypted connection. In most cases, an encrypted connection in a client can only be recognized by a lock symbol. But not what kind of certificate it is.
Certificates are issued and notarized by a certification authority (CA).
Certificate Authority (CA)
There are well over 700 certification bodies worldwide. Also called Certificate Authority or Certification Authority in English. Mostly abbreviated as CA.
The Certificate Authorities (CA) are an important pillar for security on the Internet. Anyone who offers secure services on the Internet has the authenticity of digital keys and signatures confirmed by a Certificate Authority.
For this purpose, a company or an organization can have a certificate authority issue a digital certificate after a check. This can then be stored on a web server, for example. With this certificate, the website identifies itself to the accessing browser as the owner. The visitor’s browser checks the information in the certificate and, if necessary, asks the issuing certification authority whether the certificate is valid.
In this way, for example, the customers of a bank can assume that they are actually connected to the bank’s server and that the data exchange is encrypted when they do online banking.
The certification authority also has a certificate in which its public key is located. This is a root or root certificate that is stored in browsers and operating systems. These root certificates are usually trusted unconditionally. Using the signature of the certification authority and the root certificate, a browser can determine whether the certificate of a domain was really issued by the specified certification authority.
The business relationship between the certification authority and the company, but also with the Internet users, is based on trust. A CA must therefore do everything possible to ensure that the test processes function properly and are safe from manipulation.
Unfortunately, it has already happened that intruders have accessed the internal servers of certification authorities and generated certificates there. If such a certificate is used, an Internet user cannot verify fraud. And a company that offers services on the Internet cannot determine whether a certification authority has issued unauthorized certificates. At most, the CA can detect fraudulent certificates.
CAs are therefore trustees who only live from their good reputation. As soon as it becomes known that a CA is hacking or being hacked, it can close the shop.
The certificate is issued by a certification authority, also known as a Certificate Authority (CA). The certification authority signs the certificate with its own private key, which confirms the authenticity of the data. In advance, the certification authority checks the information in the certificate and the identity of the applicant. There are different procedures for doing this. For example the Certificate Signing Request (CSR).
CSR – Certificate Signing Request / application for certification
The ssl Certificate Signing Request (CSR) is a common procedure for having your public key signed by a certification authority. Before doing this, the server operator generates a key pair on its own server. For example with OpenSSL. Some certification bodies are also able to remotely initiate key generation on the customer’s computer. The browsers have the necessary cryptography procedures for this.
The CSR or the request for the certificate then takes place, for example, using a web form. You have to provide information that is checked by the certification body and entered in the certificate. After the certificate has been issued, the customer can store the certificate and the private key on the respective server.
- The server operator generates a key pair consisting of a public and private key. The private key remains on the server and is kept secret.
- The server operator provides a CSR for the public key to a CA.
- The CA checks the information in the CSR and the public key.
- If everything is correct, the CA creates a certificate and sends it back to the server operator.
Validation of a certificate
If a client or server receives a certificate from another server, it must convince itself of its authenticity. So whether the certificate really comes from the server that was contacted.
With the validation of a certificate, the identity is confirmed without the communication partners involved having to exchange authentication information, such as keys, in advance.
The following example describes the validation for an encrypted HTTPS connection. In principle, the validation works in the same way for other protocols.
After the browser has received a certificate from the web server, it begins with the validation. The browser first checks whether it trusts the issuer of the certificate, the certification authority or Certificate Authority (CA). To do this, the relevant root certificate of the certification authority must be stored in the browser (1st and 2nd). The browser has a list of certification authorities that it trusts by default.
In the second step, the browser contacts the specified validation body or certification body (3rd and 4th). This checks whether the certificate is valid and reports the result back to the browser.
If the certificate is already known, validation by the certification authority is no longer mandatory.
With the first HTTPS request by the browser (client), TLS uses asymmetric encryption. As the first response, the server sends its public key and a certificate. In this way the web server authenticates itself to the client. The client checks the key and certificate for credibility. Depending on the setting of the client, the user must first confirm the credibility.
After successful authentication of the server, the browser generates a symmetric key, which it encrypts with the public key of the server. The browser then sends the symmetric key to the server. The server can open the encrypted packet with its private key. The browser key contained therein is used by the server for symmetrical encryption of the subsequent connection. Secure transmission is guaranteed. The contents of the HTTPS packets are protected against eavesdropping and modification.
During the data transfer between client and server, a new key is negotiated again and again, so that a possible attacker can only disrupt the connection for a short time.
Usually the client does not authenticate. The possibility of mutual authentication by signature is included as an option in the TLS specification. As a rule, only with an SSL VPN does the client also have to prove its identity with a certificate.
User authentication, if required, usually takes place at the application level. Specifically, this means that the customer would register and log in to an online shop or identify himself in online banking with a PIN, password and TAN.
eTLS – Enterprise TLS
The European Telecommunications Institute, ETSI for short, has standardized a variant of TLS 1.3. Enterprise TLS, eTLS for short, contains an intentional weakening of the Transport Layer Security (TLS) encryption standard. eTLS includes the ability to hold duplicate keys that enable companies or law enforcement officers to break encrypted data traffic. This enables companies, service providers and network operators to meet their statutory obligations to secure and monitor their networks.
With eTLS servers work with static Diffie-Hellman keys, which they use over a longer period of time and transmit them to middle boxes at regular intervals so that they can read the data traffic. The client does not have to participate. He only has to be able to use TLS 1.3.
eTLS should only be used within company networks.
When using implementations for TLS, one should rely on proven solutions. The trustworthiness of the implementations is expressed by the fact that the source code is public. That you basically have the possibility to check the source code for errors and backdoors. It cannot be ruled out that well-known and popular libraries may still contain errors and gaps. Nevertheless, the probability is higher that someone will look at the source code. How actively software or a product is maintained also plays a role.
How secure is SSL or TLS?
Since the revelations as part of the NSA scandal in the summer of 2013, it has been known that TLS is definitely insecure and contains an insecure authentication, which leads to encryption that is only partially effective. The problem here is not the encryption itself, but the trust concept, which is hierarchically arranged.
A secret service like the NSA, which can force Google, Microsoft, Yahoo and Apple to work together, can do the same with a certification authority like the central authority for the certification and validation of identities at TLS. And that’s why certification bodies that you have to trust unconditionally are considered compromised.
So TLS is not really safe! Nevertheless, TLS can be considered safe. But that doesn’t mean it is safe enough for all uses and in the future. This means that despite authentication and encryption, users have to live with a certain degree of uncertainty.
TLS are sufficiently secure for most requirements. It is true that there have always been security problems that are only partially eliminated. Most of them can only be exploited through targeted attacks, which is also associated with a great deal of effort.
Most attacks on TLS are unsuitable for mass surveillance and involve a certain risk of detection. Only attacks based on the slipping of false certificates that every browser accepts as valid are really successful. It has been known for a long time that the CA model for authentication is broken and we have lived with it for many years. There are solutions to this problem. But they are only gaining ground very slowly.
Make TLS more secure
Note: With the current trust model (Certificate Authority), it is impossible to make authentication and encryption secure for all applications. The only possibility is to build workarounds, i.e. to solve partial problems of TLS and its broken trust model, in order to keep the security of the system running reasonably credibly.
Because the authentication is fundamentally defective, one tries at least to get the encryption so far that the communication cannot retrospectively be decrypted. These measures are necessary because we know that secret services (e.g. the NSA) record encrypted data traffic. Subsequently, secret services attempt to demand the surrender of the keys by means of official orders or to obtain access to the keys in some other way.
With the use of Perfect Forward Secrecy in combination with Diffie Hellman, the communication cannot be decrypted retrospectively. This is why we recommend using TLS Perfect Forward Secrecy and Diffie-Hellman for the encrypted transmission of personal or other sensitive data.