Handshake and communication over the SSL protocolTo better understand and understand the SSL protocol, we will introduce the handshake protocol of the SSL protocol. SSL uses both public key encryption and symmetric encryption. Although symmetric encryption is faster than public key encryption, public key encryption provides better identity authentication. 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 version number of the client SSL protocol, the type of encryption algorithm, the random number generated, and various information required for communication between other servers and clients to the server.
② The server sends the version number, type of encryption algorithm, random number, and other related information of the SSL protocol to the client, and the server also sends its own certificate to the client.
③ The client 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 generates a random "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), the user 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 is valid on the date of use, 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 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.
The producer client sends a message to the server, indicating that the master password in Step 7 will be used for subsequent data communication as a symmetric key, and notifying the Server client that the handshake process is complete.
The slave server sends a message to the client, indicating that the master password in Step 7 will be used for subsequent data communication as a symmetric key, and notifying the client server end of the handshake process.
The handshake part of the SSL protocol 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 communication integrity is verified. Process of two-way SSL Authentication
① The browser sends a connection request to the security server.
② The server sends the 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 center. 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.
④ The client browser then compares the messages in the certificate, such as the domain name and public key, with whether the messages sent by the server are consistent. If yes, 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.
6. 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.
The ghost 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.
The ghost server receives the message sent from the browser and decrypts it with its own private key to obtain the call key.
The next communication between the ghost server and the browser is the symmetric password scheme. 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. Meanings of each part of the certificate
Version certificate Version. Different Versions of certificates have different formats.
The Serial Number of the Serial Number. The Serial Number of the certificate issued by the same authentication authority is unique.
Algorithm Identifier signature Algorithm, including the identity information of the Issuer identity authentication authority.
Period of Validity Period
ID of the Subject certificate holder
Subject's Public Key Certificate Holder's Public Key
Signature of the Signature authentication authority to the certificate Certificates issued by the Certification Center follow the X.509 V3 standard. The basic format is as follows: Certificate Version: used to specify the X.509 Version used in the Certificate Format.
Certificate Serial Number (Certificate Serial Number) indicates the unique Serial Number of the Certificate to identify all Public Key Certificates issued by the CA.
Algorithm Identifier indicates the Signature Algorithm used by the CA to issue a certificate.
The CA Name (Issuer) that issues the certificate indicates the unique X.500 Name (DN, Distinguished Name) of the CA that issues the certificate ).
NotAfter indicates the start date and end date of the Certificate.
User Name (Subject) meaning: used to specify the unique X.500 Name (DN, Distinguished Name) of the certificate user ).
Description: used to identify the algorithm used by the Public Key and contain the Public Key itself.
Extensions: used to specify additional information.
X.509 V3 certificate Extension (extended domain) and implementation method: CA Public Key Identifier (Authority Key Identifier) Public Key Identifier (SET unused) (Key Identifier) the Serial Number of the Issuer's Certificate (Certificate Issuer) X.509 V3 certificate Extension (extended domain) and Authority Key Identifier (SET not used) of CA) the Identification name of the issuer Certificate (the Serial number of the Certificat issuer Certificate (Certificate Serial N meaning: the Subject Key Identifier that uniquely identifies a user is used to identify a specific Key associated with the public Key in the certificate for decryption. Key Usage indicates the purpose of a public Key.
Note after (note before) indicates the start date and end date of the private key validity period of a user. The certificate policy list (certificate policies ies) recognized by the CA indicates the policy applied to the user certificate. The certificate policy can be expressed by the object identifier. Substitutional name: used to specify the user's substitute name. Meaning of the substitute name (issuer alt name) of CA: used to specify the substitute name of CA. Basic constraints indicates whether the certificate user is an end user or a ca. In the set system, there are some private extensions (Extended domains) hashed root keys. They are used only in the root certificate and used for backtracking when the certificate is updated. Certificate type: used to distinguish different entities. This item is required. Merchant data (merchant data) meaning: contains all merchant information required by the payment gateway. Card Cert required indicates whether the payment gateway supports transactions with non-certificate holders. Setextensions: lists the set information extensions of the payment commands supported by the payment gateway. CRL data definition version: displays the CRL version number.
Indicates the name of the CA that issues the CRL. CRL release time (this update) estimated next CRL Update Time (next update) Certificate Information Directory (revoked certificates) CRL extension (CRL extension) CA's Authority Key Identifier) CRL number)
|
