answer
HTTPS The reason why the agreement is secure is HTTPS The protocol encrypts the transmitted data , The encryption process is implemented by asymmetric encryption . But in fact ,HTTPS Symmetric encryption is used for encryption of content transmission , Asymmetric encryption only works in the certificate verification phase .
Why is data transmission encrypted symmetrically ？
First , The efficiency of asymmetric encryption is very low , and http There is a lot of interaction between the normal end and the end in the application scenario of , The efficiency of asymmetric encryption is unacceptable ;
in addition , stay HTTPS Only the server saves the private key in the scenario , A pair of public and private keys can only realize one-way encryption and decryption , therefore HTTPS The content transmission encryption in is symmetric encryption , Not asymmetric encryption .
Principle and process
Man in the middle attack principle
Process principle ：
-
Local request hijacked （ Such as DNS Hijack, etc ）, All requests are sent to the broker's server
-
The broker server returns the broker's own certificate
-
Client creates random number , The random number is encrypted by the public key of the intermediary certificate and then sent to the intermediary , Then construct symmetric encryption with random number to encrypt the transmission content
-
Middleman because of the random number of clients , The content can be decrypted by symmetric encryption algorithm
-
The middleman sends the request to the regular website with the request content of the client
-
Because the communication process between the middleman and the server is legal , The regular website returns encrypted data through the established security channel
-
The middleman decrypts the content with the symmetric encryption algorithm established with the regular website
-
The middleman encrypts the data returned by the normal content through the symmetric encryption algorithm established with the client
-
The client decrypts the returned data through the symmetric encryption algorithm established with the middleman
Due to the lack of verification of certificates , So although the client initiated HTTPS request , But the client has no idea that his network has been blocked , The transmission content is stolen by the middleman .
How do browsers verify the validity of certificates ？
Browser initiation HTTPS When asked , The server will return to the website SSL certificate , The browser needs to verify the certificate as follows ：
-
Verify domain name 、 Whether the validity period and other information are correct . The certificate contains this information , It's easier to verify ;
-
Determine whether the source of the certificate is legal . Each certificate can be checked according to the verification chain to find the corresponding root certificate , operating system 、 The browser will store the root certificate of the authority locally , Local root certificate can be used to issue certificates to corresponding organizations to complete source verification ;
-
Judge whether the certificate has been tampered with . Need and CA The server does the check ;
-
Determine if the certificate has been revoked . adopt CRL（Certificate Revocation List Certificate cancellation list ） and OCSP（Online Certificate Status Protocol Online Certificate Status Protocol ） Realization , among OCSP It can be used in 3 Step in to reduce with CA Server interaction , Improve verification efficiency
Only when any of the above steps are satisfied can the browser consider the certificate legal .
Can only certification authorities generate certificates ？
If you need a browser that doesn't prompt for security risks , Only certificates issued by certification bodies can be used . But browsers usually just hint at security risks , There is no restriction on the access of the website , So technically anyone can generate a certificate , As long as you have a certificate, you can complete the website HTTPS transmission . For example, the early 12306 It adopts the form of manual installation of private certificate HTTPS visit .
What to do if the local random number is stolen ？
Certificate verification is implemented by asymmetric encryption , But the transmission process is symmetric encryption , The important random number in symmetric encryption algorithm is generated locally and stored locally HTTPS
How to ensure that random numbers are not stolen ？
Actually HTTPS It doesn't include security guarantees for random numbers ,HTTPS The only guarantee is the security of the transmission process , And random numbers are stored locally , Local security belongs to another security category , The countermeasures are to install anti-virus software 、 Ewido 、 Browser upgrade to fix bugs, etc .
It was used HTTPS Will you be caught ？
HTTPS The data is encrypted , In general, the package content caught by the agent of the packet capturing tool after request is the encrypted state , Unable to view directly .
however , As mentioned above , The browser will only prompt for security risks , If the user is authorized to continue to visit the website , Complete the request . therefore , As long as the client is our own terminal , When we authorize , Then we can set up a network of middlemen , And the bag grabbing tool is acting as a middleman . Usually HTTPS The way to use the package grabbing tool is to generate a certificate , The user needs to manually install the certificate into the client , Then all requests initiated by the terminal complete the interaction with the packet capturing tool through the certificate , Then the packet capturing tool forwards the request to the server , Finally, the results returned by the server are output by the console and then returned to the terminal , To complete the whole request closed loop .
since HTTPS Can't prevent catching bags , that HTTPS What's the point ？
HTTPS It can prevent the communication link from being monitored without the user's knowledge , There is no protection for the operation of capturing the package of active credit , Because users of this scenario are already aware of the risks . To prevent being caught , Application level safety protection is required , For example, using private symmetric encryption , At the same time, do a good job of anti decompilation and reinforcement of mobile terminal , Prevent local algorithms from being **.
