2.9. SSL/TLS

2.9.1. Introduction

The full name of SSL is Secure Sockets Layer. It was designed by Netscape in 1994 and is mainly used as a secure transmission protocol for the Web. The purpose is to provide confidentiality, authentication and data for network communication. Integrity Guarantee. Today, SSL has become the industry standard for secure communications over the Internet.

The first several versions of SSL (SSL 1.0, SSL2.0, 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 Force (IETF) and renamed TLS (Transport Layer). Security), there are several versions of TLS 1.0, TLS1.1, TLS1.2, TLS1.3.

As the name of TLS says, the SSL/TLS protocol only guarantees transport layer security. At the same time, due to the characteristics of the protocol itself (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 security goals that the SSL/TLS protocol can provide mainly include the following:

  • Authentication

    • Use digital certificates to authenticate server and client identities to prevent identity forgery

  • confidentiality

    • Protection against third-party eavesdropping with encryption

  • integrity

    • Ensure data integrity and prevent message tampering with Message Authentication Code (MAC)

  • replay protection

    • Prevent replay attacks by using implicit sequence numbers

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

The handshake phase is also called the negotiation phase. In this phase, the client and the server will authenticate each other’s identities (depending on the PKI system, using digital certificates for identity authentication), and negotiate security parameters, cipher suites and MasterSecrets used in communication. All keys used for subsequent communications are generated via the MasterSecret. After the handshake phase is completed, the application phase is entered. In the application phase, both parties use the negotiated key in the handshake phase for secure communication.

2.9.2. Protocol

TLS contains several sub-protocols, the more commonly used are record protocol, alert protocol, handshake protocol, change cipher specification protocol, etc.

2.9.2.1. Recording Protocol

The Record Protocol specifies the basic unit record (record) of data sent and received by TLS.

2.9.2.2. Alert Protocol

The Alert Protocol is used to prompt an error in the protocol interaction process.

2.9.2.3. Handshake Protocol

The Handshake Protocol is the most complex sub-protocol in TLS. During the handshake process, the TLS version number, random number, cipher suite and other information are negotiated, and then the certificate and key parameters are exchanged. Finally, the two parties negotiate to obtain the session key, which is used for Subsequent hybrid encryption systems.

2.9.2.4. Changing the Cipher Specification Protocol

The Change Cipher Spec Protocol is a “notification” that tells the other party that subsequent data will be protected with encryption.

2.9.3. Interactive process

2.9.3.1. Client Hello

Client Hello is sent by the client, including a Unix timestamp (GMT Unix Time) of the client, some random bytes (Random Bytes), and the type of algorithm accepted by the client (Cipher Suites).

2.9.3.2. Server Hello

Server Hello is sent by the server, and the content includes the algorithm type supported by the server, GMT Unix Time and Random Bytes.

2.9.3.3. Certificate

Server Hello is sent by the server, and the content includes the algorithm type supported by the server, GMT Unix Time and Random Bytes.

2.9.3.4. Server Key Exchange

Sent by the server or client, the sender will send its digital certificate to the receiver, and the receiver will verify the certificate. If it fails, the receiver will interrupt the handshake process. It usually follows the Client/Server Hello message.

2.9.3.5. Server Hello Done

It is sent by the server and transmits its own public key parameters to the client, generally in a TCP packet with Server Hello and Certificate.

2.9.3.6. Client Key Exchange

The server sends it, usually in a TCP packet with Server Hello, Certificate and Server Key Exchange.

2.9.3.7. Change Cipher Spec

The client or server sends it, followed by the Key Exchange, which means that it has generated a new key, and informs the other party that the key will be changed in the future, and the new key will be used for communication.

2.9.3.8. Encrypted Handshake Message

Sent by the client or server, followed by the Key Exchange. For testing, one party encrypts a fixed message with its just-generated key and sends it to the other party. If the key negotiation is correct, the other party can decrypt it correctly.

2.9.3.9. New Session Ticket

Sent by the server, indicating that a session is initiated, within a period of time (before the timeout period arrives), both parties communicate with the key just exchanged. Since then, encrypted communication has officially started.

2.9.3.10. Application Data

Data at the application layer encrypted using the key negotiated by the key exchange protocol.

2.9.3.11. Encrypted Alert

Sent by the client or server, it means that the encrypted communication needs to be interrupted for some reason, and the other party is warned not to send sensitive data.

2.9.4. Version update content

2.9.4.1. TLS 1.3

  • Introduced PSK as a new key agreement mechanism

  • Supports 0-RTT mode, at the cost of reduced security, saving round-trip time when establishing a connection

  • All handshake messages after ServerHello are encrypted, and it can be seen that the plaintext is reduced

  • Encrypted packets are no longer allowed to be compressed, and both parties are no longer allowed to initiate renegotiation

  • DSA certificates are no longer allowed in TLS 1.3

  • Remove insecure cryptographic algorithms

    • RSA key transport - does not support forward security

    • CBC mode cipher - vulnerable to BEAST and Lucky 13 attacks

    • RC4 stream cipher - not secure to use over HTTPS

    • SHA-1 hash function - SHA-2 is recommended instead

    • Arbitrary Diffie-Hellman Group - CVE-2016-0701 Vulnerability

    • Output Password - Vulnerable to FREAK and LogJam

2.9.5. Subprotocols

The SSL/TLS protocol has a highly modular architecture and is divided into many sub-protocols, mainly:

  • Handshake Protocol

    • Including negotiated security parameters and cipher suites, server authentication (optional client authentication), key exchange

  • ChangeCipherSpec Protocol

    • A message indicating that the handshake protocol is complete

  • Alert Protocol

    • Some abnormal error reminders in the handshake protocol are divided into two levels: fatal and warning. The fatal type error will directly interrupt the SSL connection, while the warning level error SSL connection can still continue, but an error warning will be given.

  • Record protocol

    • Including message segmentation, compression, message authentication and integrity protection, encryption, etc.