In the identity authentication of the communication party, we usually ensure the security by verifying the server CA certificate, which is usually purchased from a third-party authority. So how do we verify the CA certificate?
CA certificate is verified step by step from bottom to top, and it can be regarded as credible from CA certificate to root certificate.
Using the same hash function in CA certificate to calculate plaintext information to get information digest A-> Decrypting the signature with CA's public key to get information digest B->; If the information abstracts are consistent, the validity of the certificate can be confirmed, that is, public key legality (public key of service provider S)->; Check whether the certificate has been revoked and whether the domain name information in the certificate is consistent with the valid time (the certificate can be built into the APP to compare the public key and domain name)-> The CA certificate was verified.
After the CA is verified, the "intermediate certificate" is verified by the same principle until the root certificate is trusted by the system.
There are two kinds of certificate revocation mechanisms: CRL and OCSP.
Certificates usually contain the address of CRL or OCSP.
The certificate has been verified. Let's look at another question: how to ensure the security of the exchange process by exchanging symmetric encryption keys with asymmetric encryption?
For the client, it is troublesome for users to generate certificates. For example, when we do iOS development, the development certificate is generated by ourselves according to the steps, and an account can only generate three certificates at most.
Detailed explanation of the principle of iOS APP signature mechanism
In order to speed up the handshake and reduce the performance degradation and resource consumption caused by the protocol, TLS protocol has two types of session caching mechanisms: session ID and session ticket.
The session ID is equivalent to a verification code (but can be reused), which is generated by the server. If it is not used for half an hour, it will be invalid, and if it is used, it will be reset to the validity period of half an hour. Http requests with the same session ID are considered to be in the same session.
In the case that the HTTPS connection has been established, our server or client can initiate the reestablishment of the connection and reestablish the TLS handshake in some cases. The reestablishment of the connection is based on the original TCP connection, such as the following cases:
Although the HTTPS connection is secure, there are more TLS handshake processes based on the original HTTP, which increases the RTT delay. More encryption and decryption processes will consume more server CPU resources.
The optimization direction mainly includes:
The era of full-station HTTPS has arrived. Are you ready?
Session recovery: Two brief handshakes summarize the session ID&; SessionTicket