Popular SSL/TLS protocols: in-depth interpretation of SSL/TLS implementation (1)

Popular SSL/TLS protocols: in-depth interpretation of SSL/TLS implementation (1)

Preface

The SSL/TLS protocol is an important cornerstone of secure network communication. This series will briefly introduce the SSL/TLS Protocol, focusing on the security of the SSL/TLS Protocol, especially the correct implementation of the SSL specification. The articles in this series are divided into three parts:

Basic SSL/TLS Protocol process

Typical attacks against SSL/TLS protocols

Security reinforcement measures for SSL/TLS protocols

This article gives a basic introduction to the SSL/TLS protocol, including the version change of the SSL/TLS protocol, the detailed process of the Protocol, and the popular Implementation of the SSL/TLS protocol. This article is translated from the Article 20 Years of SSL/TLS Research An Analysis of the Internet's Security Foundation, at the same time, some content is added based on the author's own understanding to make the introduction of the SSL/TLS Protocol more complete.

What is SSL/TLS?

The full name of SSL is Secure Sockets Layer, which is a Secure Socket Layer designed by Netscape, the purpose is to ensure the confidentiality, authentication and data integrity of network communication. Nowadays, SSL has become an industrial standard for secure Internet communication.

The original SSL versions (SSL 1.0, SSL2.0, and SSL 3.0) were designed and maintained by Netscape. Starting from version 3.1, the SSL protocol was officially taken over by the Internet Engineering Task Team (IETF, and changed its name to Transport Layer Security (TLS). Since its development, TLS 1.0, TLS1.1, and TLS1.2 are available.

As mentioned in the TLS name, the SSL/TLS Protocol only ensures the security of the transport layer. At the same time, due to the characteristics of the Protocol (digital certificate mechanism), SSL/TLS cannot be used to protect multi-hop end-to-end communication, but can only protect point-to-point communication.

The SSL/TLS Protocol provides the following security goals:

Authentication-use digital certificates to authenticate the identity of the server and client to prevent identity forgery

Confidentiality-prevent third-party eavesdropping with encryption

Integrity-use the message authentication code (MAC) to ensure data integrity and prevent message tampering

Replay protection-Protection against replay attacks by Using implicit serial numbers

To achieve these security goals, the SSL/TLS protocol is designed as a two-phase protocol, divided into the handshake phase and application phase:

The handshake stage is also called the negotiation stage. At this stage, the client and the server will authenticate the identity of the other party (depending on the PKI system and use digital certificates for Identity Authentication ), negotiate the security parameters, cipher suite, and MasterSecret used in communication. All keys used for subsequent communications are generated through MasterSecret.

After the handshake stage is complete, the application stage is started. In the application phase, both parties use the key negotiated during the handshake phase for secure communication.

The SSL/TLS Protocol has a highly modular architecture and is divided into many sub-protocols, as shown in:

Handshake protocol: includes negotiation security parameters and cipher suites, server identity authentication (optional for client identity authentication), and key exchange;

ChangeCipherSpec Protocol: a message indicates that the handshake protocol has been completed;

Alert Protocol: for some abnormal Error alerts in the handshake protocol, there are two levels: fatal and warning. fatal errors directly interrupt the SSL link, the error SSL link at the warning level can continue, but an error warning will be given;

Record Protocol: includes message segmentation, compression, message authentication, integrity protection, encryption, and so on.

Three Protocol process details

This section describes the SSL/TLS Protocol process in detail. Shows a typical TLS 1.0 protocol interaction process:

Each SSL/TLS link starts from a handshake. The handshake contains a message sequence used to negotiate security parameters and cipher suites for identity authentication and key exchange. Messages in the handshake must occur in the predefined order. Otherwise, a potential security threat may occur. This year's top security conference, CCS, has put forward the establishment of a comprehensive state machine to check the message sequence in the SSL link ......

3.1 message sequence during handshake

ClientHello: ClientHello is usually the first message in the handshake process, used to inform the Server client of the Supported Cipher Suite type, the maximum SSL/TLS Protocol version, and the compression algorithm.

ClientHello also contains a random number, which consists of 4 bytes of the current gmt unix time and 28 randomly selected bytes, 32 bytes in total. The random number is used during key generation.

ClientHello may also contain TLS extensions supported by clients. (TLS extensions can be used to enrich the functions of the TLS protocol or enhance the security of the Protocol)

ServerHello: After the server receives ClientHello, it returns ServerHello. The server selects the supported items from the cryptographic suite, SSL/TLS version, and compression algorithm list provided by the client in ClientHello, and includes the options in ServerHello to inform the client. Next, the establishment of the SSL protocol is based on the password suite type selected by the server, the SSL/TLS Protocol version, and the compression algorithm.

ServerHello also contains a random number of 4 + 28 bytes, which is generated by the server.

Certificate: both the client and the server can send a Certificate message to prove their identity, but the client Certificate is usually not used. Generally, the server receives a Certificate message after ServerHello. The Certificate message contains a Certificate chain, starting from the server Certificate to the Certificate authority (CA) or the latest self-signed Certificate. Vividly describes the certificate chain:

Certificates used in SSL are generally X.509 certificates. The content of X.509 certificates is shown in the following table:

The X.509 certificate used includes Version 1 and Version 3. The v1 certificate has security risks and does not support TLS extension and is gradually discarded. Currently, most SSL certificates are in V3.

At the same time, the certificate will contain the key corresponding to the negotiated key exchange algorithm. The following table lists the key exchange algorithms and their required key types.

ServerKeyExchange: This message is sent by the server only when the following key exchange algorithms are used:

RSA_EXPORT (only when the server's public key is greater than 512bit), DHE_DSS, DHE_DSS_EXPORT, DHE_RSA, DHE_RSA_EXPORT, and DH_anon use other key exchange algorithms, the server cannot send this message.

ServerkeyExchange messages carry the additional parameters required by these key exchange algorithms to negotiate PreMasterSecret in subsequent steps. These parameters must be signed.

CertificateRequest: this message is usually required to authenticate the client identity. The message contains a list of certificate types and acceptable CAS.

ServerHelloDone: the server sends this message, indicating that the key exchange information of the server has been sent. Wait for the client message to continue the next step. This message is only used as a reminder and does not contain data domains.

ClientKeyExchange: the data contained in this message is related to the selected key exchange algorithm.

If the selected key exchange algorithm is RSA, the message contains the parameter PreMasterSecret encrypted with the server RSA public key (included in the previous certificate or in ServerKeyExchange), which contains 48 bytes, the first two bytes indicate the maximum Protocol version supported by the client, and the last 46 bytes are randomly selected.

If the selected key exchange algorithm is DH or DHE, there may be two situations:

Implicit DH public value: Included in the Certificate message;

Display DH public value: the public value is part of the message.

CertificateVerify: this message is used to prove that the client has the private key of the client certificate submitted previously.

Finished: indicates that the handshake stage is over. This is the first message to be protected by a negotiated algorithm and key.

Because a message is encrypted with a negotiated key, it can be used to confirm the negotiated key.

At the same time, the Finished message contains a verify_data domain, which can be used to verify the information sent and received before.

The Verify_data field is the output of a PRF function (pseudo-random function ). The input of this pseudo-random function is: (1) Two hash values: One SHA-1 and one MD5, hash all the messages exchanged during the previous handshake; (2) the MasterSecret, generated by the master key; (3) finished_label. If the client sends "client finished", the server sends "server finished ". Details about this PRF are described in section 3.3. In addition, Finished messages cannot be sent before ChangeCipherSpec.