SSL handshake and workflow (two-way HTTPS process)

SSL protocol workflow:

Server Authentication phase:1)The client sends a start message "hello" to the server to start a new session connection;2)The server determines whether to generate a new CMK based on the customer's information. If necessary, the server will include the information required to generate the CMK in response to the customer's "hello" information;3)The customer generates a master key based on the server response information and encrypts it with the public key of the server to transmit it to the server;4)The server restores the CMK and returns a message for the customer to authenticate the server with the CMK.
User authentication stage: before that, the server has passed the customer authentication, which completes the customer authentication. The authenticated server sends a question to the customer, and the customer returns the question signed by (number) and the Public Key to provide the server with authentication.
From the services provided by the SSL protocol and their workflow, we can see that the foundation of the SSL protocol is the merchant's commitment to the confidentiality of consumer information, which is conducive to the merchant and is not conducive to the consumer. In the early stage of e-commerce, most enterprises that operate e-commerce are large companies with high reputation, so this problem has not been fully exposed. However, with the development of e-commerce, various small and medium enterprises are also involved, which leads to the problem of single authentication in the electronic payment process becoming more and more prominent. Although SSL3.0 uses digital signatures and digital certificates to verify the identity of both the browser and the web server, the SSL protocol still has some problems, such, the SSL protocol can only provide mutual authentication between the client and the server in the transaction. In electronic transactions involving multiple parties, the secure transmission and trust relationship between the parties cannot be coordinated. In this case, the two credit card organizations, Visa and MasterCard, have developed a SET agreement to provide global standards for online credit card payment.

 

Handshake process of the SSL protocol

To better understand and understand the SSL protocol, we will introduce the handshake protocol of the SSL protocol. The SSL protocol uses both public key encryption technology (asymmetric encryption) and symmetric encryption technology. The encryption of SSL for transmitted content is symmetric encryption, then, symmetric encryption is performed on the key using the public key. The advantage of doing so is that symmetric encryption technology is faster than public key encryption technology and can be used to encrypt Large Transmission content. public key encryption technology is relatively slow and provides better identity authentication technology, used to encrypt keys used in symmetric encryption.
The SSL handshake protocol is very effective for customers and servers to complete identity authentication. The main process is as follows:
①The client browser sends the SSL protocol version number of the client to the server, which is encrypted.AlgorithmTypes, random numbers, and various information required for communication between other servers and clients.

②The server sends the version number of the SSL protocol, the type of the encryption algorithm, the random number, and other related information to the client. At the same time, the server also sends its own certificate to the client.

③The customer uses the information sent from the server to verify the server's legitimacy. The server's legitimacy includes: whether the certificate expires, and whether the CA that issues the server certificate is reliable, whether the public key of the issuer certificate can properly unbind the "digital signature of the issuer" of the server certificate, and whether the domain name on the server certificate matches the actual Domain Name of the server. If the legality verification fails, the communication will be disconnected. If the legality verification passes, the fourth step will continue.

④The user end randomly generates a "symmetric password" for subsequent communication, and then encrypts it with the server's public key (the server's public key is obtained from the server certificate in step 2, then, pass the encrypted "pre-master password" to the server.

⑤If the server requires the customer's identity authentication (optional during the handshake), you can create a random number and then sign the data, send the random number containing the signature together with the customer's own certificate and the encrypted "pre-master password" to the server.

⑥If the server requires the customer's identity authentication, the server must check the validity of the customer's certificate and signature random number. The specific validity verification process includes: whether the customer's certificate date is valid, whether the CA that provides the certificate is reliable, whether the public key of the CA can properly unbind the digital signature of the CA that issues the certificate, and check whether the certificate is in the Certificate Revocation List (CRL. If the verification fails, the communication will be interrupted immediately. If the verification passes, the server will unbind the encrypted "pre-master password" with its own private key ", then, execute a series of steps to generate the master communication password (the client will generate the same master communication password in the same way ).

7.The server and the client use the same master password as the "Call password". A symmetric key is used for encryption and decryption of secure data communication over the SSL protocol. At the same time, data communication integrity must be completed during SSL communication to prevent any changes in data communication.

BytesThe client sends a message to the server, indicating that the next data communication will use the master password in Step 7 as a symmetric key, and notifies the Server client that the handshake process ends.

BytesThe server sends a message to the client, indicating that the next data communication will use the master password in Step 7 as a symmetric key, and notifies the client server that the handshake process ends.
BytesThe handshake of SSL ends, and the data communication of the SSL Secure Channel begins. The customer and the server start to use the same symmetric key for data communication, and the integrity of the communication is verified.

 

Process of two-way SSL Authentication
①The browser sends a connection request to the security server.

②The server sends your certificate and information related to the certificate to the client's browser.

③The client browser checks whether the certificate sent from the server is issued by a trusted ca. If yes, continue to execute the Protocol. If not, the client browser will send a warning message to the customer, warning the customer that the certificate is not trustworthy, asking the customer if they need to continue.

④Then, the client browser compares the messages in the certificate, such as the domain name and public key, and whether the messages sent by the server are consistent. If they are consistent, the client browser recognizes the legitimate identity of the server.

⑤The server requires the customer to send the customer's own certificate. After receiving the certificate, the server verifies the customer's certificate. If the certificate fails, the connection is rejected. If the certificate is verified, the server obtains the user's public key.

⑥The client browser informs the server of the Communication symmetric password solution that it can support.

7.The server selects a password solution with the highest degree of encryption from the password solution sent by the customer, and uses the customer's public key to add the password to notify the browser.

BytesThe browser selects a call key for this password scheme, and then uses the server's public key to encrypt the key and send it to the server.

BytesThe server receives the message sent from the browser and decrypts it with its own private key to obtain the call key.

BytesThe next communication between the server and the browser is based on the symmetric password scheme, and the symmetric key is encrypted.

The above describes the specific communication process of the two-way authentication SSL protocol. In this case, both the server and the user must have a certificate. One-way SSL authentication does not require the customer to have a CA certificate. The specific process is relative to the above steps, you only need to remove the process of verifying the customer certificate on the server side, and negotiate the symmetric password scheme, when a symmetric call key is used, the server sends a password that is not encrypted (which does not affect the security of the SSL process. In this way, the specific communication content of both parties is encrypted data. If a third party attacks, only encrypted data is obtained, and a third party needs to obtain useful information, you need to decrypt the encrypted data. At this time, security depends on the security of the password solution. Fortunately, the current password scheme is secure as long as the length of the Communication Key is long enough. This is why we stress that 128-bit encrypted communication is required.