The handshake protocol is used to negotiate connection security parameters. Handshake messages are provided to the TLS recording layer, where they are encapsulated in one or more TLSPlaintext or TLSCiphertext, which are processed and transmitted according to the current active connection state.
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
Copy the codeProtocol messages must be sent in a certain order (see below for the order). If peer ends find that the received handshake messages are unexpected, they must abort the handshake with the “unexpected_message” alert message.
In addition, IANA assigned a new handshake message type, as shown in Chapter 11
Key Exchange Messages
Key exchange messages are used to ensure the security of Client and Server and to establish the security of communication keys used to protect handshakes and data.
1. Cryptographic Negotiation
During key negotiation in TLS, ClientHello allows clients to provide the following options.
- List of encryption suites supported by Client. The password suite can display the AEAD algorithm or HKDF hash pair supported by the Client.
- Supported_groups extension and key_share extension. Supported_groups indicates which (EC)DHE groups are supported by the Client, and key_share indicates whether the Client contains some or all (EC)DHE shares.
- Extension of “signature_algorithms” and “signature_ALGORITHms_cert “signature certificate algorithms. Signature_algorithms “This extension shows what signature algorithms clients can support. Signature_algorithms_cert “This extension shows the signature algorithm for a specific certificate.
- “Pre_shared_key” pre-shared keys and “pSK_KEY_exchange_MODES” extensions. Pre-shared key extensions contain symmetric key identifiers that clients can recognize. The pSK_KEY_exchange_modes “extension indicates key exchange modes that may be used with PSK.
If the Server does not select PSK, then the first three of the above four options are orthogonal. The Server independently selects an encryption suite, independently selects a (EC)DHE group, and independently selects a key share for establishing the connection. Independently select a signature algorithm/certificate pair for Client authentication Server. If the Server received no algorithm supported by the Server in the “supported_groups” file, the Server must return an alert message of “handshake_failure” or “Insufficient_security”.
If the Server chooses PSK, it must select a key from the Client’s “pSK_KEY_exchange_MODES” extension message to establish the mode. PSK and (EC)DHE are separated at this point. Even if the same supported_groups algorithm does not exist in “PSK” and (EC)DHE, the handshake will not terminate.
If the Server selects the (EC)DHE group and the Client does not provide the appropriate “KEY_share” extension in ClientHello, the Server must respond with the HelloRetryRequest message.
If the Server successfully selects the parameters, the HelloRetryRequest message is no longer required. The Server will send the ServerHello message, which contains the following parameters:
- If PSK is being used, Server will send the “pre_shareD_key” extension, which contains the selected key.
- If PSK is not used and (EC)DHE is selected, Server will provide a “key_share” extension. Typically, if PSK is not used, (EC)DHE and certificate-based authentication are used.
- When a Certificate is authenticated, the Server sends Certificate and CertificateVerify messages. PSK and certificates are commonly used in TLS 1.3, but not together, and future documentation may define how to use them together.
If the Server cannot negotiate a supported parameter set, that is, there is no overlap between the parameter sets supported by the Client and Server. The Server must send the message “handshake_failure” or “Insufficient_Security” to stop the handshake.
2. Client Hello
When a Client connects to a Server for the first time, it sends a ClientHello message along with the first TLS message. When the Server sends the HelloRetryRequest message, the Client needs to respond with a ClientHello message after receiving it. In this case, the Client must send the same ClientHello message without modification, except in the following cases:
- If the HelloRetryRequest message contains the “KEY_share” extension, replace the share list with a single KeyShareEntry from the indicated group.
- Remove the “early_data” extension if it exists. “Early_data” is not allowed after HelloRetryRequest.
- If the HelloRetryRequest includes a cookie extension, you need to include one.
- Update the “pre_shared_key” extension if the “obfuscated_ticket_age” and binding values are recalculated and (optionally) any PSK incompatible with the password family displayed by the Server is removed.
- Optionally add, remove, or change the length of the “padding” extension RFC 7685.
- Some other modifications that may be allowed. For example, some future extension definitions and HelloRetryRequest will be specified.
Renegotiation is prohibited in TLS 1.3. If a Server receives a ClientHello at some point in the future after completing TLS 1.3 negotiation, the Server should ignore this message and must immediately disconnect from the connection. Send “unexpected_message” alert message.
If a Server establishes a TLS connection with a previous version of TLS and receives ClientHello for TLS 1.3 during renegotiation, the Server must retain the previous version and is prohibited from negotiating TLS 1.3.
The structure of the ClientHello message is
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; V1.2 * / / * TLS
Random random;
opaque legacy_session_id<0.32.>;
CipherSuite cipher_suites<2.2.^162 ->;
opaque legacy_compression_methods<1.2.^8- 1>;
Extension extensions<8.2.^16- 1>;
} ClientHello;
Copy the codeSome notes on the structure:
-
Legacy_version: In previous versions of TLS, this field was used for version negotiation and to indicate the highest version of TLS that clients could support. Experience shows that many servers don’t properly implement version negotiation, resulting in “version atragweed “– Sever rejects some ClientHello messages that could have been supported just because the version number is higher than the Server can support. In TLS 1.3, the Client indicates its version in the “supported_versions” extension. And the legacy_Version field must be set to 0x0303, which is the TLS 1.2 version number. Legacy_version in ClientHello messages in TLS 1.3 is set to 0x0303, supported_versions extension is set to 0x0304. See Appendix D for more details.
-
Random: A random 32-byte number generated by a secure random number generator. Additional information is provided in Appendix C.
-
Legacy_session_id: Earlier versions of TLS 1.3 support session recovery. In this version of TLS 1.3, this feature has been merged with the pre-shared key PSK. If the Client has a cached Session ID set by the Server prior to TLS 1.3, this field should be filled in. In compatibility mode, this value must be non-null, so a Client that cannot provide sessions prior to TLS 1.3 must generate a new 32-byte value. This value should not be random, but it should be an unpredictable value to prevent implementation from being fixed to a fixed value. Otherwise, the field must be set to a vector of length 0. (For example, a 0 byte length field)
-
Cipher_suites: This list is a list of symmetric encryption options supported by the Client, especially the hash algorithm used by record protection algorithms (including key length) and HKDF. In descending order of Client preference. If the list contains cipher suites that the Server does not recognize or support, or that it wants to use, the Server must ignore them and process the remaining cipher suites as usual. If a Client attempts to build a PSK key, it should contain at least one hash encryption suite associated with PSK.
-
Legacy_compression_methods: Compression was supported in TLS versions prior to TLS 1.3. Send a list of supported compression methods in this field. For each ClientHello, the vector must contain a byte set to 0, which corresponds to the NULL compression method in previous versions of TLS. If this field in ClientHello in TLS 1.3 contains a value, the Server must immediately send an “illegal_parameter” alert message to abort the handshake. Note that TLS 1.3 Server may receive TLS 1.2 or older versions of ClientHellos that include other compression methods. If these prior versions are being negotiated, the provisions of prior versions of TLS must be followed.
-
Extensions: The Client requests extensions from the Server by sending data in the extensions field. “Extension” follows the format definition. In TLS 1.3, it is mandatory to use certain extensions. The functionality was moved to the extension to maintain compatibility with previous TLS versions of ClientHello messages. The Server must ignore extensions that are not recognized.
All versions of TLS allow an optional compression_methods extension field. TLS 1.3 ClientHello messages usually contain extended messages (at least “supported_versions”, otherwise this message will be interpreted as a ClientHello message for TLS 1.2) TLS 1.3 Server may also receive ClientHello messages without extended fields from previous VERSIONS of TLS. The existence of the extension can be determined by detecting whether there are bytes in the compression_methods field at the end of ClientHello. Note that this method of detecting optional data is different from the normal TLS method with variable-length fields, but it can be used for compatibility until the extension is defined. The TLS 1.3 Server needs to perform this check first, and attempts to negotiate TLS 1.3 only when the supported_versions extension exists. If you are negotiating versions prior to TLS 1.3, the Server must do two checks: is there any data after the legacy_compression_methods field; Valid Extensions block with no data to follow. If both of these checks fail, a “decode_error” alert message is immediately sent to abort the handshake.
If a Client requests additional functionality through an extension that the Server does not provide, the Client can abort the handshake.
After sending the ClientHello message, the Client waits for the ServerHello or HelloRetryRequest message. If Early Data is in use, the Client can send Early Application Data while waiting for the next handshake message.
3. Server Hello
If the Server and Client can negotiate a mutually acceptable set of handshake parameters in the ClientHello message, the Server responds to the ClientHello message with a Server Hello message.
The structure of the message is:
struct {
ProtocolVersion legacy_version = 0x0303; V1.2 * / / * TLS
Random random;
opaque legacy_session_id_echo<0.32.>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6.2.^16- 1>;
} ServerHello;
Copy the code-
Legacy_version: Prior to TLS 1.3, this field is used for version negotiation and identifies the version selected by both parties when establishing a connection. Unfortunately, some middleware may fail to assign a new value to this field. In TLS 1.3, the Server identifies the version supported by the “supported_versions” extension field, and the legacy_version field must be set to 0x0303(this value represents TLS 1.2). (For more information on backward compatibility, see Appendix D.)
-
Random: Random 32 bytes generated by a secure random number generator. If TLS 1.1 or TLS 1.2 is negotiated, the last 8 bytes must be overridden and the remaining 24 bytes must be random. This structure is generated by the Server and must be independent of Clienthell.random.
-
Legacy_session_id_echo: indicates the content of the LEGacY_session_id field of the Client. Note that even if the Server decides not to resume sessions before TLS 1.3, the Client legacy_session_ID field caches values before TLS 1.3, At this time the legacY_sESSION_ID_echo field will also be taken. If the legacY_session_ID_echo value received by the Client does not match the value sent in ClientHello, the Client must immediately abort the handshake with the “illegal_parameter” alert message.
-
Cipher_suite: Server An encryption suite selected from the Cipher_Suites list in ClientHello. If the Client receives a password suite that is not provided, it should immediately abort the handshake with the “illegal_parameter” alert message.
-
Legacy_compression_method: a single byte that must have a value of 0.
-
Extensions: List of extensions. ServerHello must include only the extensions required to establish the encryption context and negotiate the protocol version. All ServerHello messages in TLS 1.3 must contain the “supported_versions” extension. The current ServerHello message also contains the “pre_shared_key” extension or the “key_share” extension, or both (when establishing connections using PSK and (EC)DHE). Other extensions are sent separately in the EncryptedExtensions message.
For backwards compatible middleware reasons, the HelloRetryRequest message has the same structure as the ServerHello message, but the Sha-256-specific value of HelloRetryRequest needs to be set randomly:
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
Copy the codeWhen receiving the server_hello message, the implementation must first check that the random value matches the one above. If it matches the value above, proceed.
TLS 1.3 has degrade protection, which is implemented through random values embedded in the Server. TLS 1.3 The Server negotiates TLS 1.2 or older, and in response to ClientHello, the ServerHello message must be filled with a specific random value in the last eight bytes.
If TLS 1.2 is negotiated, TLS 1.3 Server must set the last 8 bytes of the Random field in ServerHello to:
44 4F 57 4E 47 52 44 01
D O W N G R D
Copy the codeIf TLS 1.1 or older is negotiated, TLS 1.3 Server and TLS 1.2 Server must change the last 8 bytes of the Random field in ServerHello to:
44 4F 57 4E 47 52 44 00
D O W N G R D
Copy the codeTLS 1.3 After receiving the ServerHello message from TLS 1.2 or older versions, the Client must check that the last 8 bytes of the Random field in ServerHello do not equal the preceding two values. The TLS 1.2 Client also checks the last 8 bytes, and if TLS 1.1 or older is negotiated, the Random value should not equal the second value above. If neither match, the Client must abort the handshake with an “illegal_parameter” alert message. This mechanism provides limited protection against degrade attacks. Finished Exchange allows you to override the protection mechanism because ServerKeyExchange messages contain signatures with two random values on TLS 1.2 or later. As long as temporary encryption is used, it is impossible for an attacker to alter random values without being detected. Therefore, static RSA does not provide protection against degraded attacks.
Please note that the changes described in RFC5246 are not implemented by many TLS 1.2 clients and servers.
If a Client receives ServerHello of TLS 1.3 during TLS 1.2 or earlier negotiation, the Client must send a protocol_version alert immediately to terminate the handshake. Please note that once TLS 1.3 has been negotiated, it cannot be renegotiated because TLS 1.3 forbids renegotiation.
4. Hello Retry Request
If a ClientHello message from the Client finds a set of mutually supporting parameters, but the Client does not provide enough information for the subsequent handshake, At this point, the Server sends the HelloRetryRequest message in response to the ClientHello message. In the previous section, we talked about the HelloRetryRequest and ServerHello messages having the same data structure, Legacy_version, LEGacY_session_ID_echo, cipher_SUITE, and LEGacy_compression_method have the same meanings. For the sake of discussion, the HelloRetryRequest messages are treated as different messages in the following sections.
The Server extension set must contain supported_versions. In addition, it needs to include a minimal set of extensions that allow the Client to generate the correct ClientHello pair. In contrast to ServerHello, HelloRetryRequest can only contain any extensions that appeared in the first ClientHello, with the exception of the optional “cookie.”
After the Client receives the HelloRetryRequest message, Legacy_version, LEGacY_session_ID_echo, cipher_SUITE, and LEGacy_compression_method must be verified. Supported_versions determines the version of the file to be connected to the Server, and then processes the extension. If the HelloRetryRequest does not result in any changes to ClientHello, the Client must abort the handshake with an “illegal_Parameter” alert message. If the Client receives a second HelloRetryRequest message in a connection (ClientHello itself responds to the HelloRetryRequest), Then one must unexpected_message alert message to abort the handshake.
Otherwise, the Client must process all the extensions in the HelloRetryRequest and send the second updated ClientHello. The HelloRetryRequest extension defined in this specification is:
- supported_versions
- cookie
- key_share
The Client must immediately abort the handshake when it receives a cipher suite that it does not provide. Servers must ensure that when they receive a valid and updated ClientHello, they are negotiating the same ciphersuite (this step is automatically sent if the Server chooses the ciphersuite as the first step in the negotiation). After receiving ServerHello, the Client must check whether the password suite provided by ServerHello is the same as that provided by HelloRetryRequest. Otherwise, the Client terminates the handshake with the Illegal_parameter alert message.
In addition, in its updated ClientHello, the Client cannot provide any pre-shared key (associated with a hash) that is not associated with the selected cipher suite. This allows the Client to avoid a partial hash transcript that computes multiple hashes in the second ClientHello.
The value of the selected_version field in the “support_versions” extension of the HelloRetryRequest must be retained in ServerHello. If this value changes, The Client must abort the handshake with the “illegal_parameter” alert message.
Two Extensions.
Many TLS messages contain tag-length-value encoded extended data structures:
struct {
ExtensionType extension_type;
opaque extension_data<0.2.^16- 1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
Copy the codeHere:
- “Extension_type” identifies a specific extension state.
- “Extension_data” contains information specific to that particular extension type.
All extension types are maintained by IANA, as detailed in the appendix.
Extensions are typically built in a request/response fashion, although some extensions are just identifiers with no response. The Client sends its extension request in ClientHello, and the Server sends the corresponding extension response in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages. The Server sends the extension request in a Certificate request message, and the Client may respond to the Certificate message. The Server may send an extension request in the Newssession ticket message without being invited. The Client does not need to respond to the extension request directly.
If the remote side does not send a corresponding extension request, the implementer cannot send an extension response other than the “cookie” extension in the HelloRetryRequest message. After receiving such an extension, the endpoint must abort the handshake with an “unsupported_extension” alert message.
The following table shows the possible message extensions in the following notation: CH (ClientHello), SH (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR (CertificateRequest), NST (newssession ticket) and HRR (HelloRetryRequest). The implementer must abort the handshake with an “illegal_parameter” alert message when it receives a message it recognizes and does not specify the presence of the message.
+--------------------------------------------------+-------------+
| Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms (RFC 8446) | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share (RFC 8446) | CH, SH, HRR |
| | |
| pre_shared_key (RFC 8446) | CH, SH |
| | |
| psk_key_exchange_modes (RFC 8446) | CH |
| | |
| early_data (RFC 8446) | CH, EE, NST |
| | |
| cookie (RFC 8446) | CH, HRR |
| | |
| supported_versions (RFC 8446) | CH, SH, HRR |
| | |
| certificate_authorities (RFC 8446) | CH, CR |
| | |
| oid_filters (RFC 8446) | CR |
| | |
| post_handshake_auth (RFC 8446) | CH |
| | |
| signature_algorithms_cert (RFC 8446) | CH, CR |
+--------------------------------------------------+-------------+
Copy the codeWhen there are multiple types of extensions, the order between the extensions can be arbitrary, except that “pre_shared_key” must be the last extension of ClientHello. “Pre_shared_key” can appear anywhere in the ServerHello extension block. There cannot be more than one extension of the same type.
In TLS 1.3, unlike TLS 1.2, negotiation extensions are required for each handshake, even to restore PSK mode. However, the parameters for 0-RTT are negotiated in the previous handshake. If the parameters do not match, 0-RTT needs to be rejected.
There are subtle interactions between new and old features in TLS 1.3, which can make overall security significantly less secure. Here are some factors to consider when designing a new extension:
-
Some cases where the Server disagrees with the extension are wrong (for example, the handshake cannot continue), and some cases simply do not support specific functionality. In general, the former case should be handled with an error alert, and the latter case should be handled with a field in the Server’s extended response.
-
Wherever possible, extensions should be designed to prevent attacks that can force the use (or non-use) of a particular feature by artificially manipulating the handshake information. This principle must be followed regardless of whether this feature raises security concerns. Normally, the extension fields included in the hash input of the Finished message should not be a concern, but you need to be careful when the extension attempts to change the meaning of the sent message during the handshake phase. Designers and implementers should be aware that attackers can modify messages, insert, delete, or replace extensions before the handshake completes authentication.
1. Supported Versions
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2.254.>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
Copy the codeSupported_versions: For the Client, it indicates the TLS version supported by the Client, and for the Server, it indicates the TLS version being used by the Server. This extension contains a list of supported versions, in order of precedence. The version with the highest priority of support is placed first. The specification for TLS version 1.3 is that ClientHello messages must be sent with this extension, which contains all versions of TLS to be negotiated. (For this specification, this means a minimum of 0x0304, but this extension must be carried if previous versions of TLS are to be negotiated.)
If the SUPPORted_versions extension does not exist, the Server that meets TLS 1.3 and is compatible with TLS 1.2 must negotiate TLS 1.2 or earlier versions. Even if clienthello.legacy_version is 0x0304 or higher. The Server may need to abort the handshake immediately when it receives a value of legacy_version 0x0304 or higher in ClientHello.
If the supported_versions extension of ClientHello exists, the Server does not use the value of Clienthell. legacy_version as the version negotiation value. Only supported_versions can be used to determine the Client preference. The Server must select only TLS versions that exist in the extension and must ignore any unknown versions. Note that this mechanism makes it possible to negotiate between versions prior to TLS 1.2 if the communicating party supports sparse ranges. An implementation of TLS 1.3, a previous version that supports TLS, should support TLS 1.2. The Server should be ready to receive ClientHellos messages with this extension, but do not include 0x0304 in the Viersions list.
To negotiate TLS versions earlier than 1.3, you must set serverHello. version and cannot send the “supported_versions” extension. When the Server negotiates the TLS 1.3 version, it must send the “SUPPORted_versions” extension in response, and the extension must contain the selected TLS 1.3 version (0x0304). Also set serverHello.legacy_version to 0x0303(TLS 1.2). Client must check this extension before processing ServerHello (although ServerHello needs to be parsed first in order to read the extension). If the “supported_versions” extension exists, the Client must ignore the value of serverHello. legacy_version and use the value of “supported_versions” to determine the selected version. If the “supported_versions” extension in ServerHello contains a version not provided by the Client, or a version before TLS 1.3 is included, The Client must immediately send an “illegal_parameter” alert message to abort the handshake.
2. Cookie
struct {
opaque cookie<1.2.^16- 1>;
} Cookie;
Copy the codeCookies have two main purposes:
-
Allows the Server to force clients to show network address reachability (thus providing a metric to protect Dos), which is primarily for connectionless transport (see the example in RFC 6347)
-
Allows Server uninstallation status. This allows the Server to send the HelloRetryRequest message to the Client without storing any state. To do this, the Server can store ClientHello’s hash in the Cookies of the HelloRetryRequest (protected with some appropriate integrity algorithms).
When sending the HelloRetryRequest message, the Server can provide a “cookie” extension to the Client (this is an exception to the general convention that only extensions that can be sent can appear in ClientHello). When sending a new ClientHello message, the Client must copy the contents of the extension received in the HelloRetryRequest into the “cookie” extension in the new ClientHello. The Client may not use the Cookie from the initial ClientHello in subsequent connections.
When the Server is running stateless, it may receive an unprotected Change_cipher_spec message between the first and second ClientHello. Since the Server does not store any state, it behaves as if the first message arrived. A stateless Server must ignore these records.
3. Signature Algorithms
TLS 1.3 provides two extensions to indicate the signature algorithms that may be used in digital signatures. Signature_algorithms_cert “Extension provides signature algorithms in certificates.” The signature_algorithms” extension (TLS 1.2) provides signing algorithms in CertificateVerify messages. The key in the certificate must match the appropriate type based on the signature algorithm used. This is a special problem for RSA keys and PSS signatures, described as follows: If there is no “signature_ALGORITHms_cert” extension, then the “Signature_algorithms” extension also applies to signatures in certificates. If the Client wants the Server to authenticate itself with a certificate, it must send the “signature_algorithms” extension. If the Server is authenticating a certificate and the Client does not provide “signature_algorithms” extension, the Server must send a “missing_extension” message to abort the handshake.
The intent of the “signature_algorithms_cert” extension is to allow implementations of different sets of algorithms that already support certificates to explicitly identify their capabilities. The TLS 1.2 implementation should and should handle this extension. Implementations that have the same policy in both cases can omit the “signature_algorithms_cert” extension.
The “extension_data” field in these extensions contains a SignatureSchemeList value:
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
private_use(0xFE00.. 0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2.2.^162 ->;
} SignatureSchemeList;
Copy the codeNote: This enumeration is named “SignatureScheme” because the “SignatureAlgorithm” type already exists in TLS 1.2, replacing it. Throughout this article, we all use the term “signature algorithm.”
Each listed SignatureScheme value is a single signature algorithm that Client wants to verify. The values are listed in descending order of priority. Note that the signature algorithm takes an arbitrary length message as input, not a digest. The algorithms traditionally used for digests should be defined in TLS, first hashing the input using the specified hash algorithm, followed by general processing. The code listed above has the following meanings:
-
Rsassa-pkcs1-v1_5 Algorithms: Indicates the signature algorithm using RSassa-PKCS1-V1_5 RFC8017 and the corresponding hash algorithm defined in SHS. These values refer only to signatures that appear in the certificate and are not defined for signing TLS handshake messages. These values will appear in “signature_algorithms” and “signature_algorithms_cert” because backwards compatibility with TLS 1.2 is required.
-
Using ECDSA, the corresponding curves are defined in ANSI X9.62 ECDSA and FIPS 186-4 DSS, and the corresponding hash algorithms are defined in SHS. The signature is represented as an DER encoded ECDSA-sig-value structure.
-
Rsassa-pss RSAE algorithms: indicates the RSASSA-PSS signature algorithm with mask generation function 1. Both the digest used in the mask generator and the digest being signed are the corresponding hash algorithms defined in SHS. The length of the salt must equal the length of the output of the digest algorithm. If the public key is in the X.509 certificate, you must use rsaEncryption OID RFC5280.
-
EdDSA Algorithms: Using THE EdDSA algorithm defined in RFC 8032 or its subsequent improvements. Note that these corresponding algorithms are “PureEdDSA” algorithms, not “prehash” variants.
-
Rsassa-pss PSS algorithms: indicates the RSASSA-PSS RFC 8017 signature algorithm with mask generation function 1. Both the digest used in the mask generator and the digest being signed are the corresponding hash algorithms defined in SHS. The length of the salt must be equal to the length of the digest algorithm. If the public key is in the X.509 certificate, you must use RSASSA-PSS OID RFC5756. When it is used in the certificate signature, the algorithm parameter must be DER encoding. If corresponding public key parameters exist, the parameters in the signature must be the same as those in the public key.
-
Legacy algorithms: Using algorithms that are being deprecated because they have known weaknesses. In particular, SHA-1 is used in conjunction with the rsassa-PKCS1-V1_5 and ECDSA algorithms mentioned above. These values refer only to signatures that appear in the certificate and are not defined for signing TLS handshake messages. These values will appear in “signature_algorithms” and “signature_algorithms_cert” because backwards compatibility with TLS 1.2 is required. Endpoints should not negotiate these algorithms, but are allowed to do so only for backward compatibility. Clients that provide these values must list them in the lowest priority position (after all other algorithms in SignatureSchemeList). TLS 1.3 Server must not provide a SHA-1 signed certificate unless a valid certificate chain cannot be generated without it.
Certificates with signatures or trust anchors on self-signed certificates cannot be verified because they start an authentication path (see RFC 5280). The certificate that starts the authentication path can use a signature algorithm not recommended to be supported in the “signature_algorithms” extension.
Note that this extension is defined differently in TLS 1.2 than in TLS 1.3. When negotiating TLS 1.2, TLS 1.3 implementations willing to negotiate TLS 1.2 must meet the requirements of RFC5246, in particular:
-
TLS 1.2 ClientHellos can ignore this extension.
-
In TLS 1.2, the extension includes hash/ Signature Pairs. These pairs are encoded as two octet bytes, so the SignatureScheme value of the allocated space is aligned with the TLS 1.2 encoding. Some traditional Pairs remain unassigned. These algorithms have been deprecated by TLS 1.3. They may not be provided or negotiated in any implementation. In particular, do not use MD5 [SLOTH], SHA-224, and DSA.
-
The ECDSA signature scheme is consistent with the Hash/Signature Pairs of TLS 1.2. However, the old semantics did not limit the signature curve. If TLS 1.2 is negotiated, the implementer must be prepared to accept the signature of any curve in the “supported_groups” extension.
-
Implementers that support RSASSA-PSS (mandatory in TLS 1.3) are prepared to accept the signature of the scheme even if TLS 1.2 is negotiated. In TLS 1.2, rsassa-pSS is used with the RSA cipher suite.
4. Certificate Authorities
The “Certificate_AUTHORITIES” extension is used to represent the CA supported by the terminal, and receiving endpoints should use it to guide certificate selection.
“Certificate_authorities” extension of main body includes a CertificateAuthoritiesExtension structure:
opaque DistinguishedName<1.2.^16- 1>;
struct {
DistinguishedName authorities<3.2.^16- 1>;
} CertificateAuthoritiesExtension;
Copy the code- Authorities: A list of recognized names X501 of certificate authorities in DER X690 encoding format. These resolvable names are the desired resolvable names specified by the trust anchor or dependent CA. Therefore, you can use this message to describe known trust anchors and the authorization space required.
The Client may send the “Certificate_AUTHORITIES” extension in a ClientHello message, Server may send the “certificate_authorities” extension in a CertificateRequest message.
The “TRUSTEd_CA_keys” extension serves the same purpose as the “CERTIFicate_authorities” extension, but is more complex. The trusted_CA_keys “extension is not available in TLS 1.3, but it is available in versions prior to TLS 1.3 and may appear in Client ClientHello messages.
5. OID Filters
The “oid_filters” extension allows the Server to provide a set of OID/value pairs that match Client certificates. If Server wants to send this extension, it can do so only in a Certificate Test message.
struct {
opaque certificate_extension_oid<1.2.^8- 1>;
opaque certificate_extension_values<0.2.^16- 1>;
} OIDFilter;
struct {
OIDFilter filters<0.2.^16- 1>;
} OIDFilterExtension;
Copy the code- Filters: A list of certificate extensions OID RFC 5280 with allowed values, in DER encoded X690 format. Some certificate extension oids allow multiple values (for example, Extended Key Usage). If the Server contains a non-empty list of filters, the Client certificate included in the response must contain all specified extension oids recognized by the Client. For each extension OID recognized by the Client, all specified values must exist in the Client certificate (but the certificate can have other values as well). However, the Client must ignore and skip any unrecognized certificate extension OID. If the Client ignores some required certificate extension OID and provides a certificate that does not meet the request. The Server can decide whether to continue the connection with an unauthenticated Client or abort the handshake with an “unsupported_certificate” alert message. No given OID can appear more than once in the list of filters.
The PKIX RFC defines various certificate extension oids and their corresponding value types. Matching certificate extension values are not necessarily bitwise equal, depending on the type. It is expected that TLS implementations will rely on their PKI library, using the certificate extension OID for certificate selection.
This document defines the matching rules for the two standard certificate extensions defined in RFC5280:
-
When all Key Usage bits declared in the request are also declared in the Key Usage certificate extension, the Key Usage extension in the certificate matches the request.
-
The Extended Key Usage in the certificate matches the request when all the Key OIDs in the request are also present in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID must not be used in the request.
Separate specifications can define matching rules for rules extended by other certificates.
6. Post-Handshake Client Authentication
The “post_handshake_auth” extension is used to indicate that the Client is willing to re-authenticate after a handshake. Server cannot send a Post-handshake re-authentication certificate message to clients that do not provide this extension. Server cannot send this extension.
struct {} PostHandshakeAuth;
Copy the codeThe “extension_data” field in the “post_handshake_auth” extension has zero length.
7. Supported Groups
When the Client sends the “supported_groups” extension, this extension indicates the named groups supported by the Client for key exchange. From highest to lowest in order of priority.
Note: In versions prior to TLS 1.3, this extension was called “elliptic_curves” and only included groups of elliptic curves. For details, see RFC8422 and RFC7919. This extension can also be used to negotiate ECDSA curves. The signature algorithm now negotiates independently.
The “extension_data” field in this extension contains a” NamedGroupList” value:
enum {
/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC.. 0x01FF),
ecdhe_private_use(0xFE00.. 0xFEFF),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2.2.^16- 1>;
} NamedGroupList;
Copy the code-
Elliptic Curve Groups (ECDHE): Indicates support for corresponding named curves defined in FIPS 186-4 [DSS] or [RFC7748]. Values 0xFE00 to 0xFEFF are reserved for use with [RFC8126].
-
Finite Field Groups (DHE): Indicates that corresponding Finite Field Groups are supported. See [RFC7919] for definitions. The values from 0x01FC to 0x01FF are reserved.
The items in named_group_list are sorted according to the priority of the sender (preferably preferentially selected).
In TLS 1.3, the Server allows sending the “supported_groups” extension to the Client. The Client cannot act on any information found in “supported_groups” before successfully completing the handshake, but can use information obtained from a successfully completed handshake to change the group used in the “key_share” extension in subsequent connections. If the Server has a group that prefers to accept the values in the “key_share” extension, but still prefers to accept ClientHello messages, it should send “supported_groups” to update the Client’s preference view. This extension should contain all groups supported by the Server, regardless of whether the Client supports it or not.
8. Key Share
The “key_share” extension contains encryption parameters for the terminal.
The Client may send an empty client_shares vector, requesting the selected group from the Server at an additional round-trip cost.
struct {
NamedGroup group;
opaque key_exchange<1.2.^16- 1>;
} KeyShareEntry;
Copy the code-
Group: named group of keys to be exchanged.
-
Key_exchange: information about key exchange. The content of this field is determined by the specific group and the corresponding definition. The Diffie-Hellman parameter for a finite field is described below. The Diffie-Hellman parameter for elliptic curves is also described below.
In the ClientHello message, the “extension_data” in the “key_share” extension contains the KeyShareClientHello value:
struct {
KeyShareEntry client_shares<0.2.^16- 1>;
} KeyShareClientHello;
Copy the code- Client_shares: a list of KeyShareEntry values in descending order based on Client preferences.
This vector can be null if the Client is requesting HelloRetryRequest. Each KeyShareEntry value must correspond to a group provided in the “supported_groups” extension, and must appear in the same order. However, it is possible that the value can be a discontinuous subset of the “supported_groups” extension and the most preferred group can be omitted when the combination with the highest priority is new and insufficient to provide pre-generated key Shares.
A Client can provide as many KeyShareEntry values as the support groups it provides. Each value represents a set of key exchange parameters. For example, a Client might provide shares for multiple elliptic curves or for multiple FFDHE groups. The key_exchange value in each KeyShareEntry must be generated independently. A Client cannot provide multiple KeyShareEntry values for the same group. The Client cannot provide any KeyShareEntry values for groups not listed in the “supported_group” extension of the Client. The Server checks these rules and immediately sends an “illegal_parameter” alert message to abort the handshake if the rules are violated.
In HelloRetryRequest news, “key_share” extension of “extension_data” field contains KeyShareHelloRetryRequest values.
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
Copy the code- Selected_group: the group that the Server intends to negotiate for mutual support and is requesting to retry ClientHello/KeyShare.
After receiving this extension in the HelloRetryRequest message, the Client must verify two points. First, selected_groups must have appeared in “supported_groups” in the original ClientHello. Second, selected_group does not appear in “key_share” in the original ClientHello. If both checks fail, the Client must abort the handshake with an “illegal_parameter” alert message. Otherwise, when you send a new ClientHello, The Client must replace the original “key_share” extension with only the group indicated in the selected_group field that triggered the HelloRetryRequest, which contains only new KeyShareEntry.
In the ServerHello message, the “extension_data” field in the “KEY_share “extension contains the KeyShareServerHello value.
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
Copy the code- Server_share: single KeyShareEntry value shared with clients in the same group.
If the link is established using the (EC)DHE key, the Server provides only one KeyShareEntry in ServerHello. This value must be in the same group as the value selected by the Server from the KeyShareEntry value provided by the Client to negotiate the key exchange. The Server cannot send the KeyShareEntry value for any group specified in the “supported_groups” extension of the Client. Server also cannot send KeyShareEntry value when using “pSK_KE” PskKeyExchangeMode. If the link is established using (EC)DHE, the Client receives the HelloRetryRequest message contained in the “key_share” extension, The Client must verify that the NameGroup selected in ServerHello is the same as that selected in HelloRetryRequest. If they are different, the Client must immediately send an “illegal_parameter” alert message to abort the handshake.
(1) Diffie-Hellman Parameters
The Diffie-Hellman [DH76] parameter of the Client and Server is encoded in the OPAQUE key_exchange field in the KeyShare data structure of the KeyShareEntry. The opaque value contains the Diffie-Hellman public key (Y = g^X mod P) of the specified group, which is encoded as a big-endian integer. This value is p bytes in size, and if there are not enough bytes, add 0 to the left of it.
Note: For a given Diffie-Hellman group, populating results in all public keys having the same length.
The peer end must verify the public key of the other end to ensure that 1 < Y < P-1. This check ensures that the remote peer is working properly and that the local system does not force entry into smaller subgroups.
(2) ECDHE Parameters
ECDHE parameters of the Client and Server are encoded in the OPAQUE key_exchange field of the KeyShare data structure in KeyShareEntry.
For secP256R1, SECP384R1, and SECP521R1, the contents are the serialized values of the following structures:
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
Copy the codeX and Y are binary representations of the X and Y values in the network byte order, respectively. Since there is no internal length marker, each number occupies the 8-bit number of bytes implied by the curve parameter. For p-256, this means that each of the X and Y takes up 32 octets, with zeros padded to the left if needed. For P-384, they each occupy 48 octets, and for P-521, they each occupy 66 octets.
For secP256R1, SECP384R1, and SECP521R1, the peer end must verify the other end’s public key Q to ensure that this point is a valid point on the elliptic curve. Appropriate validation methods are defined in [ECDSA] or [KEYAGREEMENT]. This process involves three steps. Step 1: Verify that Q is not an infinite point (O). Second, verify that the two integers x, y in Q = (x, y) are correctly spaced. Third, verify that (x, y) is the correct solution to the elliptic curve equation. For these curves, the implementer no longer needs to verify the correct membership in the subgroup.
For X25519 and X448, the contents of the common values are the byte input and output of the corresponding function defined in [RFC7748], 32 bytes for X25519 and 56 bytes for X448.
Note: Prior to TLS 1.3, which allowed Point format negotiation, TLS 1.3 removed this feature in favor of a separate point format for each curve.
9. Pre-Shared Key Exchange Modes
To use PSK, the Client must also send a “pSK_KEY_exchange_MODES” extension. The extended semantics are that the Client only supports using PSKS with these patterns. This limits the use of the PSK provided in this ClientHello, as well as the PSK provided by the Server via newssession ticket.
If the Client provides the “pre_shareD_key” extension, it must also provide the “pSK_KEY_exchange_MODES” extension. If the Client sends “pre_shared_key” without the “pSK_KEY_exchange_MODES” extension, the Server must abort the handshake immediately. The Server cannot select a key exchange mode that is not listed by the Client. This extension also limits the modes used with PSK recovery. The Server also cannot send newssession tickets that are not compatible with the recommended modes. However, if the Server does this, the Client will fail when trying to resume the session.
Server cannot send “pSK_KEY_exchange_MODES” extension:
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1.255.>;
} PskKeyExchangeModes;
Copy the code-
Psk_ke: Only PSK keys are established. In this mode, the Server cannot provide a “key_share” value.
-
Psk_dhe_ke: PSK and (EC)DHE are established. In this mode, clients and servers must provide a “key_share” value.
Any future values assigned must ensure that the transmitted protocol messages clearly identify the mode selected by the Server. The value currently selected by the Server is represented by the “key_share” that exists in ServerHello.
10. Early Data Indication
When PSK is used and PSK allows early_data, the Client can send application data in its first message. If the Client chooses to do so, it must send the “pre_shared_key” and “early_data” extensions.
The “extension_data” field in the EarlyDataIndication extension contains an EarlyDataIndication value.
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
Copy the codeFor details about the use of the max_EARly_datA_size field, see the New Session Ticket Message section.
Parameters for 0-RTT data (version, symmetric encryption suite, application layer protocol negotiation protocol [RFC7301], etc.) are related to PSK parameters in use. For externally configured PSKS, the associated value is provided by the key. For a PSK established through a Newssession ticket message, the associated value is the value negotiated when the PSK connection is established. The PSK used to encrypt early Data must be the first PSK listed by the Client in the “pre_shareD_key” extension.
For PSK available through newssession ticket, The Server must verify the ticket age(subtract ticket_age_add from pskidentit.obfuscated_ticket_age 2^32 module) in the selected PSK id Is there a small tolerance for delivery time? If the time difference is large, the Server should continue to shake hands, but reject the 0-RTT, and assume that the ClientHello is new, and do nothing else.
0-RTT messages sent in the first flight have the same (encrypted) content type as messages of the same type sent in other flights (handshake and application data), but are protected by a different key. After receiving the Finished message from the Server, the Client sends an EndOfEarlyData message indicating the key change. The message will be encrypted using the 0-RTT traffic key.
The Server receiving the “early_data” extension must operate in one of three ways:
-
Ignore the “early_data” extension and return the regular 1-RTT response. The Server attempts to decrypt the received record by using the traffic key in the handshake and ignores the early data. Discards records that failed to decrypt (depending on max_early_data_size configured). Once a record has been decrypted, it is treated by the Server as the start of the Client’s second flight and treated as a normal 1-RTT.
-
Request the Client to send another ClientHello by responding to the HelloRetryRequest. Client cannot include the “early_data” extension in this ClientHello. The Server ignores early data(again, depending on the max_early_data_size configuration) by skipping all records with external content types “application_data”(indicating that they are encrypted).
-
Returns its own “early_data” extension in EncryptedExtensions, indicating that it is ready to process Early data. The Server cannot accept only a portion of the Early Data message. Even if the Server sends a message to receive Early Data, early Data may actually be in flight when the Server generates the message.
In order to accept early Data, the Server must have accepted the PSK cipher suite and selected the first key provided in the Client’s “pre_shareD_key” extension. In addition, the Server needs to verify that the following values are the same as the selected PSK association values:
- The TLS version number
- Selected cipher suite
- ALPN protocol selected, if selected
These requirements are the superset required to perform a 1-RTT handshake using the associated PSK. For externally established PSKS, the associated value is the value supplied with the key. For a PSK established with a Newssession ticket message, the associated value is the value negotiated in the connection during which the ticket is established.
Future extensions must define their interaction with 0-RTT.
If any checks fail, Server must not attach extensions to the response and must discard all first-flight data (thus falling back to 1-RTT or 2-RTT) using one of the first two mechanisms listed above. If the Client tries an 0-RTT handshake but the Server rejects it, the Server usually does not have a 0-RTT record protection key, Instead, the first non-0-RTT message must be found using trial decryption (using the 1-RTT handshake key or by looking up the plaintext ClientHello in the presence of the HelloRetryRequest message).
If the Server chooses to accept the earLY_data extension, when processing early Data records, the Server must comply with the same standard (specifying the same error handling requirements) for all records. Specifically, if the Server is unable to decrypt records in an already accepted “early_data” extension, it must send a” bad_record_mac” alert message to abort the handshake.
If the Server rejects the “early_data” extension, the Client application can choose to resend the application data previously sent in Early Data after the handshake is complete. Please note that automatic retransmission of Early Data can lead to misjudgments about connection status. For example, when a negotiated connection selects a different ALPN protocol from the one used for Early Data, the application may need to construct a different message. Similarly, if Early Data assumes that it contains anything about the state of the connection, it may incorrectly be sent after the handshake is complete.
TLS implementations should not automatically resend early Data; The application can make good decisions about when to retransmit. A TLS implementation must not automatically resend Early Data unless the negotiated connection selects the same ALPN protocol.
11. Pre-Shared Key Extension
The “pre_shareD_key” extension is used to negotiate the identity of the pre-shared key used for a given handshake associated with the PSK key.
The “extension_data” field in this extension contains a PreSharedKeyExtension value:
struct {
opaque identity<1.2.^16- 1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32.255.>;
struct {
PskIdentity identities<7.2.^16- 1>;
PskBinderEntry binders<33.2.^16- 1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
Copy the code-
Identity: key label. For example, a ticket or the label of an externally established pre-shared key.
-
Obfuscated_ticket_age: obfuscate version of the age of the key. This section describes how to generate this value for identities through newssession ticket message establishment. For the externally established identities, 0 obfuscated_ticket_age should be used, and the Server must also ignore this value.
-
Identities: Indicates the identities that clients are willing to negotiate with servers. If sent with “early_data”, the first identifier is used to identify 0-RTT.
-
Binders: A series of HMAC values. Corresponds to each value in the identities list in the same order.
-
Selected_identity: The identity selected by the Server and represented by the identity in the Client list as a zero-based index.
Each PSK is associated with a single hash algorithm. For the PSK established by ticket, when ticket is established in the connection, the KDF hash algorithm is used. For external PSKS, the hash algorithm must be set when the PSK is set. If not, the default algorithm is SHA-256. The Server must ensure that it selects a compatible PSK (if any) and key suite.
In versions prior to TLS 1.3, the Server Name Identification (SNI) value was intended to be associated with the session. The Server is forced to match the SNI value associated with the session with the SNI value specified in the recovery handshake. In fact, however, the SNI values provided by the implementer and the two they use are inconsistent, causing the Client to enforce consistency requirements. In TLS version 1.3, the SNI value is always explicitly indicated in the recovery handshake, and the Server does not need to associate the SNI value with the ticket. However, the Client needs to store SNI and PSK together to meet the requirements in section 4.6.1.
Implementers note: session recovery is the primary use of PSK, and the most straightforward way to achieve PSK/ key suite matching requirements is to negotiate the cipher suite first, and then exclude any incompatible PSKS. Any unknown PSKS (e.g., not in the PSK database, or encoded with an unknown key) must be ignored. If no acceptable PSK is found, the Server should perform a non-PSK handshake if possible. If backward compatibility is important, client-provided, externally built PSK should influence the choice of cipher suite.
Before accepting PSK key establishment, the Server must verify the corresponding binder values (see [Section 4.2.11.2]). If this value does not exist or is not validated, the Server must immediately abort the handshake. Instead of trying to validate multiple binders, the Server should select a single PSK and validate only the binder corresponding to that PSK. See Appendix E.6 and [Section 8.2] for a description of the security explanation for this requirement. To accept the PSK key to establish a connection, the Server sends the “pre_shared_key” extension, identifying the identity of its choice.
The Client must verify that the Server’s selected_identity is within the scope provided by the Client. The encryption suite selected by the Server identifies the hash algorithm associated with the PSK, and if ClientHello “pSK_KEY_exchange_MODES” is required, the Server should also send the “key_share” extension. If these values are inconsistent, the Client must immediately abort the handshake with an “illegal_parameter” alert message.
If the Server provides the “early_data” extension, the Client must verify that the Server’s selected_identity is 0. If any other value is returned, the Client must abort the handshake with the “illegal_parameter” alert message.
The “pre_shared_key” extension must be the last extension in ClientHello (this helps with the implementation described below). The Server must check that it is the last extension, or abort the handshake with an “illegal_parameter” alert message.
(1) Ticket Age
From the perspective of the Client, the ticket time refers to the period between the time when the newssession ticket message is received and the current time. The Client cannot use a ticket whose duration is longer than ticket_lifetime specified by the ticket. The “obfuscated_ticket_age” field in each PskIdentity must contain an obfuscate version of the ticket time by adding the “ticket_age_add” field to the ticket time (in milliseconds), And then finally, modulo 2^32. Unless the ticket is reused, this obfuscation prevents passive observers of some associated connection. Note that the “ticket_lifetime” field in the Newssession ticket message is in seconds, but the “obfuscated_ticket_age” field is in milliseconds. Because ticke Lifetime is limited to one week, 32 bits are sufficient to represent any reasonable time, even in milliseconds.
(2) PSK Binder
PSK Binder values form two binding relationships, one between the PSK and the current handshake, and the other between the handshake and the current handshake after the PSK is generated (if via newssession ticket messages). Every entry in the list of binder according to some ClientHello calculation HMAC hash copy, will eventually contain HMAC PreSharedKeyExtension. Identities fields. That is, HMAC contains all ClientHello, but no Binder List. If binders of the correct length exist, the length field of the message (including the total length, the length of the extension block, and the length of the “pre_shared_key” extension) is set.
PskBinderEntry is computed in the same way as the Finished message. But BaseKey is derived from binder_key by providing the corresponding PSK key.
If the handshake includes the HelloRetryRequest message, the original ClientHello and HelloRetryRequest are included in the copy along with the new ClientHello. For example, if a Client sends a ClientHello, its binder will calculate by:
Transcript-Hash(Truncate(ClientHello1))
Copy the codeThe Truncate() function removes the binders list from ClientHello.
If the Server responds to the HelloRetryRequest, the Client sends ClientHello2, which its binder calculates as follows:
Transcript-Hash(ClientHello1,
HelloRetryRequest,
Truncate(ClientHello2))
Copy the codeComplete ClientHello1 / ClientHello2 will be contained in other handshake in computing the hash. Note that on the first send, Truncate(ClientHello1) evaluates the hash directly, but on the second send, ClientHello1 evaluates the hash and injects a “message_hash” message.
(3) Processing Order
The Client is allowed to stream 0-RTT data until it receives the Finished message from the Server. After receiving the Finished message, the Client needs to send an EndOfEarlyData message at the end of the handshake. To prevent deadlocks, when a Server receives an “early_data” message, the Server must immediately process the Client’s ClientHello message and immediately respond to ServerHello, Instead of waiting for the EndOfEarlyData message from Client and then sending ServerHello.
3. Server Parameters
The Server’s next two messages, EncryptedExtensions and CertificateRequest messages, contain the message from the Server that determines the rest of the handshake. These messages are encrypted with a key derived from server_handshake_traffic_secret.
1. Encrypted Extensions
In all handshakes, the Server must send the EncryptedExtensions message immediately after the ServerHello message. This is the first message encrypted under the key derived from server_handshake_traffic_secret.
The EncryptedExtensions message contains extensions that should be protected. That is, any extension that does not require an encryption context to be established but is not associated with individual certificates. The Client must check for any prohibited extensions in the EncryptedExtensions message, and if any prohibited extensions are found, it must immediately abort the handshake with an “Illegal_parameter” alert message.
Structure of this message:
struct {
Extension extensions<0.2.^16- 1>;
} EncryptedExtensions;
Copy the code- Extensions: List of extensions.
2. Certificate Request
The Server that uses the certificate for authentication can optionally request a certificate to the Client. The request message (if sent) follows the EncryptedExtensions message.
Structure of a message:
struct {
opaque certificate_request_context<0.2.^8- 1>;
Extension extensions<2.2.^16- 1>;
} CertificateRequest;
Copy the code-
Certificate_request_context: An opaque string that identifies the Certificate request and is displayed in the Certificate message from the Client. Certificate_request_context must be unique in this connection (to prevent Client’s CertificateVerify replay attack). This field is typically 0 length, except for the post-handshake authentication exchange described in [4.6.2]. When requesting handshake authentication, the Server should send an unpredictable context to the Client (for example, generated with random numbers) to prevent attackers from cracking it. An attacker can obtain temporary Client private key permissions by pre-calculating valid CertificateVerify messages.
-
Extensions: A set of parameter extensions required to describe the certificate being requested. Signature_algorithms “extensions must be specific. If other extensions are defined by this message, then other extensions may optionally be included. Clients must ignore unrecognized extensions.
In versions prior to TLS 1.3, the CertificateRequest message carried a list of signing algorithms and a list of certificate authorizations acceptable to the Server. In TLS 1.3, the list of signature algorithms can be represented with “signature_algorithms” and the optional “signature_algorithms_cert” extension. The latter certificate authorization list can be represented by sending the “Certificate_authorities” extension.
Servers authenticated by PSK cannot send A CertificateRequest message in the main handshake, although they may be able to send a CertificateRequest message in the post-handshake authentication, This assumes that the Client has already sent the extension “post_handshake_auth”.
Reference:
RFC 8446
Making Repo: Halfrost – Field
Follow: halfrost dead simple
Source: halfrost.com/TLS_1.3_Han…