SSL/TLS Security Series: SSL/TLS Overview

SSL/TLS Security Series: SSL/TLS Overview
1. 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.

3.2 handshake process corresponding to different key exchange algorithms

Different key exchange algorithms correspond to different message sequences in the handshake process, and their implementation methods are also different. This section describes the handshake process corresponding to several common key exchange algorithms.

TLS-RSA: In this scenario, PreMasterSecret is specified by the client and is encrypted and sent to the server using the RSA public key. The server does not affect the generation of PReMasterSecret.

TLS-DH: DH-based Key Exchange is also known as static Diffie-Hellman. In this scenario, either party submits a certificate containing the DH public value, or the server submits a certificate containing the DH public value. The client selects a value for each session. The negotiated DH value is used as PreMasterSecret. Obviously, the parameters in the certificate are fixed, so the PreMasterSecret of each link is the same.

TLS-DH cannot provide forward security.

TLS-DHE: There is a ServerKeyExchange message in the DHE-based TLS handshake. The exchange parameter authentication is implemented through digital signatures during handshaking. supported signature algorithms include RSA and DSS. The DH parameter will contain its digital signature and be sent out in ServerKeyExchange. The client returns its public DH parameter in ClientKeyExchange without signature protection. The negotiated DH key is used as PreMasterSecret.

3.3 Key Generation

Pseudo-random Function (PRF): a Pseudo-random Function is an important component of the SSL protocol. It is used to secretly expand and generate keys. PRF has been briefly mentioned in the Finished message in section 3.1. Here we will discuss in detail how PRF works. Shows the PRF in the SSL/TLS protocol:

This PRF is based on two hash functions: MD5 and SHA-1. It has three inputs, one Secret (for example, PreMasterSecret) and one identifier (for example, "client finished" and "server finished "), there is also a seed value (such as a random number on the client + a random number on the server ).

Secret is divided into the same length of two half: S1 and S2, respectively as P_MD5 and P_SHA-1 input.

The PRF output is processed as follows:

PRF( secret , label , seed ) = P_MD5( S1 , label + seed ) XOR P_SHA−1(S2 , label + seed ) ;

P_MD5 and P_SHA-1 are extension functions used to extend the secret value for key generation, their calculation method is as follows:

P hash ( secret , seed ) = HMAC hash(secret , A( 1 ) + seed ) +HMAC hash(secret , A( 2 ) + seed ) +HMAC hash(secret , A( 3 ) + seed ) + . . .

Where A (0) = seed, A (I) = HMAC hash (secret, A (I −1 ))

 

This secret extension will continue until you get enough extended data. Key Derivation: the master Key (MasterSecret) is generated from the pre-master Key (PreMasterSecret) using the PRF. Each MasterSecret is 48 bytes. The generation method is as follows:

mastersecret = PRF( pre mastersecret , ” mastersecret ” , ClientHello.random + ServerHello.random) 

After MasterSecret is obtained, it is further processed to generate four different keys and two initial vectors (IV ). The process is as follows:

keyblock = PRF( SecurityParameters.mastersecret , ”key expansion ” , SecurityParameters.server random +SecurityParameters.client random ) ; 

The processing process continues until enough output is generated, and then the output is divided into four keys and two IV:

client_write_MAC_secret，server_write_MAC_secret, client_wriete_key, server_write_key, client_write_IV, server_write_IV.

Describes the Key Generation Process in SSL/TLS.

From SSL to TLS

This section describes the version changes of the SSL/TLS protocol, differences between different versions, and security features.

SSL 1.0 has never been disclosed and has serious security vulnerabilities, so we will not discuss it.

SSL 2.0: SSL 2.0 was released in April 1995. The main problems in SSL 2.0 are as follows:

MAC cannot overwrite the padding length domain, which attackers may exploit to undermine message integrity;

Without handshake authentication, attackers can tamper with the list of cipher suites to trick communication parties into using weak cipher suites;

Use Weak or problematic cryptographic algorithms (such as MD5 and RC4) or insecure grouping modes (such as CBC );

Using the same key for different cryptographic elements violates basic security knowledge.

Due to the above security issues, RFC 6176 has explicitly proposed to avoid using SSL 2.0, but in real life there are a small number of clients and servers supporting SSL 2.0.

SSL 3.0: SSL 3.0 introduces some new features and mechanisms to solve many vulnerabilities in earlier versions. In addition, the ChangeCipherSpec sub-protocol is introduced in SSL 3.0. SSL 3.0 is backward compatible with SSL 2.0. Compared with SSL 2.0, the main changes include the following:

Supports more cipher suites (supports more cryptographic algorithms such as DSS and SHA-1)

Supports key negotiation (DH and FORTEZZA) in the handshake phase)

Supports password parameter re-negotiation

Added message compression options.

MAC can overwrite the fill length domain, while MAC can use MD5 or SHA-1

Different cryptographic elements use different keys

The Alert sub-Protocol provides two types of prompts for any errors: Warning and Fatal.

When the link is terminated, A close_policy warning will be sent to both parties.

Supports certificate chains instead of individual certificates

Use Finished to authenticate all sent and received messages

The encrypted PreMasterSecret contains the current Protocol version to prevent protocol rollback.

TLS 1.0: The difference between TLS 1.0 and SSL 3.0 is very small. In fact, TLS 1.0 is SSL 3.1, which is changed to TLS after the IETF takes over. TLS 1.0 is the most widely used SSL/TLS Protocol version.

TLS 1.0 no longer supports FORTEZZA cipher suite.

In TLS 1.0, the MAC is replaced with HMAC.

As mentioned earlier, ChangeCipherSpec messages must be sent before Finished messages. In TLS 1.0, if the message sequence does not meet this requirement, a FATAL warning is generated and the link is terminated.

TLS 1.1: This version is slightly changed compared to the previous version. The most important change is to prevent attacks against the CBC group mode. The current padding error changes cannot be distinguished from the invalid MAC error, preventing attackers from attacking the ciphertext by using a differentiated Error Response to establish a decryption oracle.

In each encryption process, when using the CBC group mode, the IV is displayed, instead of using PRF to generate the IV when the key is generated.

Additionally, TLS 1.1 prohibits the use of weakened cipher suites to adapt to previous exit restrictions.

TLS 1.2: this is the latest version and is rarely deployed. This version disables MD5 and SHA-1 in PRF, and replaces them with a configurable hash function, which simplifies the calculation process. The modified PRF style is as follows:

In addition, an important change in TLS 1.2 is that it supports the Authentication Encryption mode (supports GCM and so on ). However, because some AEAD (Authenticated Encryption with Associated Data) cryptographic algorithms require IV to be implicit, IV is restored to the style previously generated by MasterSecret, that is, TLS 1.0.

TLS 1.2 supports the use of GCM and CCM new cipher suites.

At the same time, SSL 2.0 is declared to be abandoned and is no longer backward compatible with SSL 2.0.

Popular implementations of SSL/TLS

This section briefly introduces the popular SSL/TLS implementation libraries. the SSL protocol is very complex and developers often encounter errors when implementing their own implementations. Developers often rely on these cryptographic libraries when implementing the SSL protocol.

5.1 common SSL/TLS implementations

OpenSSL: This is a popular open-source SSL/TLS implementation.

OpenSSLim is fully implemented in C language and supports SSL 2.0/3.0, TLS 1.0/1.1/1.2, and DTLS 1.0.

OpenSSL has encountered many security vulnerabilities in recent years, such as the well-known Heartbleed vulnerability discovered in 2014.

JSSE: this is implemented in Java and supports SSL 3.0, TLS 1.0/1.1/1.2.

Bouncy Castle: it not only supports SSL/TLS, but also is a complete cryptographic library that supports various cryptographic algorithms and protocols. However, it only supports TLS 1.0.

The Android platform mainly uses this cryptographic library.

GnuTLS: This is another library implemented in C language. It supports SSL 3.0, TLS 1.0/1.1/1.2, and DTLS 1.0. It is mainly used in the Unix world. It is also known for its wide variety of security vulnerabilities.

 

NSS: A library originally developed by Netscape. It supports SSL 2.0/3.0, TLS 1.0/1.1, and is mainly used by browsers and client software, for example, Firefox uses the NSS library and Chrome uses the modified version of the NSS library.

 

The following table shows some common software and the SSL/TLS implementation libraries they use:

There are also some common SSL implementation libraries, such as cryptlib, CyaSSL, MatrixSSL, and PolarSSL. Due to the low market share, we will not discuss them here.

5.2 popular SSL/TLS library security research

The high-risk SSL Security Vulnerabilities exposed in recent years are mostly related to the SSL implementation library. For example, the heartbleed vulnerability discovered in April 2014 exists in OpenSSL 1.0.1-1.0.1f, it affects nearly 17% of Web servers around the world. It is also the "gotofail" vulnerability in the iOS 7.0.6 system exposed in 2014. due to the negligence of programmers, signature verification in SSL certificate verification fails; this year, the SSL Freak attack was also caused by the Security Vulnerability of the SSL implementation library. Our team analyzed the attack in detail. For details, see "SSL Freak Attack: how to implement a specific SSL Freak attack. At the same time, we also developed a python-based man-in-the-middle proxy attack framework "wind" to launch a specific attack on a well-known e-commerce server in China, and reported the vulnerability.

Considering the security issues in a large number of SSL/TLS implementation libraries, these mainstream SSL/TLS implementation libraries are difficult for developers to use, for example, some SSL/TLS implementation libraries require developers to generate random numbers or manage keys themselves, so that developers who lack system information security knowledge training can use such highly complex cryptographic libraries, which may cause many security problems. We recommend some advanced cryptographic libraries: Google keycazer, NaCl, Cryptlib, and GPGME. These cryptographic inventory has fewer security issues and encapsulates some underlying cryptographic operations, reducing the difficulty of developers.