This article was originally published on the Red Hat Customer Portal. The information may no longer be current.
Transport layer Security version 1.3 (TLS 1.3) is the latest version of the SSL/TLS protocol which is currently under development by the IETF. It offers several security and performance improvements as compared to the previous versions. While there are several technical resouces which discuss the finer aspects of this new protocol, this two-part article is a quick reference to new features and major changes in the TLS protocol.
Faster Handshakes
In TLS, before data can be encrypted, a secure channel needs to created. This is achieved via the handshake protocol in which a cipher suite is negotiated between the client and the server and key share materials are exchanged.
The handshake is initiated by the TLS client utilizing a ClientHello message sent to the server. This message contains, among other things, a list of cipher suites which the client is capable of supporting. The server replies to this message in its ServerHello message by picking one of the cipher suites from the client list and, along with it, the server also sends its key share and the site's certificate to the client.
The client receives all of the above, generates its own key share, combines it with the server key share and generates bulk encryption keys for the session. The client then sends the server its key share and sends a FINISHED message which contains a signed hash of all the data which was previously exchanged. The server does the same thing by sending its own FINISHED message.
This ends the handshake and results in a cipher suite and a bulk encryption key being negotiated between the client and the server and takes two full rounds of data exchange.1
TLS 1.3 aims to make this faster by reducing the handshake to just one round trip (1-RTT). In TLS 1.3 the ClientHello not only contains a list of supported ciphers, but also it makes a guess as to what key agreement protocol the server is likely to chose and sends a key share for that particular protocol.
As soon as the server selects the key agreement protocol it sends its own key share and, at the same time, generates the bulk encryption key (since it already has the client key share). In doing so, the computers can switch to encrypted messages one whole round trip in advance. The ServerHello also contains the FINISHED message. The client receives the server key share, generates bulk encryption keys, sends the FINISHED message and is immediately ready to send encrypted data. This results in faster handshakes and better performance.2
Faster Session Resumptions
The TLS protocol has a provision for session resumption. The general idea is to avoid a full handshake by storing the secret information of previous sessions and reusing those when connecting to a host the next time. This drastically reduces latency and CPU usage. However in modern times the session resumption is usually frowned upon because it can easily compromise Perfect Forward Secrecy (PFS).
Session resumption can be achieved in one of the two following ways:
-
Session ID:
In a full handshake the server sends a Session ID as part of the ServerHello message. On a subsequent connection the client can use this session ID and pass it to the server when connecting. Because both server and client have saved the last session’s “secret state” under the session ID they can simply resume the TLS session where they left off. -
Session Tickets:
The second mechanism to resume a TLS session are Session Tickets. This extension transmits the server’s secret state to the client, encrypted with a key only known to the server. That ticket key is protecting the TLS connection now and in the future and is the weak spot an attacker will target. The client will store its secret information for a TLS session along with the ticket received from the server. By transmitting that ticket back to the server at the beginning of the next TLS connection both parties can resume their previous session, given that the server can still access the secret key that was used to encrypt it.
In both of the above methods session resumption is done by using 1-RTT (one round trip). However TLS 1.3 achieves this by using 0-RTT. When a TLS 1.3 client connects to a server, they agree on a session resumption key. If pre-shared keys (PSK) are used the server provides a Session Ticket which can be encrypted using the PSK if required.
During Session resumption, the client sends the Session Ticket in the ClientHello and then immediately, without waiting for the RTT to complete, sends the encrypted data. The server figures out the PSK from the session ticket and uses it to decrypt the data and resume the connection. The client may also send a key share, so that the server and the client can switch to a fresh bulk encryption key for the rest of the session.
There are two possible problems with the above implementation though:
-
No PFS when using Session Resumption:
Since the PSK is not agreed upon using fresh Diffie Hellman, it does not provide Forward Secrecy against a compromise of the session key. This problem can be solved by rotating the session keys regularly. -
This can easily lead to replay attacks:
Since the 0-RTT data does not have any state information associated with it, an attacker could easily resend the 0-RTT message, and the server will decrypt the associated data and act on the data it received. One way to avoid this is to make sure that the server does not perform any "important action" (like transferring secret information or making a financial transaction) based on the 0-RTT data alone. For such operations servers can impose 1-RTT session resumptions.
DTLS has an additional concern: during re-handshake it is not known whether the peer is alive at all. Data sent along with the handshake message may have ended up in a black hole, going no where.
Part 2 of the blog discusses the various cryptographic changes found in TLS 1.3 and their implications.
-
TLS 1.2 has an extension called "false start", which can reduce the initial handshake to 1-RTT, it bundles the client application data with its FINISHED message. ↩
-
The roundtrips mentioned are TLS protocol roundtrips, not actual network roundtrips. In reality you have additional roundtrips due to TCP establishment. Most implementations today provide a way to use TCP fast open to reduce that additional round-trip. ↩
Sull'autore
Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit