1. Purpose of TLS protocol
The primary goal of TLS is to provide a secure channel for both parties to communicate. The only requirement for the underlying transmission is a reliable and ordered data stream.
-
Authentication: The Server side of the channel should always be authenticated; The Client is optional to be authenticated. Authentication can be done by asymmetric algorithms (for example, RSA, elliptic Curve Digital Signature Algorithm (ECDSA), or Edwards Curve Digital signature Algorithm (EdDSA)), or by a symmetric pre-shared key (PSK).
-
Confidentiality: Data sent over the established channel is visible only to the terminal. The TLS protocol does not hide the length of the data it transmits, but terminals can hide the length by filling TLS records to improve protection against traffic analysis techniques.
-
Integrity: it is impossible to send data over established channels without data tampering being detected. That is, once data is modified, the peer end immediately detects the modification.
The above three points must be guaranteed, even if the attacker has fully mastered the network, as happened in RFC 3552. There is a separate article devoted to TLS security.
2. TLS protocol composition
The TLS protocol is mainly composed of two components:
-
Handshake protocol The handshake protocol deals with all the authentication processes between communication parties. Including key negotiation, parameter negotiation, and establishment of shared keys. Handshake protocols are designed to resist tampering; If the connection is not attacked, an active attacker should not force the peer to negotiate different parameters.
-
The recording protocol uses parameters established by the handshake protocol to protect the traffic between the communicating parties. Recording protocols divide traffic into a series of records, each of which independently uses a key to protect confidentiality.
TLS is a separate protocol; High-level protocols can transparently override TLS. However, the TLS standard does not specify how the protocol enhances TLS security, how to initiate a TLS handshake, and how to understand authentication certificate exchange, leaving it to the designers and implementers of protocols running on TOP of TLS.
This document defines TLS version 1.3. Although TLS 1.3 is not directly compatible with previous versions, all versions of TLS include a version control mechanism that allows clients and servers to negotiate which version of TLS to use during communication.
TLS 1.3 replaces and repeals previous versions of TLS, including RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2. Rescinded TLS Ticket mechanism defined in RFC5077 Transport Layer Security (TLS) Session Transnistria without Server-Side State Replace it with a pre-shared Key (PSK) mechanism. RFC5705 Keying Material Exporters for Transport Layer Security (TLS) is updated as TLS 1.3 changes the way keys are exported. It also changed the online certificate status protocol (OCSP) message transmission mode, therefore RFC6066 https://tools.ietf.org/html/rfc6066 are updated. RFC6961 He Transport Layer Security (TLS) Multiple Certificate Status Request Extension As described in the OCSP Status and SCT Extensions section.
3, TLS 1.3 and TLS 1.2 are different
The main differences between TLS 1.2 and TLS 1.3 are described below. Beyond these major differences, there are many subtle ones.
-
The list of supported symmetric algorithms has been stripped of algorithms that are no longer safe. The list preserves all algorithms that use authentication encryption with Associated Data (AEAD). The cryptosuite concept has been changed to separate record protection algorithms (including key length) and a hash and HMAC for key generation functions into authentication and key exchange mechanisms.
-
A 0-RTT mode was added to save some application data a round trip during connection establishment at the expense of certain security features. The security of 0-RTT will be specifically discussed below.
-
Static RSA and Diffie-Hellman cipher suites have been deleted. All public-key-based key exchange algorithms can now provide forward security.
-
All handshake messages after ServerHello are now encrypted. The newly introduced EncryptedExtension messages allow the same confidentiality for various extensions that were previously sent in clear text in ServerHello.
-
The key export function has been redesigned. The new design allows cryptographers to perform easier analysis with improved key separation features. Hmac-based extraction -and-Expand Key Derivation Function (HKDF) is used as a basic primitive component (Primitive).
-
The handshake state machine has been significantly tweaked for greater consistency, removing redundant messages such as ChangeCipherSpec (except when required due to middleware compatibility).
-
Elliptic curve algorithm already belongs to the basic specification, and includes new signature algorithm, such as EdDSA. TLS 1.3 removes point format negotiation in favor of using a single point format for each curve.
-
Other cryptographic improvements include changing RSA padding to use the RSA probabilistic signature scheme (RSASSA-PSS), removing compression, DSA, and customizing THE DHE group.
-
The version negotiation mechanism of TLS1.2 is disabled. Support the use of version lists in extensions. This increases compatibility with servers that incorrectly implement version negotiation.
-
Session recovery with and without Server state and the PSK based cipher suite of earlier versions of TLS have been replaced by a separate new PSK exchange.
-
Update references to the latest version of RFC as appropriate (for example, RFC 5280 instead of RFC 3280).
4. Improvements affecting TLS 1.2
The TLS 1.3 specification also defines a number of alternative implementations for TLS 1.2, including those that do not support TLS 1.3.
- Version degradation protection mechanism defined in TLS 1.3
- RSASSA-PSS signature scheme
- The “supported_versions” extension in ClientHello can be used to negotiate the version of TLS to be used, which takes precedence over the Legacy_version field in ClientHello.
- The “signature_algorithms_cert” extension allows a Client to show which signature algorithm it uses to validate X.509 certificates.
5. TLS 1.3 Protocol Overview
The password parameters used by the secure channel are generated by the TLS handshake protocol. The handshake protocol, a subprotocol of TLS, is used when the Client and Server communicate for the first time. The handshake protocol allows both ends to negotiate a protocol version, select a password algorithm, selectively authenticate each other, and establish shared key data. Once the handshake is complete, the two parties use the established key to protect application layer data.
A failed handshake or other Protocol error triggers the termination of the connection, before which an Alert message can be selectively sent, following the Alert Protocol.
TLS 1.3 supports three basic key exchange modes:
- (EC)DHE (Diffie-Hellman based on Finite fields or elliptic curves)
- PSK – only
- PSK with (EC)DHE
The following figure shows the entire TLS handshake process:
Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data]Copy the code+ represents noteworthy extensions sent in previously annotated messages * represents optional or conditional messages/extensions, They do not always send () indicating that the message is protected by a key exported from Client_early_traffic_secret {} indicating that the message is protected by a key exported from a [sender]_handshake_traffic_secret [] indicating that the message is protected by a key exported from Client_early_traffic_secret [sender]_application_traffic_secret_N Exported key protection
A handshake can be thought of as having three stages (see picture above) :
- Key exchange: Establishes shared key data and selects password parameters. After this stage all data is encrypted.
- Server parameters: Establishes other handshake parameters (whether the Client is authenticated, application layer protocol support, etc.).
- Authentication: Authenticates the Server (and optionally authenticates the Client), providing key confirmation and handshake integrity.
In the key exchange phase, the Client sends a ClientHello message, which contains a random Nonce (Clienthell.random). It provides protocol versions, a list of symmetric password /HKDF hash pairs; A Diffie-Hellman key shared collection or a pre-shared key tag (in the “key_share” extension) collection, or both; And possibly other extensions.
The Server processes ClientHello and determines the appropriate password parameters for the connection. It then responds with its own ServerHello, which indicates the negotiated connection parameters. ClientHello and ServerHello are combined to determine the shared key. If an established (EC)DHE key is being used, ServerHello contains a “key_share” extension, along with the Server’s temporary Diffie-Hellman share parameter, The shared parameter must be in the same group as one of the Client’s shared parameters. If the PSK key is used, ServerHello contains a “pre_shared_key” extension to indicate which PSK provided by the Client is selected. Note that implementations can use (EC)DHE and PSK together, in which case both extensions need to be provided.
The Server then sends two messages to establish the Server parameters:
- EncryptedExtensions: Response to the ClientHello extension that does not require the determination of encryption parameters other than those specific to individual certificates.
- CertificateRequest: If certificate-based client authentication is required, the required parameter is the certificate. If client authentication is not required, omit this message.
Finally, the Client and Server exchange authentication messages. TLS uses the same message set for each certificate-based authentication (PSK based authentication is a side effect in key exchange) in particular:
-
Certificate: The terminal’s Certificate and an extension of each Certificate. The client ignores this message if the server does not authenticate with a certificate and if the server does not send a CertificateRequest (thus indicating that the client should not use certificates for authentication). Note that if you use the original public key [RFC7250] or the cache information extension [RFC7924], this message will not contain the certificate, but other values corresponding to the server’s long-term key.
-
CertificateVerify: Signs the entire handshake message using the private key paired with the public key in the certificate message. This message is ignored if the terminal does not use a certificate for authentication.
-
Finished: Indicates the MAC address (message authentication code) for the entire handshake messages. This message provides key confirmation, binding the terminal identity to the exchanged key so that the handshake can also be authenticated in PSK mode.
After receiving the message from the Server, the Client responds with Certificate, CertificateVerify (if required), and Finished.
After the handshake is complete, the client and server extract the key for recording layer exchange application layer data, which needs to be protected by authentication encryption. Data at the application layer cannot be sent before the Finished message and can be sent only after the recording layer uses the encryption key. Note that the server can send application data before receiving the authentication message from the client. Any data sent at this point in time is sent to an unauthenticated peer.
1. Wrong DHE sharing
If the client does not provide an adequate “key_share” extension (for example, it contains only DHE or ECDHE groups that are not accepted or supported by the server), the server uses a HelloRetryRequest to correct the mismatch, The client needs to restart the handshake using an appropriate “key_share” extension, as shown below. If there are no common password parameters to negotiate, the server must issue an appropriate alert to abort the handshake.
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Copy the codeAs shown above, a message flow with a complete handshake with mismatched parameters
Note that the handshake process contains the initial ClientHello/HelloRetryRequest exchange; It cannot be reset by the new ClientHello.
TLS also allows several optimized variants of the basic handshake, as described in the following section.
2. Reuse and pre-shared Key (PSK)
Although TLS pre-shared keys (PSK) can be established out of band, pre-shared keys can also be established in a previous connection and reused (session recovery). Once a handshake is complete, the server can send the client a PSK key corresponding to a unique key from the initial handshake. The client can then use this PSK key to negotiate the use of the associated PSK in future handshakes. If the server accepts it, the security context of the new connection is cryptographically associated with the original connection, and the key obtained from the initial handshake is used to load the password state instead of the full handshake. In TLS 1.2 and later, this functionality is provided by “Session IDs” and” Session Tickets “[RFC5077]. Both mechanisms were abolished in TLS 1.3.
PSK can be used in conjunction with the (EC)DHE key exchange algorithm to make shared keys forward-secure, or PSK can be used alone at the expense of forward-secure application data.
The following figure shows two handshakes, the first to establish a PSK and the second to use it:
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Copy the codeWhen a server is authenticated by a PSK, it does not send a Certificate or a CertificateVerify message. When a client wants to resume a session via PSK, it should also provide a “key_share” to the server to allow the server to demote to a full handshake if it refuses to resume the session. The Server responds to the “pre_shareD_key” extension, establishes connections using PSK key negotiation, and responds to the “key_share” extension for (EC)DHE key establishment, thereby providing forward security.
When the PKS is provided out of band, the PSK key and the KDF Hash algorithm used with the PSK must also be provided.
Note: When using a pre-shared key provided out of band, a key consideration is to use sufficient entropy in key generation, as discussed in [RFC4086]. A shared key exported from a password or other low entropy source is not secure. A low entropy password, or password, is vulnerable to PSK binder-based dictionary attacks. The PSK key specified is not an authenticated key exchange based on a strong password, even if the Diffie-Hellman key establishment method is used. Specifically, it does not prevent an attacker who can observe the handshake from violently attacking the password/pre-shared key.
3. 0 – RTT data
When client and server share a PSK (obtained externally or through a previous handshake), TLS 1.3 allows the client to carry data (“early data”) in the first message sent out. The Client uses this PSK to authenticate the server and encrypt Early Data.
As shown in the figure below, 0-RTT data is added to the 1-RTT handshake in the first message sent. The rest of the handshake message is the same as the 1-RTT handshake message with PSK session recovery.
Client Server
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
Copy the codeThe figure above shows the 0-RTT information flow
+ notable extensions that indicate they were sent in a previously tagged message * indicates optional or conditional messages/extensions, They do not always send () to indicate that the message is protected by a key exported from client_early_TRAFFic_secret {} to indicate that the message is protected by a key exported from a [sender]_handshake_traffic_secret [] indicates that the message is protected with the key exported from [sender]_application_traffic_secret_N
0-RTT arrays are less secure than other types of TLS data, in particular:
- 0-RTT data has no forward security and is encrypted using the exported key from the supplied PSK.
- There is no guarantee that replay attacks will not occur between multiple connections. Normal TLS 1.3 1-RTT data is protected against replay attacks by using random numbers sent by the server. Now 0-RTT does not depend on ServerHello messages, so the protection is worse. This is especially important if the data is authenticated with TLS Client or with the application protocol. This warning applies to any use of early_exporter_master_secret.
0-RTT data cannot be replicated in a connection (that is, the server will not process the same data twice for the same connection), and an attacker will not be able to make 0-RTT data look like 1-RTT data (because it is protected by a different key).
Security of 0-RTT will be discussed in a separate article.
Reference:
RFC 8446
Making Repo: Halfrost – Field
Follow: halfrost dead simple
Source: github.com/halfrost/Ha…