TLS 1.3 Handshake Packet Analysis

TLS Mechanism

Transport Layer Security (TLS) is a cryptographic protocol that operates above the transport layer to provide secuirty services to applications (such as HTTPS, SMTP, POP3, etc.). We have TLS over TCP and DTLS over UDP and it typically relies on a public key infrastructure (PKI).

TLS provides:

• authentication(server-to-client) based on public key certificates. (client-to-server auth is optional).
• confidentiality & integrity of message transmission.
• NOTE: confidentiality is protected only if authentication is correct.

During TLS handshake, it does the following:

• Negotiation of cryptographic parameters
• Authentication (oftern one-way) using public key certificates
• Establish a master secret key
• Derivation of encryption/authentication keys from the master key
• Key confirmation

Then bi-direction authenticated encryption follows in the record layer.

Problem in establishing a master key using RSA:

RSA key is transported as follow:

• Server sends its RSA public key to the client inside certificate
• Client picks a random premaster secret
• Client sends premaster secret encrypted under server's RSA public key
NOTE: No forward secrecy! (was allowed for TLS <= 1.2)

Since TLS v1.3, we use ephemeral Diffie-Hellman where the server generates a temporary (EC)DH pub key and sends toclient, signs it using its signature key from certificate. Client then generates a temporary (EC)DH pub key and sends to the server and they compute (EC)DH shared secret.

TLS setup in advance:

• CA setup
CA generates an RSA signature key pair (pk_CA, sk_CA).
Client must have pk_CA installed in browser. If not, add it.
• Certificate Issuance
Server generates an RSA signature key pair (pk_S, sk_S).
Server gets CA to issue a certificate for its public key: cert_S = Sign(sk_CA, "Bob"||pk_S)
Bob gets cert_S

Lab

Procedure:

1. Dump traffics using wireshark while connecting to my website :D (https://dc-lee.com)
2. Look into packets :P

High-level observation

• [12] ClientHello
• [14] ServerHello + Exchange cipher spec
• [15] Data encryption began

Detailed Investigation

1. Packet 12 (Client Hello)
Overview:

• TLS version support



It supports TLS v1.0-1.3 as indicated in supported_versions field.
NOTE: Version field is a legacy_version which is not used anymore.

• Client offers various cipher suites for all TLS versions.



• Cipher suite for TLS <= 1.2:
TLS_<KeyExchange>_WITH_<DataEncryption>
For example, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA384 says that key exchange method is ephemeral elliptic curve diffie-hellman and authenticated with RSA method. Record layer encryption would be AES_128_GCM_SHA384 (a type of AEAD algorithm).
• Cipher suite for TLS v1.3:
TLS_<DataEncryption>
For example, TLS_AES_256_GCM_SHA384 says the record layer encryption would be AES_256_GCM_SHA384 (a type of AEAD algorithm).
NOTE: In TLS v1.3, we don't talk about key exchange and authentication algorithms in Cipher Suites field.
• Key exchange for TLS v1.3



Client supports three ECDHE methods (x25519, secp256r1, secp384r1). (x25519 == Curve25519, secp256r1 == NISTP-256, secp384r1 == NISTP-384) as indicated in key_share field.
We also observe that client is providing public key for each elliptic curve.

• PSK key exchange mode



PSK (Pre-Shared Key) is a shared secret key betwen client and server for which helps reducing handshake delay by allowing session resumption and/or 0-RTT connection.
There are two modes for exchanging PSK key:

• psk_ke (0): Uses only PSK in exchange
No forward secrecy!
• psk_dhe_ke (1): Uses PSK + ECDHE
Has forward secrecy! (a bit slower)
Details of PSK in TLS handshake are described in section 2.2 and 2.3 of RFC8446.
• Signature algorithms support



It lists signature algorithms that client supports, so that the server knows what algorithm he should use to sign his certificate.
NOTE: rsa_pkcs1 uses padding scheme PKCS#1 which is a deterministic padding. Thus, it directly disobeys semantic security and is not safe against chosen-message attack.

2. Packet 14 (Server Hello)
Overview:

• server chose TLS_AES_256_GCM_SHA384 as its cipher suite.
• Server chose x25519 elliptic curve and sent its public key.
  NOTE: The computational Diffie-Hellman assumption and discrete logarithm assumption assure that people like you cannot recover my secret key :P I (partially) belive in current cryptographers. Even if you recover the key, it will be useless since it is ephemeral :P

3. Packet 15 (Encrypted data from server)
After the server sent its public key, certificate verification, certification and finished messages are sent encrypted. I suspect packet 15 is responsible for it.