Process analysis of SSL/TLS algorithm

SSL/TLS is no longer a strange word, but its principles and rules are not too easy to remember. This article will try to show the principle of the process through some simple illustrations, hoping that the reader has something to gain.

first, the relevant version

Proposed Internet standard

(from IETF) [TLS1]

td>

Version	Source	Description	Browser support
SSL v2.0	Vendor Standard   (from Netscape Corp.) [SSL2]	first SSL protocol for which implementations exist	-NS Navigator 1.x/2.x  -MS IE 3.x  -Lynx/2.8+openssl
SSL v3.0	expired Internet Draft (from Netscape Corp.) [SSL3]	revisions to prevent specific security attacks, add non-rsa ciphers and support for certificate chains	-NS Navigator 2.x/3.x/4.x  -MS IE 3.x/4.x  -Lynx/2.8+openssl
TLS v1.0	revision of SSL 3.0 to update the MAC layer To hmac, add block padding for block ciphers, message order standardization and more alert messages.	-lynx/2.8+openssl

SSL is all called Socket security layer,tls is all called Transport Layer Security, there is no essential difference between the two is to do the transport layer above the encryption (between the transport layer and the application layer). TLS is the name of the subsequent SSL version branch, and it is meaningless to spend a long time arguing about the pros and cons of both. Current TLS latest version is TLS1.2 (also known as SSL3.3)

second, the problem of SSL/TLS solution

Information is tapped (wiretap), third party access to the content of communications anywhere;

SSL/TLS enables the encryption of transmitted information.

Data is tampered with (tampering), third parties can modify the data in the transmission;

SSL/TLS enables data signing and validation.

Identity is impersonating (pretending), the third party can impersonate the identity of the communicator to transmit data;

SSL/TLS uses the CA digital certificate authentication mechanism.

third, the handshake stage

To put it simply, SSL/TLS encryption of the transport layer is realized by encrypting the data with the dynamic key, while the dynamic key is negotiated by the handshake process, and in order to ensure the security of the dynamic key, the public key encryption algorithm (asymmetric) and the digital certificate signature are used.

The information that a SSL/TLS handshake process needs to negotiate includes:

1 version number of the Protocol;

2 encryption algorithm, including asymmetric encryption algorithm, dynamic key algorithm;

3 digital certificate, the transmission of both sides through the exchange of certificates and signature verification of mutual authentication;

4 dynamic key, which transmits data using the key for symmetric and decryption, which is encrypted by an asymmetric key.

Iv. Process Analysis

A typical SSL/TLS handshake process consists of two-way authentication, as follows:

1. Clients send a client Hello message that carries information including:

A list of supported SSL/TLS versions, supported and encrypted algorithms, supported data compression methods, random number A;

2. The service side responds to a server Hello message that carries information including:

Negotiated SSL/TLS version number; session ID; random number b; service-side digital certificate Serverca;

Due to the two-way authentication requirements, the server needs to authenticate the client, and simultaneously sends a customer certificate request, representing the requesting client's certificate;

3. The client verifies the digital certificate of the server, and sends the random number C after the verification is passed, which is called Pre-master-key, and is issued by using the public key in the digital certificate;

because the client certificate request is initiated by the server, the clients use the private key to encrypt a random number clientrandom issued with the client's certificate CLIENTCA;

4. The server verifies the client's certificate and successfully decrypts the client encrypted random number clientrandom;

Generate dynamic key Master-key according to random number A/random number B/random number C (Pre-master-key), encrypt a finish message to send to client;

5. The client generates Master-key based on the same random number and algorithm, encrypts a finish message and sends it to the server;

6. The service side and the client are successfully decrypted, the handshake is completed, and then the packets are encrypted and transmitted using Master-key.

Five, the key points analysis two-way authentication and one-way authentication

Two-way authentication to better solve the problem of identity impersonation, the server provides the certificate at the same time requires the authentication of the client identity; However, in some common application scenarios, there is often only one-way authentication, such as the use of HTTPS Web site only requires the client (browser) to authenticate the server side of the certificate.

In a one-way authentication scenario, the Handshake Phase 2 server does not issue the client certificate request, and then the server does not need to verify the clients certificate;

In a two-way authentication scenario, if the client fails to provide a certificate, a warning message is issued for no digital certificate alert, which may result in a handshake failure (depending on the service-side policy);

use of random numbers

Because the digital certificate is static, it is required to use random factors to guarantee the randomness of the negotiation key; for the RSA algorithm,Pre-master-key itself is a random number, plus the random in the Hello message, three random numbers through a key exporter to finally export a symmetric key.

the reason for using the Pre-master-key mechanism is that SSL protocol does not trust each host can produce a completely random random number, if the pre-master-key is not random, then the risk of being guessed is very big, so just use Pre-master-secret as the key is inappropriate, need to introduce new random factors, That is, combining the two-way random number in the hello message.

session key Reuse

The SSL/TLS handshake process is cumbersome, while asymmetric encryption and decryption performance is much worse than symmetric key, and it is necessary to implement session reuse to improve performance if you need to do a handshake each time the connection is rebuilt to incur significant overhead.

Common ways to do this include:

SessionID (RFC 5246), both the client and the server maintain a session ID, and the session data state, while rebuilding the connection, the two parties based on the SessionID to find the previous conversation key for reuse;

Sessionticket (RFC 5077), which generates an encrypted ticket from the server based on session state, and also sends the key to the client to ensure that both ends can decrypt it. This mechanism is more lightweight than SessionID, and the server does not need to store session state data, which can alleviate some pressure.

Verification of Certificates

1. Check the digital signature;

The digital signature is generated by the Digital Digest algorithm and transmitted by the private key, and the public key is decrypted.

2. CA chain authorization check;

3. Certificate Expiration and activation time check;

The calculation diagram of the Numeric digest

about the server Name indication

In the ordinary SSL/TLS handshake, the client sends information that does not include the domain name of the server, so in theory the server can contain only one domain name, otherwise it will not be able to tell the client which domain name the digital certificate should be provided. The SNI (server name Indication) extension is implemented in subsequent TLS versions to support scenarios where a single server host needs to serve multiple domain names.

When requested by the client, the specified domain name is sent and the server chooses the appropriate certificate to complete the handshake.

Vi. Reference Documentation

An overview of the operating mechanism of Nanyi _SSL/TLS protocol

An overview of the SSL or TLS handshake

Process analysis of SSL/TLS algorithm