I. Handshake and key negotiation process
The client authentication server based on RSA handshake and key exchange is used as an example to explain the TLS/SSL handshake.
1, client_hello
The client initiates a request and transmits the request information in plaintext, including the version information, encryption suite candidate list, compression algorithm candidate list, random number, and extended fields. The related information is as follows:
SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2. The version later than TLSv1 is rarely used.
Cipher suites list supported by the client. Each cipher suite corresponds to the combination of the preceding four functions in TLS: Authentication algorithm Au (identity authentication), KeyExchange algorithm KeyExchange(key negotiation), symmetric encryption algorithm Enc (information encryption) and information digest Mac(integrity check);
List of supported compression methods for subsequent information compression transmission;
Random number random_C, used for subsequent key generation;
Common SNI is an extension field. The functions of this field will be discussed separately in the following sections.
2, server_hello + server_certificate + sever_hello_done
(a) server_hello, the server returns the negotiation result, including the protocol version selected, cipher suite selected, compression method selected, random_S random number, etc. The random number is used for subsequent key negotiation.
(b) Server_certificates, where the corresponding certificate chain is configured on the server side for authentication and key exchange;
(c) server_hello_done, notify the client server_hello message sending end;
3. Certificate verification
The client verifies the validity of the certificate. If the verification succeeds, the client communicates with the certificate. Otherwise, the client prompts and performs operations based on the error situation.
Certificate chain trustWorthiness Trusted Certificate Path, as described above;
There are two modes for certificate revocation: offline CRL and online OCSP. Different clients have different behaviors.
Whether the certificate is valid;
Domain name domain, check whether the certificate domain name matches the current access domain name, and analyze the matching rules later;
4, client_key_exchange + change_cipher_spec + encrypted_handshake_message
(a) Client_key_exchange. After passing the validity verification, the client calculates and generates a random pre-master number, encrypts it with the certificate public key, and sends it to the server;
(b) At this point, the client has obtained all the information needed to calculate the negotiated key: two plaintext random numbers random_C and random_S and the pre-master generated by its own calculation, to calculate the negotiated key;
enc_key=Fuc(random_C, random_S, Pre-Master)
Note: 1. Change_cipher_spec: The client notifies the server that the subsequent communication adopts the negotiated communication key and encryption algorithm for encrypted communication;
2. Encrypted_handshake_message: Encrypted_handshake_message combines the hash values of all the previous communication parameters with other information, encrypts it with the session secret algorithm, and sends it to the server for data and handshake verification.
5, change_cipher_spec + encrypted_handshake_message
(a) The server decrypts the encrypted pre-master data with the private key, and calculates the negotiated key based on the two plaintext random numbers random_C and random_S exchanged before :enc_key=Fuc(random_C, random_S, pre-master);
(b) Calculate the hash value of all previously received messages and decrypt the encrypted_Handshake_message sent by the client to verify the correctness of the data and key;
(c) Change_cipher_spec. After the authentication passes, the server also sends change_cipher_spec to inform the client that the subsequent communication uses the negotiated key and algorithm for encrypted communication.
(d) encrypted_handshake_message. The server also generates a piece of data with all the current communication parameters and encrypts it with the session secret algorithm and sends it to the client;
6. End of handshake
The client computes the hash value of all received messages and decrypts the encrypted_handshake_message with a negotiated key to verify the data and key sent by the server. If the authentication passes, the handshake is complete.
7. Encrypt communication
Start encrypted communication with the algorithm using the negotiated key.
Note: (a) The server can also require the authentication client, i.e., two-way authentication, to send client_CERTIFicate_Request information during procedure 2. The client sends client_Certificate and certificate_verify_message in Process 4. The certificate authentication methods are basically the same. Certificate_verify_message uses the private key of the client to encrypt data based on negotiated communication information. The server can decrypt and verify data using the corresponding public key.
(b) Depending on the key exchange algorithm used, e.gECCEtc., the details of the negotiation are slightly different, but generally similar;
(c) Sever Key Exchange is used when the Server certificate does not carry enough information, it is sent to the client to calculate the pre-master. For example, the DH-based certificate, the public key is not included in the certificate and needs to be sent separately.
(d) Change Cipher Spec can actually be used to inform the peer end to change the current encrypted communication mode, which is not thoroughly analyzed at present;
(e) ALTER message is used to indicate the status change or error information in the process of handshake or communication. Generally, the trigger conditions of alarm information are connection closure, receipt of illegal information, information decryption failure, user cancellation, etc. After receiving the alarm, communication will be disconnected or the receiver decides whether to disconnect.
Session cache handshake process
To speed up handshake establishment and reduce performance degradation and resource consumption (detailed in the following section), the TLS protocol provides two session caching mechanisms: session ID and session ticket.
The session ID is supported by the server and is a standard field in the protocol. Therefore, it is supported by almost all servers. The server saves the session ID and negotiated communication information.
Session ticket is an extended field supported by both the server and the client, and the supported range is about 60%(no statistics or source is available). The session ticket encrypts the negotiated communication information and sends it to the client for saving. The key is known only by the server, occupying few server resources.
The comparison between the two is mainly about the different location and way of saving negotiation information, which is similar to session and cookie in HTTP.
If both exist, session_ticket is preferred.
The handshake process is as follows:
Note: Although there are 1.5 rounds of shaking, the first application data sent by the client to the server does not need to wait for information back from the server, so the handshake delay is 1*RTT.
1. Session ID
(a) If a connection has been established between the client and the server, the server will return the session ID after the handshake is successful and save the corresponding communication parameters in the server;
(b) If the client needs to establish a connection with the server again, the session ID in client_hello carries the recorded information and sends it to the server;
(c) The server retrieves the cache record based on the received session ID. If no cache expiration is retrieved, the normal handshake process is followed;
Change_cipher_spec and encrypted_Handshake_message are returned if the corresponding cache record is retrieved. Encrypted_handshake_message is the hash value to the current communication parameter and master_secret;
(f) The client also sends change_CIpher_SPEC and encrypted_Handshake_message if the client can verify that the data is encrypted by the server;
(g) If the server verifies that the data passes, the handshake is established successfully and normal encrypted data communication begins.
2. Record the session ticket
(a) If a connection has been established between the client and server, the server carries encrypted session_ticket information in the new_session_ticket data, which is saved by the client.
(b) If the client needs to establish a connection with the server again, the extended field session_ticket in client_Hello carries encrypted information and sends it to the server.
(c) The server decrypts sesssion_ticket data. If the decryption fails, the normal handshake process is followed;
(d) If decryption succeeds, the change_CIpher_spec and encrypted_Handshake_message are returned, similar to those in the session ID;
(f) The client also sends change_CIpher_SPEC and encrypted_Handshake_message if the client can verify that the data is encrypted by the server;
(g) If the server verifies that the data passes, the handshake is established successfully and normal encrypted data communication begins.
Three,Reconstruction of connection
Renegotiation is a process in which the TLS connection in use is abandoned and identity authentication and key negotiation are performed again. It is characterized by reauthentication and key or algorithm update without disconnecting the current data transmission. Therefore, the information stored and cached on the server can be retained. Both the client and the server can initiate the reconnection process, which is currently not supported by Windows 2000 & XP and SSL 2.0.
1. The server reestablishes the connection
Server reconnection usually occurs when a client accesses protected data. The basic process is as follows:
(a) A valid TLS connection is established and communicated between the client and server;
(b) Client access to protected information;
(c) The server returns the hello_REQUEST message;
(d) After receiving the hello_Request message, the client sends client_Hello message to re-establish the connection.
2. The client reestablishes the connection
The client reestablishes the connection to update the communication key.
(a) A valid TLS connection is established and communicated between the client and server;
(b) The client needs to update the key and actively sends client_hello message;
(c) The server cannot immediately identify the client_hello message as non-application data after receiving it, so it will submit it to the next step for processing. After processing, it will return a notification indicating that the message is required to rebuild the connection;
(d) The server will not immediately stop sending data to the client until the connection is reestablished. It may be at the same time or cache data needs to be sent to the client, but the client will not send any information to the server;
(e) After the server recognizes the reconnection request, it sends server_hello message to the client;
(f) The client also cannot immediately determine that the information is not application data, so it is also submitted to the next step for processing. After processing, the client will return a notification that the information is required to rebuild the connection;
(g) The client and server begin the process of re-establishing the connection.
Four,The key to calculate
The previous section mentioned two random numbers random_C and random_S transmitted in plaintext and the pre-master exchanged between the server and the client through encryption, with three parameters as the basis for key negotiation. This section describes the basic calculation process of key negotiation and key usage during communication.
1. Calculate the Key
Random Client and Random Server, pre-master, Master Secret and key Material are involved. When calculating the key, both the server and client have these basic information, and the exchange mode is described in the previous section. The calculation process is as follows:
(a) The client uses RSA or Diffie-Hellman encryption algorithms to generate pre-master;
(b) Pre-master calculates master secret through PseudoRandomFunction(PRF) by combining two random numbers, random Client and Random Server;
(c) Master Secret combines random client and Random Server to obtain Key material through iterative calculation;
The following is some important records, can solve part of the love in-depth study of the doubts of friends, copy of the material, to share with you:
(a) The first two bytes of PreMaster secret are TLS version numbers. This is an important version number for checking the handshake data, because during the Client Hello phase, the Client will send a list of encryption suites and the currently supported SSL/TLS version numbers to the server. In addition, the packet is transmitted in plaintext. If the packet is cracked, the attacker is likely to change the packet in sequence and choose a less secure encryption suite and version to the server, so as to crack the data. Therefore, the server needs to compare the version number of the PreMaster decrypted pair in the ciphertext with the version number of the previous Client Hello phase. If the version number becomes lower, it indicates that the PreMaster version is changed in a string and stops sending any messages immediately. (copy)
(b) Both the client and the server need random numbers so that the generated key is not the same every time. Because SSL certificates are static, it is necessary to introduce a randomness factor to ensure the randomness of the negotiated keys.
For the RSA key exchange algorithm, the pre-master-key itself is a random number, plus the randomization in the Hello message, three random numbers through a key exporter finally exported a symmetric key.
The existence of Pre Master is that SSL protocol does not trust each host to generate a completely random random number. If the random number is not random, pre Master Secret may be guessed, so it is not appropriate to only apply Pre Master Secret as the key. Therefore, it is necessary to introduce a new random factor, so it is not easy to guess the key generated by the client and server together with the three random numbers pre Master secret. One pseudo-random may not be random at all, but three pseudo-random will be very close to random. Every increase of one degree of freedom, the randomness will not increase by one.
2. Use of key
After 12 iterations of Key calculation, 12 hash values will be obtained, which can be grouped into 6 elements. The list is as follows:
(a) MAC Key, encryption key, and IV are sets of encryption elements that are used by the client and the server, respectively, but are retrieved by both sides at the same time;
(b) The client uses the Client group element to encrypt data, and the server uses the Client element to decrypt data; The server uses the server element for encryption and the client uses the server element for decryption.
(c) The key used in the different directions of two-way communication is different, which requires at least two cracking of the communication;
(d) Encryption key used to encrypt data symmetrically;
(e) IV is used as the initialization vector of many encryption algorithms, specifically symmetric encryption algorithms can be studied;
(f) Mac key is used for data integrity check;
3. Data encryption communication process
(a) Fragment the application layer data into appropriate blocks;
(b) Number fragmented data to prevent replay attacks;
(c) Data compression using negotiated compression algorithms;
(d) Compute MAC values and compress data to compose transmission data;
(e) Encrypt data with client Encryption key and send it to the server server;
(f) After the server receives the data, it uses client Encrytion key to decrypt, verify, decompress and reassemble the data.
Note: MAC value calculation includes two Hash values: client MAC key and Hash (number, packet type, length, compressed data).
Five,Caught analysis
There is no more detailed analysis about packet capture. According to the previous analysis, the basic situation can be matched. According to the usual process of locating problems, I propose some points that need to be paid attention to:
1, caught
To capture HTTP communication, you can clearly see the headers and plaintext of the communication. However, HTTPS is encrypted communication, and you cannot see the headers and plaintext of the data. HTTPS communication consists of the following three processes: TCP connection establishment, TLS handshake, and TLS encrypted communication are used to analyze the handshake establishment and status of HTTPS communication.
2, client_hello
Based on the version information, you can know the highest protocol version supported by the client. If the version is SSL 3.0 or TLS 1.0, some handshake failures may occur due to the earlier version.
Determine whether SNI is supported according to the Server_name field in the Extension field. If SNI exists, SNI is supported. Otherwise, SNI is not supported.
Session ID Is part of the standard protocol. If no connection has been established, the corresponding value is empty. If no connection has been established and the corresponding connection has been cached.
Session TicKE T Indicates the extended protocol. If this field exists, sesssion ticket is supported. Otherwise, sesssion ticket is not supported.
3, server_hello
The TLS Version field indicates the highest version of the protocol supported by the server. Different versions may cause a handshake failure.
Based on cipher_suite information, the encryption protocol that the server preferentially supports is determined.
4, ceritficate
The certificate chain configured and returned by the server determines whether the request is consistent with the expectation based on the certificate information and compares the certificate information with the server configuration file. If the request is inconsistent, whether the default certificate is returned.
5, and alert.
The alarm alert indicates the cause of the connection failure. The alarm type is very important for locating faults.