chikaku

且听风吟

永远是深夜有多好｡
github
email
HomeArchives

TLS1.3 Communication Process

#计算机网络#TLS#密码学337
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
This is a summary of the TLS 1.3 communication process. The client generates a key pair and sends a Client Hello Packet containing information such as random numbers, supported cipher suites, protocol versions, and requested server name. The Key Share extension allows the client to send one or more public keys and encryption algorithms that the server is likely to accept. The server generates its own key pair and sends a Server Hello Packet with similar information. Handshake keys are then calculated using a combination of client and server information. The server sends its certificate for verification, and the client uses its installed CA public key to decrypt the signature and verify the certificate. In some cases, intermediate certificates may be included in the response. The server then encrypts a handshake message digest with its private key and sends it to the client for verification. Once the handshake is complete, application keys are calculated for symmetric encryption. Session tickets are provided by the server for quick session resumption in the future. Multiple session tickets may be sent. The process involves the use of random values and age calculations to prevent replay attacks. Multiple references are provided for further reading on TLS and certificate verification.

TLS1.3 Communication Process Overview, basically translated from https://tls13.xargs.org, it is recommended to refer to the original text.

Client: Generate Key Pair#

Denoted as (client_priv, client_pub)

Client: Send Client Hello Packet in plaintext#

Mainly includes the following contents:

  • Random number client_random
  • Cipher suites supported by the client
  • Protocol versions supported by the client
  • Requested server name SNI (Server Name Indication)
  • PSK (pre-shared keys) pre-shared key mode
  • Key Share public key list (client_pub)
  • Session Ticket
  • Compression method, etc.

The SNI field allows the server to provide multiple TLS services on the same ip group and return the corresponding certificate based on SNI during the handshake process.

The Key Share extension sends one or more public keys and encryption algorithms that the client thinks the server is likely to accept. If the server accepts, the subsequent data after Server Hello can be transmitted encrypted. It is equivalent to performing Key Exchange in advance. If the server cannot accept it, it returns a Retry Hello Request message to restart the handshake.

The Session Ticket is sent by the server after the connection is established, and the client can save this data for subsequent quick recovery and reconnection.

Refer to the use of PSK When do clients use TLS in PSK mode?

Server: Generate Key Pair#

Denoted as (server_priv, server_pub)

Server: Send Server Hello Packet in plaintext#

Mainly includes the following contents:

  • Random number server_random
  • Select a cipher suite
  • Select a public key
  • Select a protocol version
  • Return Key Share including (server_pub)
  • Compression method, etc.

Server: Calculate Handshake Key#

Calculate the handshake key based on the following information:

  • client_pub obtained from the Client Hello Packet
  • server_priv generated by the server
  • Calculate the hash value of the previously sent message SHA384(ClientHello + ServerHello)

All subsequent handshake processes are encrypted using this key.

Client: Calculate Handshake Key#

Calculate the handshake key based on the following information:

  • server_pub obtained from the Server Hello Packet
  • client_priv generated by the client
  • Calculate the hash value of the previously sent message SHA384(ClientHello + ServerHello)

All subsequent handshake processes are encrypted using this key.

Server: Send Certificate in ciphertext#

The server returns the certificate and verifies it based on the SNI specified in the Client Hello.

Certificate Verification and Issuance#

  • The server generates its own key pair (host_priv, host_pub) and combines host_pub with domain name information and regional information to form host_info, which is sent to the CA (Certificate Authority).
  • The CA verifies the applicant's information and encrypts hash(host_info) with its own private key CA_priv to obtain the signature SIG. Finally, the SIG and host_info are combined to form a certificate issued to the server.
  • After the client requests the server to obtain the certificate, it decrypts the signature SIG using the CA public key installed on the local machine to obtain the original data CA_pub(SIG).
  • The client extracts the host_info from the certificate, calculates hash(host_info) by itself, and verifies whether it is consistent with the decrypted signature data.

Certificate Issuance

Trust Chain#

In some cases, the certificate may be issued by a subordinate CA. When the client requests the certificate, the server will return the intermediate certificate and its own certificate:

  • The client first needs to verify the intermediate certificate using the CA public key installed on the local machine and extract the public key of the intermediate certificate.
  • The client then uses the public key of the intermediate certificate to verify the server certificate.

Trust Chain

Server: Send Certificate Verification in ciphertext#

Through the previous step, the client can confirm that the certificate (including its public key) belongs to the current requested service name, but it cannot prove that the server is the owner of this certificate. Therefore, the server needs to encrypt the handshake message digest with the private key host_priv created before the certificate is issued and return it to the client. The client can decrypt this data based on the public key host_pub in the certificate host_info, and then calculate the handshake message digest for comparison. At this point, the client can confirm the security of this connection.

Server: Send Handshake Finished Verification Message in ciphertext#

The server sends the hash of all handshake messages as the verification message to the client.

Server: Calculate Application Key#

The server calculates the Application Key, which is the symmetric key for subsequent data transmission, by taking the hash of all information from the Client Hello to the end of the server handshake using the Handshake Key.

Client: Calculate Application Key#

The client calculates the Application Key using the same method.

Client: Send Handshake Finished in ciphertext#

The client sends the hash of all handshake messages as the verification message to the server.

At this point, the client and the server can communicate with each other using symmetric encryption through the Application Key.

Server: Send Session Ticket 1 in ciphertext#

The server provides the client with a Session Ticket for quick initiation of a new session in the future, reducing a large amount of calculation and network latency in the session creation phase. It includes:

  • Ticket Lifetime
  • Ticket Age Add (each ticket has a separate copy)
  • Ticket Nonce random value (each ticket has a separate copy)
  • Session Ticket

Among them, Ticket Age Add is a random millisecond number generated by the server. When the client uses the Session Ticket to restore the connection, it needs to add this value to the ticket_age (representing the time difference from receiving the Session Ticket to the current time) for confusion. After receiving this value, the server verifies whether the client's ticket_age and the time difference calculated by itself are close. If it exceeds a certain threshold, it can directly reject this connection, to some extent, avoiding replay attacks caused by reusing Session Tickets.

Server: Send Session Ticket 2 in ciphertext#

Due to the fact that the client, such as a browser, generally sends multiple connections, and each Session Ticket can only be used once, the server generally returns multiple Session Tickets.

References:
RFC8446
xargs.org - TLS
xargs.org - x25519
Wikipedia - Shared_secret
Wikipedia - Pre-shared_key
Wikipedia - SNI
A walkthrough of a TLS 1.3 handshake
An In-depth Explanation of HTTPS and TLS Certificate Chain Verification
SSL/TLS Protocol Explanation (Part 2) - Certificate Authority
Network Security Popular Science: Wonderful SSL/TLS Certificate (Basic)

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.