Preface
HTTPS implements the encrypted and secure transmission of HTTP through the TLS/SSL protocol. The TLS/SSL protocol mainly relies on three algorithms to achieve security functions:
Asymmetric encryption: implements identity authentication and key agreement
Symmetric encryption: encrypts data Hash
function: verifies the integrity of information For
symmetric encryption, asymmetric encryption and signatures, please refer to this document
HTTPS uses a combination of symmetric encryption and asymmetric encryption. The specific method is:
the party sending the information (client) uses the public key of the server to encrypt the "symmetric key", and the server uses the private key to decrypt and obtain the "symmetric key". This ensures that the transmission process of the "symmetric key" is secure, and the "symmetric key" can be used for subsequent encrypted data transmission.
Specific process of digital certificate authentication
Submit the server public key, organizational information, personal information (domain name) and other information to the third-party agency CA and apply for certification. (In actual operation, it is often necessary to provide a private key, and it will automatically extract the public key from the private key)
The CA uses a variety of means to verify the authenticity of the information provided by the applicant, such as whether the organization exists, whether the enterprise is legal, and whether it owns the domain name. wait. If the information is reviewed and approved, the CA will issue a certification document-certificate to the applicant.
The certificate contains the following information: the applicant's public key, the applicant's organizational information and personal information, the information of the issuing authority CA, the validity time, the plain text of the certificate serial number and other information, and also contains a signature. The signature generation algorithm: first, use a hash function to calculate the information digest of the public plaintext information, and then use the CA's private key to encrypt the information digest, and the ciphertext is the signature.
When the client makes a request to the server, the server returns the certificate file.
The client reads the relevant plaintext information in the certificate, uses the same hash function to calculate the information digest, and then uses the public key of the corresponding CA to decrypt the signature data and compares the information digest of the certificate. If they are consistent, the certificate can be confirmed to be legitimate. sex.
The client will also verify the domain name information, validity time and other information related to the certificate; the client will have built-in trust CA certificate information (including public key). If the CA is not trusted, the certificate corresponding to the CA will not be found, and the certificate will also be Determined illegal.
HTTPS workflow
1. The client initiates an HTTPS request.
2. The server returns the configured certificate to the client.
3. The client verifies the certificate: for example, whether it is within the validity period, whether the purpose of the certificate matches the site requested by the Client, whether it is in the CRL revocation list, whether its upper-level certificate is valid, etc. 4. The client uses pseudo-random number
generation Symmetric key, encrypted by the server's public key in the certificate. This symmetric key is subsequently used to transmit information.
5. The server uses its own private key to decrypt the message and obtain the symmetric key. At this point, both the client and the server hold the same symmetric key.
6. The server uses a symmetric key to encrypt "plain text content A" and sends it to the client.
7. The client uses the symmetric key to decrypt the ciphertext of the response and obtains "plaintext content A".
8. The client initiates an HTTPS request again, uses the symmetric key to encrypt the requested "plaintext content B", and then the server uses the symmetric key to decrypt the ciphertext and obtains "plaintext content B".
This maintains encrypted communications.
Reference document: https://github.com/ljianshu/Blog/issues/50