Main section
What is TLS 1.3 - and what are the advantages over TLS 1.2?
The security protocol "Transport Layer Security" (TLS) for encrypting and authenticating communication with web servers has been revised repeatedly over the last thirty years. The current version is 1.3 - we explain why it is worth upgrading to this new standard.
As a system administrator and certificate manager, you regularly update your organisation's SSL/TLS certificates. You may also use automation options to do this, such as using the standardised ACME protocol or a REST-based Application Programming Interface (API) to obtain certificates. A clean certificate environment is essential to provide your customers and stakeholders with a seamless user experience.
It is also worth keeping the web server up to date with the latest versions of the Transport Layer Security (TLS) protocol. TLS is used to encrypt communication between the client, usually the browser, and the (web) server. Outdated versions of this encryption protocol pose a security risk. In addition, using the latest TLS version 1.3 offers further advantages, particularly in terms of latency when establishing a connection.
Summary
TLS (Transport Layer Security) is the modern standard protocol for secure communication on the web - and with version 1.3, there are clear advantages over the previous version TLS 1.2. The most important difference: TLS 1.3 is faster. Thanks to a simplified connection setup (only one round trip instead of two), latency is significantly reduced - this results in faster loading websites and a better user experience. In addition, TLS 1.3 is ready for the future: it supports Post Quantum Cryptography (PQC), which means encryption that can withstand future attacks by quantum computers. That is why it is also relevant for your compliance. Even though TLS 1.2 is still considered secure under certain conditions, SwissSign recommends supporting TLS 1.3 to ensure maximum security and performance.
Background: What is TLS and what are the current standards?
The origins of the TLS protocol go back to research in the 1980s and it was specified and used in the 1990s as Secure Socket Layer (SSL) for the web. Finally, SSL was further developed by the Internet Engineering Task Force (IETF) under the name Transport Layer Security (TLS) and officially standardised.
The TLS 1.2 version was published as a standard in 2008. This included various innovations regarding cryptographic algorithms that are still in use today.
The standard was again updated in 2018. In addition to the 1.2 version, TLS version 1.3 was also introduced.
TLS version 1.3 and its predecessor 1.2 are considered secure and (only) these versions should be offered as options for communication between the web server and the browser. However, version 1.2 should only be offered with the correct "ciphersuites," i.e. the correct combinations of the cryptographic algorithms used.
The predecessor versions SSL 1.0 - 3.0 as well as TLS 1.0 and TLS 1.1, on the other hand, are now outdated. They are considered insecure and are no longer supported in new browser versions.
TLS 1.2 can therefore still be operated securely if the requirements for cryptographic algorithms are observed.
Benefits of TLS 1.3
So the question arises: why should one support version 1.3 at all, when the previous version 1.2 also allows for a sufficiently secure communication? Due to its longer existence, this version is more widespread, so compatibility with older client software is also guaranteed. So why support the newer version?
With TLS 1.3, encryption runs faster
TLS 1.3 redefines the handshake.
In the previous approach in TLS 1.2, an initial "greeting" (called "ClientHello" and "ServerHello") was performed before the client and server exchanged the cryptographic parameters that set up the encryption. In total, four messages were exchanged in sequence, two client requests and two server responses. This is referred to as two "roundtrips".
The TLS 1.3 handshake has been streamlined, with the client sending the server the information it needs in one message and receiving only one message in return from the server. This means there is only one round trip, and the number of steps for TLS connection establishment has been halved. This simplification leads to a significant reduction in latency, or in other words, a performance improvement - the website loads much faster. The users benefit and also Google ranks websites better that load faster.
The above discussion deals with the initial TLS connection establishment of a client with a server. But what about resuming a TLS connection? TLS 1.3, together with the "Zero Round Trip Time" (0-RTT) feature that the protocol allows, can also reduce latency in this case. Although more than zero round trips are needed to resume a TLS connection, at least one round trip can be saved compared to the traditional method.
Modern, quantum-resistant encryption
With TLS 1.3, you also take a big step forward in terms of data security. The encryption methods used in TLS so far are secure according to today's technological standards. However, with the development of the so-called quantum computer, there is a risk that encrypted communication using today's public key cryptography could be decrypted by an attacker in the future ("store now, decrypt later"). A connection that is secure enough today may not be so tomorrow.
For this reason, a new public-key encryption method has been developed that cannot be cracked by quantum computers. Such algorithms and keys are referred to as quantum-resistant encryption or "Post Quantum Cryptography" (PQC). An extension of TLS 1.3 allows the use of both conventional public-key encryption and PQC encryption.
Note: in modern TLS protocols, the TLS certificate and the public key contained therein are only used for authentication and not for encryption. PQC encryption is therefore possible even when using certificates based on conventional public-key cryptography.
If you are reading this blog on the web server https://swisssign.com/ and using a modern browser, the connection is probably protected by PQC encryption. If you are using Google Chrome (desktop version), for example, you can check whether the connection is encrypted in a quantum-resistant way as follows: Press Ctrl+Shift+I. A sub-window will open on the right side of the browser, where you can select the "Privacy & Security" tab.
In addition to the information about the SwissSign-TLS certificate used, you will find information about the encryption of the connection. The indication of the public-key encryption "X25519MLKEM768" is not very easy to understand, but the "MLKEM" part means that your connection is protected by modern, quantum-resistant encryption and is unlikely to be readable by unauthorised parties in the future. The TLS version used for the connection is also displayed, and with this method you can also check whether the web servers you administer already support TLS 1.3.
Graph 2: Screenshot of a TLS connection with a "hybrid" handshake, including quantum-resistant ML-KEM.
TLS 1.3 and Compliance - a topic for auditors
The use of current encryption protocols such as TLS 1.3 is not just a purely technical recommendation, but also and in particular a topic for IT security audits and assessments. In many regulated industries - such as the financial and insurance sectors, government or healthcare - there are high requirements for the protection of data in transit.
Standards such as ISO/IEC 27001, the NIST Cybersecurity Framework or industry-specific requirements (e.g. FINMA circulars or the Data Protection Act DSG) require the use of "recognised strong encryption methods". The use of outdated protocols such as TLS 1.0 or 1.1 will be considered a security flaw and will lead to non-conformity.
Technical implementation: How to enable TLS 1.3 on your web server
Support for TLS 1.3 can be implemented on most modern web servers with a few adjustments - provided the software in use is up-to-date:
Apache: from version 2.4.38 on with OpenSSL 1.1.1
NGINX: from version 1.13.0 on with OpenSSL 1.1.1
Microsoft IIS / Windows Server: from on Windows Server 2022
To enable TLS 1.3, you need to set the supported protocols accordingly in the server configuration.
In Apache, this looks like this: apache > SSLProtocol TLSv1.2 TLSv1.3
With NGINX, the setting can be made like this: nginx > ssl_protocols TLSv1.2 TLSv1.3;
Make sure that the OpenSSL library you are using also supports TLS 1.3. After enabling, we recommend checking your configuration with tools such as Qualys SSL Labs or openssl s_client.
Note: Even if TLS 1.3 is enabled, the server still supports TLS 1.2 - this ensures compatibility with older clients. However, it is important to consistently disable outdated and insecure protocols such as TLS 1.0 and 1.1.
Conclusion: Upgrade to TLS 1.3
The use of the current version of the TLS protocol, version 1.3, is superior to the previous versions in terms of speed when establishing a connection. Even the most modern encryption algorithms - with "Post Quantum Cryptography (PQC)" - can be used if TLS 1.3 is supported by both the client and the server. Therefore, we recommend that your webservers support the latest version.
