HTTPS - Why TLS 1.3 provides better performance and security?

TLS v1.2 was released in August 2008. Ten years later, TLS v1.3 was released in August 2018, which made great changes in performance optimization and security. At the same time, in order to avoid upgrade conflicts caused by the new protocol, TLS v1.3 also made compatibility processing by adding extended protocols to support older versions of clients and servers.

Security

TLS v1.2 supports many encryption suites and is very compatible with older versions. Some of the algorithms with weak encryption strength and security vulnerabilities are likely to be exploited by attackers, bringing potential security risks to the business. TLS v1.3 removes these insecure encryption algorithms, simplifies the encryption suites, and reduces some options for the server handshake process.

• Removed support for MD5 and SHA1 password hash functions, and recommended using SHA2 (ie, SHA-256).
• Remove RSA and all static keys (key agreement is not forward secure).
• Overflow RC4 stream cipher, DES symmetric encryption algorithm.
• Added support for the elliptic curve algorithm https://www.wanweibaike.net/wiki-X25519 during key negotiation.
• Supports ChaCha20 stream encryption algorithm with Poly1305 message authentication code. Stream encryption is also a symmetric encryption algorithm.
• The CBC grouping mode has been removed. TLS v1.3 symmetric encryption only supports three modes: AES GCM, AES CCM, and ChaCha20**-**Poly1305.
• All messages after "Server Hello" on the server side will be transmitted encrypted, so regular packet capture analysis will raise questions about why the certificate information cannot be seen.

Performance Optimization

A significant change in performance optimization is the simplification of the TLS handshake phase, which is shortened from 2-RTT in TLS v1.2 to 1-RTT. At the same time, TLS v1.3 also introduces the 0-RTT concept after the first link is established.

Source https://www.a10networks.com/wp-content/uploads/differences-between-tls-1.2-and-tls-1.3-full-handshake.png

In TLS v1.2, key negotiation requires the client/server to exchange random numbers and the server to send a certificate, and then both parties send a "Clent/Server Key Exchange" message to exchange the parameter information required for key negotiation. In terms of security, TLS v1.3 has removed many insecure algorithms and simplified the cipher suite. The "Clent/Server Key Exchange" message has now been removed. When the client sends a "Client Hello" message, the extended protocol carries the supported elliptic curve name, temporary public key, and signature information. After receiving the message, the server tells the client the selected key negotiation parameters in the "Server Hello" message, thereby reducing one message round trip (1-RTT).

   Client Server 
 
 Key ^ ClientHello
 Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key* -------- >  
                                                  ServerHello^Key
                                                 + key_share* | Exch
                                            + pre_shared_key* v
                                        {EncryptedExtensions}^Server
                                        {CertificateRequest*} v Params
                                               {Certificate*} ^
                                         {CertificateVerify*} | Auth
                                                   {Finished} v
 < -------- [Application Data*]
 ^ {Certificate*}
 Auth | {CertificateVerify*}
     v {Finished} -------- >  
       [Application Data] < ------- > [Application Data] 
                                                 
                       The basic full TLS handshake

When accessing a previously visited site, the client can achieve "zero round trip time (0-RTT)" by sending data on the first message to the server using a pre-shared key (PSK) from a previous session.

 Client Server 
 
 ClientHello
 + early_data
 + key_share*
 + psk_key_exchange_modes
 + pre_shared_key
 (Application Data*) -------- >  
                                                ServerHello
                                           + pre_shared_key
                                               +key_share*
                                      {EncryptedExtensions}
                                              + early_data*
                                                 {Finished}
 < -------- [Application Data*]
 (EndOfEarlyData)
 {Finished}-------- >  
 [Application Data] < ------- > [Application Data] 
 
              Message Flow for a 0-RTT Handshake

TLS v1.3 packet capture analysis

Take a complete TLS handshake between client and server as an example, and analyze the handshake process of TLS v1.3 by capturing packets. The following figure shows the captured data message of www.zhihu.com website, and the message has been decrypted, otherwise the data after the "Change Cipher Spec" message has been encrypted and cannot be analyzed. For packet capture, please refer to "Things about Network Protocols - How to capture packets and crack HTTPS encrypted data?".

image.png

The TLS v1.3 handshake process is shown in the following figure:

tls-1-3-full-handshake.jpg

Client Hello

At the beginning of the handshake, the client tells the server its own Random, Session ID, encryption suite, etc.

In addition, TLS v1.3 needs to pay attention to the "extended protocol". TLS v1.3 achieves "forward compatibility" through the extended protocol. When the client requests, it tells the server the protocols it supports and some other extended protocol parameters. If the old version does not recognize it, it will be ignored.

Let's look at several major extension protocols:

• supported_versions: TLS versions supported by the client, for the server to choose after receiving.
• supported_groups: supported elliptic curve names
• key_share: elliptic curve name and corresponding temporary public key information.
• signature_algorithms: signature

 Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Version: TLS 1.2 (0x0303)
            Random: 77f485a55b836cbaf4328ea270082cdf35fd8132aa7487eae19997c8939a292a
            Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
            Cipher Suites (16 suites)
                Cipher Suite: Reserved (GREASE) (0x1a1a)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
            Extension: signature_algorithms ( len = 18 )
            Extension: supported_groups ( len = 10 )
                Supported Groups (4 groups)
                    Supported Group: Reserved (GREASE) (0xcaca)
                    Supported Group: x25519 (0x001d)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: secp384r1 (0x0018)
            Extension: key_share ( len = 43 )
                Type: key_share (51)
                Key Share extension
                    Client Key Share Length: 41
                    Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1
                    Key Share Entry: Group: x25519, Key Exchange length: 32
                      Group: x25519 (29)
                      Key Exchange Length: 32
                      Key Exchange: 51afc57ca38df354f6d4389629e222ca2654d88f2800cc84f8cb74eefd473f4b
            Extension: supported_versions ( len = 11 )
                Type: supported_versions (43)
                Supported Versions length: 10
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)

Server Hello

After receiving the client request, the server returns the selected cipher suite, Server Random, the selected elliptic curve name and the corresponding public key (Server Params), and the supported TLS version.

This cipher suite looks much shorter: TLS_AES_256_GCM_SHA384. The parameters for negotiating the key are placed in the key_share extension protocol.

 TLSv1.3 Record Layer: Handshake Protocol: Server Hello
    Content Type: Handshake (22)
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Version: TLS 1.2 (0x0303)
        Random: 1f354a11aea2109ba22e26d663a70bddd78a87a79fed85be2d03d5fc9deb59a5
        Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
        Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
        Compression Method: null (0)
 Extensions Length: 46
        Extension: supported_versions ( len = 2 )
            Supported Version: TLS 1.3 (0x0304)
        Extension: key_share ( len = 36 )
            Type: key_share (51)
            Key Share extension
                Key Share Entry: Group: x25519, Key Exchange length: 32
                    Group: x25519 (29)
                    Key Exchange: ac1e7f0dd5a4ee40fd088a8c00113178bafb2df59e0d6fc74ce77452732bc44d

The server now has the four parameters Client Random, Client Params, Server Random, and Server Params, and can prioritize calculating the pre-master key. In TLS v1.2, after the first round-trip message, the client initiates the request first.

After calculating the session key for symmetric encryption, the server sends a Change Cipher Spec message and switches to encryption mode. All subsequent message (certificate, certificate verification) transmissions will be encrypted, which also reduces the plaintext transmission during the handshake.

Certificate、Certificate Verify、Finished

In addition to Certificate, TLS v1.3 also has a "Certificate Verify" message, which uses the server's private key to sign the handshake information, strengthening security measures.

 Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Certificate
    TLSv1.3 Record Layer: Handshake Protocol: Certificate Verify
        Handshake Protocol: Certificate Verify
            Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                Signature Hash Algorithm Hash: Unknown (8)
                Signature Hash Algorithm Signature: Unknown (4)
            Signature length: 256
            Signature: 03208990ec0d4bde4af8e2356ae7e86a045137afa5262ec7c82d55e95ba23b6eb5876ebb…
    TLSv1.3 Record Layer: Handshake Protocol: Finished
        Handshake Protocol: Finished
 Verify Data

The client switches to encryption mode

After the client obtains the four parameters of Client Random, Client Params, Server Random, and Server Params to calculate the final session key, it will also initiate "Certificate Verify" and "Finished" messages. When both the client and the server have sent the "Finished" message, the handshake is completed, and data can then be transmitted securely.

image.png