ServerHello – Secrets and Keys in TLS 1.3
12.6.3 ServerHello
Upon receiving a ClientHello message from Bob, Alice responds with the ServerHello message to continue the TLS handshake – if Alice is able to select a feasible set of cryptographic parameters based on the choices offered by Bob in his ClientHello message. The structure of ServerHello is shown in Listing 12.3.
Listing 12.3: ServerHello message structure
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
The legacy˙version field – as you have surely already guessed – is a remnant from previous TLS versions. It was used for version negotiation and contained the TLS version number that Alice selected for that TLS connection.
However, some middleboxes prevent a TLS connection when they encounter a new TLS version number unknown to them in the ServerHello message. A middlebox is a network device that transforms, inspects, filters, and manipulates network traffic beyond mere packet forwarding, for example, a firewall, a network address translator, a load balancer, or a deep packet inspection appliance [182].
To address this downside in TLS 1.3, Alice indicates the TLS version she wants to use in the supported˙versions extension and sets the legacy˙version field to 0x0303, the code for TLS 1.2.
The random field is a 32-byte random number that must be generated using a cryptographically secure random number generator. This number is generated by Alice and is completely independent from the random number in ClientHello.
The TLS 1.3 specification in RFC 8446 requires the use of a cryptographically secure Pseudorandom Number Generator (PRNG). Most modern operating systems provide such a mechanism. As an example, the special /dev/urandom file in Linux-based systems provides the interface to the Linux kernel’s random number generator and can be used as PRNG (see Listing 12.4). As an alternative, most modern cryptographic libraries provide suitable PRNGs.
Listing 12.4: Output of Linux /dev/urandom PRNG
$ hexdump -C -n 8 /dev/urandom
00000000 41 32 c8 61 53 e8 39 d3 |A2.aS.9.|
$ hexdump -C -n 8 /dev/urandom
00000000 30 db cc 9e 7f 03 43 8a |0…..C.|
Random numbers are used in TLS in public message fields such as the random field in ClientHello and ServerHello messages, and for the generation of the keying material itself. As discussed in Chapter 3, A Secret to Share, a cryptographically secure PRNG must be designed in such a way that attacker Eve cannot predict its future output or determine its internal state from previously observed output. Formally, this is captured in the requirement that an attacker cannot efficiently distinguish the output sequence of a PRNG from a truly random sequence of the same length. If a PRNG used in a TLS handshake is insecure and Eve can (partially) predict its output, she can immediately break the security of the TLS connection between Alice and Bob.
The legacy˙session˙id˙echo field contains the legacy˙session˙id value from Bob’s ClientHello message. If Bob receives a ServerHello message with a legacy˙session˙id˙echo value that does not match the value he sent to Alice in ClientHello, Bob immediately terminates the TLS handshake and sends Alice an illegal˙parameter message.
legacy˙session˙id˙echo is also an example of a cryptographic best practice to explicitly verify that what Alice heard is what Bob actually said. When Alice and Bob see different data in a protocol execution, it creates an opportunity for Eve and Mallory to break its security by tricking Alice or Bob to misinterpret the data they see.
The cipher˙suite field contains the single cipher suite that Alice selected from the list of cipher suites offered by Bob in cipher˙suites extension in his ClientHello message. If Alice selects a cipher suite that was not offered by Bob, Bob terminates the TLS handshake with an illegal˙parameter message.
The legacy˙compression˙method field consists of a single byte that is always 0 in TLS 1.3.
Finally, the extensions field contains a list of – well, you guessed it – extensions. The ServerHello message is only allowed to include TLS extensions needed to agree on the cryptographic parameters and the TLS version. Therefore, TLS 1.3 ServerHello always contains the supported˙versions extension and either the pre˙shared˙key or key˙share extension (or both when a pre-shared symmetric key is used in combination with DH or ECDH key agreement).
The ServerHello message in TLS 1.3 also includes a mechanism that allows limited protection against downgrade attacks. In a nutshell, if a TLS 1.3 Alice negotiates a TLS 1.2 or TLS 1.1 connection, it must set the last eight bytes of the random field to the values 44 4F 57 4E 47 52 44 01 or c—44 4F 57 4E 47 52 44 00—, respectively, which means DOWNGRD in ASCII code.