Overview of TLS (Transport Layer Security) 1.3 standard
Explore the TLS 1.3 standard and the algorithms behind it.
Intro
In 2018 a new version of TLS, TLS 1.3 was released. The standard is described extensively in RFC 8446 and as usual, contains several improvements to it’s predecessor TLS 1.2. The beginning of this RFC entry contains the purpose of the algorithm it should provide authentication, confidentiality and integrity. To achieve this goal TLS 1.3 contains several complex cryptographic algorithms.
TLS is divided into two main parts, the first part is the handshake protocol and the second one is the record protocol. The first of those two is used to establish a secure connection over the insecure network. The second protocol is used for continuous communication between the two parties.
Handshake Protocol
The handshake starts with the computation of the client to generate key. In comparison to TLS 1.2 handshake, only 3 steps are used for the key exchange which is a drastic improvement in round-trips. To exchange a shared secret TLS 1.3 uses asymmetric encryption. It is
The process of a TLS handshake is started by a client hello, this contains the basic information to the server to establish a connection. The server checks if it can meet the requirements and responds successfully if that works. In the next step the connection is encrypted, the server sends the certificate and if all is finished without an issue the application data exchange will start.
An interesting phenomena of TLS and the corresponding implementations in the different frameworks is that each TLS request is unique and can contain data for multiple versions of the TLS protocol. The standards for TLS including RFC 8446 represent only the desired state of the implementation of TLS and how it should work. Even in the RFC are some not fully clear sections and recommendations usually marked by the key words described in RFC 2119. The standard has to be flexible in many situations, e.g. for IOT devices. This requirement makes it harder to define only one simple protocol or one way of key exchange.
A full handshake contains 3 round-trips, all messages after the ServerHello are encrypted.
Note: The images provided in the following paragraphs containing the TLS handshake were made using Firefox 128.10 and the server requested is
tryhackme.com.
Client Hello
The client hello is the first TLS packet send to establish a connection to a server. In this package the client provides the server with the cipher suites it supports. In addition to that the client guesses which public key exchange the server might support, for that guessed algorithm the client sends his public key. This algorithm guessing makes the TLS key exchange efficient cause it saves additional round-trips. If the server accepts the public key exchange method the server only needs to send his public key to the client to establish a encrypted connection. Also the TLS 1.3 client hello somewhat looks similar to the TLS 1.2 client hello. This is the case because of the backwards compatibility feature o TLS, so if the server doesn’t understand TLS 1.3, the server can process the client hello despite that.
Moreover the client hello usually contains:
- a random which should be generated by a cryptographically secure PRNG (CPRNG)
- a session id, only there for legacy with TLS 1.3, it is ignored by the TLS .13 handshake
- a list of cipher suites the client supports
- a compression method, which is disabled by default (compressed TLS is vulnerable to attacks like CRIME)
- additional data using the
extensionsfields in TLS
An interesting observation can be made by inspecting the client hello packet. The version in the request is set to 1.0. The version used for TLS is no longer set in the version field, the version is discussed about the supported_versions field in the extensions.
Another interesting observation can be made, in TLS 1.3 only 5 cipher suites are available, which will be explained further below. The cipher suites in this client hello are more than 5, to be precise 17 cipher suites. The client also sends TLS 1.2 ciphers to the server so if the server only supports TLS 1.3 the packet wouldn’t be wasted.
This shows how redundant the web and in the current example TLS 1.3 are built, there is always a fallback version if the current method doesn’t work.
Extension field
The Extension fields of the client hello contain the actual TLS 1.3 magic. The most basic field in the extensions block is the Supported Versions field which contain the TLS versions the client understands.
The Supported Groups field contains the supported key exchange methods by the client, the client provides them to the server if the server doesn’t use the proposed key exchange by the key_share field.
The key_share extension is responsible for containing the public key of the client. This is the already computed public key for the algorithm the client “guessed” the server would use. As shown below the client doesn’t need to pick only one specific public key algorithm and can send multiple public keys in one message from which the server can pick. The versions picked below are the elliptic curve secp256r1 and the other elliptic curve X25519. This field shows that elliptic curves play a crucial role in modern cryptography providing good security but also fast calculations.
Lastly the signature hash algorithms field is used to provide the server with a list of algorithms the client supports for signature validation. These are the signature algorithms used for certificate validation.
Server Hello
The server hello tries to process the clients proposal and in the best case finish the unencrypted communication. In comparison to the client hello the server hello contains less information, because the server usually only choses the cipher to use.
In the response to the client hello the server provides his random, the session id and some extension fields.
If the server accepts the TLS version it will send the supported versions extension field back with the selected version. The actual version header in the TLS 1.3 handshake is set to TLS 1.2 for backward compatibility with proxies.
The server then selects the cipher suite from the client proposed ones. In the example handshake the server selected TLS_AES_128_GCM_SHA256.
Finally the server sends the client his key using the key_share field again, which contains the public key of the server. The servers public key should ideally be generated by the same algorithm the client used to generate its public key, if not a HelloRetryRequest is send.
After the server hello both parties have their private key exchanged and will compute their shared secret used for further communication.
In TLS 1.2 there is a Change Cipher Spec package send before the the connection is becoming encrypted. This is the same for TLS 1.3 although this isn’t really needed anymore, but it is still send to avoid any communication issues.
Encrypted extensions
After the encrypted connection is established by the server there is the possibility to exchange further extensions encrypted. The client doesn’t need to send his Change Cipher Spec package to switch to encryption, because it’s no longer required, so the encrypted extensions are send right after the Server Hello and the compatibility Change Cipher Spec TLS packet.
In the extensions the server name is empty. The type 65037 usually should be set by the client to protect the user, this will tell an intermediate attacker that the user is visiting a website provider like cloudflare and not the actual host name, but this is not the case in this example.
The application_layer_protocol_negotiation extension is used for selecting the protocol used over TLS. In this example the server tells the client that it uses HTTP2. In the client hello request there was also the extension application_layer_protocol_negotiation set, so the server knows that the client supports that.
The client sends all the protocols it supports.
Certificate
To conclude the final steps of the connection process between the client and the server the server sends the client the certificate of itself. The messages are encrypted in this step because the keys are established, specifically for this step the data is encrypted using the server handshake key. The certificate is send in the ASN.1 (Abstract Syntax Notation One) DER format.
The DER format is the serialized version of the ASN.1 certificate. The certificate is used by the client to validate if it is communicating with the legit server, which has the corresponding certificate signed by a certification authority. For validation the server sends the certificate, more about the format of the certificate can be found here.
In the Certificate step of the handshake there are three certificates included. The client receives the root certificate (GTS Root R4), the intermediate certificate (WE1) and the leaf certificate (end certificate) for tryhackme.com. Each of the certificates is issued by the certificate before, this is a certificate chain.
Certificate verify
The server hashes the full handshake until this point and signs it using the private key. The result is send to the client which will verify it using the public key. For this
Signature Methods
There are several algorithms for signature generation/verification is available in TLS 1.3. These signatures are used for the certificate verification, these signatures do not have to do anything with the signature methods of the messages.
The first category contains the ECDSA algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384 and ecdsa_secp521r1_sha512, these are elliptic curve DSA algorithms. These algorithms work similar to the basic DSA algorithms with the difference that they are using elliptic curves.
Secondly RSASSA-PSS algorithms are supported by TLS 1.3. These are the replacement for the RSASSA-PKCS1-v1_5 functions which are known for vulnerabilities.
More over there are also two EdDSA algorithms included in the standard ed25519 and ed448. They differ from the ECDSA algorithms in generation and use Twisted Edwards curves instead of basic Weierstrass curves.
Server/Client Finished
Both the server and the client send a hash of the handshake until their point to the client, this is used to mitigate any tampering attempts and to check if no packet was missed.
The client will also send a Change Cipher Spec again for legacy purposes.
Key Exchange
The Supported Groups field contains the possible groups used for public key exchange. All supported groups for the exchange for all versions of TLS can be found here. Most of the proposed methods contain elliptic curves (EC). TLS 1.3 itself only supports 10 different groups.
The first 5 groups are elliptic curve groups and the last 5 are finite field groups.
The curve Curve25519 with the function name x25519 is one of the most used functions in TLS 1.3, it was also used in the key exchange above. The curve offers 128 bits of security, because the key is 256 bit long. The key exchange is like a usual ECDHE, so both parties calculate their public key by multiplying a generator point with a private key number. In the next step the parties exchange their public keys and calculate their secret key by multiplying the public key of each other with the private key.
Another popular but less used curve is the Curve448, with the function name x448. This curve uses the same key exchange method but offers a larger key size (448 bit) and 224 bits of security.
In the elliptic curve section there are 3 more Weierstrass curves secp256r1, secp384r1 and secp521r1. The security of these curves is as follows: 128 bits for secp256r1, 192 bits for secp384r1, and 256 bits for secp521r1.
In comparison to the elliptic curves the finite field groups have much larger key sizes. The DHE (Diffie-Hellman key exchange) provides less security per bit. The supported finite fields are ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144 and ffdhe8192. The ffdhe2048 group only provides 112 bits of security even though the key is over 9 times bigger than the EC with the same security. It is now clear that the DHE using finite fields is much less efficient due to the key sizes needed for exchange, than the DHE using elliptic curves over finite fields.
Generally speaking the two rival challenges for the exchange methods are speed vs security. On the one hand the calculation of the public key/secrets should be as fast as possible, on the other hand speed often compromises security and the curves/fields should offer solid security.
In the RFC8446 there is the option also to use a PSK (pre-shared key), this means a key from a earlier established connection is used.
Calculation of the handshake keys
After the exchange of the public keys both parties (the client and the server) calculate the keys used for the session. This is done through a key derivation function (KDF). The function is specified in RFC5869. The key derivation function is named HKDF and based on HMAC. The hash function is specified using the cipher suite. So for the cipher suite TLS_AES_128_GCM_SHA256, SHA256 is used. The parties generate several new keys with the HKDF:
- handshake secret, using a pre-computed 0’s HKDF hash and a empty HKDF hash which are also HKDF hashed to derived secret
- server secret, generated using the handshake secret generated by the derived secret and the shared secret, the label is “s hs traffic”
- client secret, same as the server handshake traffic secret but the label is “c hs traffic”
- server handshake key, generated using the server secret and the label “key”
- server handshake IV, generated using the label “iv” from the server secret as the key
- client handshake key, same as the server handshake key only from the servers secret key
- client handshake IV, same as the server handshake iv, difference is the secret
The process aims to generate random secrets for the different purposes from a simple function. The keys will now be used for the communication. For further reference visit this page.
Calculation of the application keys
As the handshake keys, the new keys for the application exchange are calculated using the HKDF function and the hashing algorithm specified in the cipher suite name.
First the hash of the handshake is calculated. Then a derived secret is generated from a handshake secret and again an empty hash. A master key is generated from the empty hash and the derived key. Then the process repeats like in the handshake key generation, only this time the keys are different.
Special messages
HelloRetryRequest
This message is send from the server if the server doesn’t support the key exchange algorithm selected with the key_share by the client. The message has the same format as the ServerHello but contains additionally supported_versions field with the versions the server supports.
Alerts
If something unexpected happens an alert message is send to the other party and the handshake is aborted. Further reference.
Record Protocol
In TLS 1.3 there are only two encryption algorithms available. Both feature not only encryption, but also authentication, this provides a tampering protection which is vital in a insecure network environment.
The RFC standard provides three cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256. The only three algorithms for encryption are AES-GCM, AES-CCM and ChaCha20-Poly1305.
Symmetric encryption algorithms
AES-GCM is an extended AES mode which adds authentication to the AES block cipher. The mode is based on AES-CRT, so it is essentially a block cipher used as a stream cipher with authentication attached. This is probably the most used algorithm for TLS 1.3. It provides good security with AES and is fast computable. The good performance is especially due to hardware acceleration on modern CPUs.
The mode is initialized with a counter which is encrypted using the key. For each block the counter is increased by one. The encrypted counter is then XORed to the plaintext resulting in the ciphertext. The ciphertext is additionally used by the authentication part (marked blue and red). For the computation of the authentication tag a Galois field is used, hence the name is GCM (Galois/Counter Mode). For further mathematics refer to Wikipedia.
AES-CCM ciphers are included for low performance devices such as micro controllers. This suite also provides authentication and encryption. The name CCM is due the combination of the CRT mode with the CBC-MAC authentication. The ciphertext is generated using CRT, like in GCM but the authentication tag is generated by essentially using the AES CBC mode to generate a tag. The TLS_AES_128_CCM_8_SHA256 encryption method is exactly the same as for the TLS_AES_128_CCM_SHA256 encryption method, only the tag is shorter.
ChaCha20-Poly1305 is also an authenticated version of the ChaCha20 cipher. The ChaCha20 cipher is a relatively new cipher but provides relatively good security in the right implementation. The ChaCha20 cipher also provides redundancy for the possibility of a 0-day in AES, an alternative encryption method is available.
Different browsers and tools
Firefox which was used in the images above sends a x25519 public key and a secp256r1 public key. Also Firefox only sends only TLS 1.2 and TLS 1.3 as the supported TLS versions.
curl was tested also using tryhackme.com as the destination server and the results were different. curl only sends a x25519 public key, but more supported versions TLS 1.3-1.0.
In Chromium you will find the GREASE values in several attributes, this is for testing TLS. Additionally Chrome sends the key_share group 4588 to the server which is not part of the standard protocol, this is a post-quantum algorithm.
It can be seen that even when using the same server as the destination different TLS implementations request data differently. Although for example the group 4588 is not recognized in WireShark the server responds with its public key in that algorithm. This proves that TLS is highly flexible and can be used efficiently.
Finally it is astonishing how much cryptography and logic is behind one click onto a website.