The message by which the client states its intention to do some SSL/TLS.

Note that "client" is a symbolic role; it means "the party which speaks first". It so happens that in the HTTPS context, which is HTTP-within-SSL-within-TCP, all three layers have a notion of "client" and "server", and they all agree (the TCP client is also the SSL client and the HTTP client), but that's kind of a coincidence.

The ClientHello message contains:

the maximum protocol version that the client wishes to support;

the ClientHello.random (32 bytes, out of which 28 are suppose to be generated with a cryptographically strong number generator);

the "session ID" (in case the client wants to resume a session in an abbreviated handshake, see below);

the list of "Cipher Suites" that the client knows of, ordered by client preference;

the list of compression algorithms that the client knows of, ordered by client preference;

When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message. The client will also send a ClientHello when the server has responded to its ClientHello with a HelloRetryRequest. In that case, the client MUST send the same ClientHello (without modification) except:

If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group.

Removing the "early_data" extension (Section 4.2.9) if one was present. Early data is not permitted after HelloRetryRequest.

If a server established a TLS connection with a previous version of TLS and receives a TLS 1.3ClientHello in a renegotiation, it MUST retain the previous protocol version. In particular, it MUST NOT negotiate TLS 1.3.

legacy_version In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.)

legacy_session_id - Versions of TLS before TLS 1.3 supported a "session resumption" feature which has been merged with Pre-Shared Keys in this version (see Section 2.2). This field MUST be ignored by a server negotiating TLS 1.3 and MUST be set as a zero length vector (i.e., a single zero byte length field) by clients that do not have a cached session ID set by a pre-TLS 1.3 server.

All versions of TLS allow extensions to optionally follow the compression_methods field as an extensions field. TLS 1.3 ClientHello messages always contain extensions (minimally, "supported_versions", or they will be interpreted as TLS 1.2 ClientHello messages), however TLS 1.3 servers might receive ClientHello messages without an extensions field from prior versions of TLS. The presence of extensions can be detected by determining whether there are bytes following the compression_methods field at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined. TLS 1.3 servers will need to perform this check first and only attempt to negotiate TLS 1.3 if a "supported_version" extension is present. If negotiating a version of TLS prior to TLS 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following. If not, then it MUST abort the TLS Handshake with a "decode_error" alert.
In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the clientMAY abort the TLS Handshake.