HTTPS

As the cost of HTTPS has dropped, most sites are now using HTTPS. We all know that HTTPS is more secure than HTTP, and we have heard of SSL, asymmetric encryption, CA certificates, etc., related to HTTPS protocol, but the following three questions may not be answered:

  1. Why is HTTPS secure?
  2. How to implement the underlying principles of HTTPS?
  3. Is HTTPS always safe?

This article will be layer by layer, from the principle of HTTPS security explain through.

HTTPS implementation principle

You’ve probably heard that THE HTTPS protocol is secure because it encrypts the transmitted data using asymmetric encryption. However, IN fact, HTTPS uses symmetric encryption for content transmission. Asymmetric encryption only applies to certificate verification.

The HTTPS process consists of certificate authentication and data transmission. The interaction process is as follows:

① Certificate verification phase

  1. The browser initiates an HTTPS request
  2. The server returns the HTTPS certificate
  3. The client verifies whether the certificate is valid. If the certificate is invalid, an alarm is generated

② Data transmission stage

  1. When the certificate is valid, a random number is generated locally
  2. The public key encrypts the random number and transmits the encrypted random number to the server
  3. The server decrypts random numbers using private keys
  4. The server uses the random number from the client to construct a symmetric encryption algorithm, encrypts the returned result and transmits it

Why is data transmitted symmetrically encrypted?

First of all, the efficiency of asymmetric encryption is very low, and there is usually a lot of end-to-end interaction in HTTP application scenarios, so the efficiency of asymmetric encryption is unacceptable.

In the HTTPS scenario, only the server saves the private key, and a pair of public and private keys can only realize one-way encryption and decryption. Therefore, the content transmission encryption in HTTPS adopts symmetric encryption instead of asymmetric encryption.

Why do I need a CA to issue a certificate?

HTTP is considered insecure because the transmission process is easy to be tapped by listeners and forged servers, while HTTPS mainly solves the security problem of network transmission.

First, we assume that there is no certification authority and that anyone can create a certificate, which presents a security risk known as the classic “man-in-the-middle” problem. The detailed process of man-in-the-middle attack is as follows:

Process principle:

  1. Local requests are hijacked (e.g., DNS hijacking) and all requests are sent to the middleman’s server
  2. The middleman server returns the middleman’s own certificate
  3. The client creates a random number, encrypts the random number using the public key of the middleman certificate, and sends the random number to the middleman. Symmetric encryption is constructed based on the random number to encrypt and transmit the transmitted content
  4. Because the middleman has the random number of the client, it can decrypt the content through the symmetric encryption algorithm
  5. The middleman sends a request to the official website with the content requested by the client
  6. Because the process of communication between the middleman and the server is legal, the legitimate website returns encrypted data through a secure channel established
  7. Middlemen decrypt content using symmetric encryption algorithms established with legitimate websites
  8. The middleman encrypts and transmits the data returned by the regular content through the symmetric encryption algorithm established with the client
  9. The client decrypts the returned result data through a symmetric encryption algorithm established with the middleman

Due to the lack of certificate verification, although the client initiates an HTTPS request, the client is completely unaware that its network has been intercepted and the transmitted content is stolen by a middleman.

How does the browser ensure that the CA certificate is valid?

1. What information does the certificate contain?

  • Information of issuing Authority
  • The public key
  • Your company information
  • The domain name
  • The period of validity
  • The fingerprint
  • …

2. What is the basis of validity of the certificate?

Above all, authoritative orgnaization should have attestation, not just an orgnaization is qualified to issue a certificate, otherwise also not be called authoritative orgnaization. In addition, the credibility of the certificate is based on the trust system, and the authority needs to endorse the certificate issued by the authority. As long as the certificate generated by the authority, we consider it legitimate. Therefore, the authority will review the information of the applicant, and the requirements of the authority of different levels are not the same, so the certificate is also divided into free, cheap and expensive.

3. How does the browser verify the certificate validity?

When the browser initiates an HTTPS request, the server returns the website’s SSL certificate. The browser needs to verify the certificate as follows:

  1. Verify that the domain name and validity period are correct. All certificates contain these information, which is easier to complete verification;
  2. Determine whether the certificate source is valid. Each issued certificate can be found based on the authentication chain. The operating system (OS) and browser store the root certificate of the authorized authority locally, and use the local root certificate to authenticate the source of the issued certificates of the authorized authority.
  3. Determine whether the certificate has been tampered with. Verification with the CA server is required.
  4. Determine whether the certificate has been revoked. Through Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP), OCSP can be used in step 3 to reduce interaction with the CA server and improve verification efficiency

The browser considers the certificate valid only if any of the preceding steps are met.

Here is a question that I have been thinking about for a long time, but the answer is actually very simple: since the certificate is public, if I download a certificate from the official website as my server certificate, the client will definitely recognize that the certificate is legitimate. How can I avoid the situation of fraudulent use of the certificate? In fact, this is the use of public and private keys in unencrypted symmetry. Although the middleman can get the certificate, the private key cannot be obtained. It is impossible to calculate the corresponding private key of a public key.

4. Can only certification authorities generate certificates?

If you want the browser to avoid security risks, you can only use the certificate issued by the certification authority. However, browsers usually just warn of security risks and do not restrict access to websites, so technically anyone can generate a certificate that can complete HTTPS transfer of a website. For example, early 12306 uses the form of manually installing private certificates to implement HTTPS access.

What if local random numbers are stolen?

Asymmetric encryption is used for certificate authentication, but symmetric encryption is used for transmission. Important random numbers in the symmetric encryption algorithm are generated and stored locally. How does HTTPS prevent random numbers from being stolen?

In fact, HTTPS does not guarantee the security of random numbers. HTTPS only guarantees the security of transmission, and random numbers are stored locally. Local security belongs to another security category.

Can I get caught using HTTPS?

HTTPS data is encrypted. Generally, packets captured by the packet capture tool are in the encrypted state and cannot be viewed.

However, as mentioned above, the browser will only alert you to security risks if the user is authorized to continue accessing the site and complete the request. Therefore, as long as the client is our own terminal, we can set up the middleman network under the condition of authorization, and the packet capture tool is the agent acting as the middleman. The use of the HTTPS caught tool is usually generates a certificate, the user needs to manually install the certificate to the client, then the terminal by all the request through the certificate completed and caught tools of interaction, and then caught tools forward requests to the server, finally, the server returns the results in the console output and then returned to the terminal, Thus completing the loop of the entire request.

If HTTPS can’t prevent packet capture, what’s the point of HTTPS? HTTPS prevents communication links from being monitored without users’ knowledge. However, HTTPS does not provide protection against packet capture with active credit, because users are already aware of risks in this scenario. To prevent packet capture, application-level security protection is required, such as proprietary symmetric encryption, and anti-decompilation hardening on mobile terminals to prevent local algorithms from being cracked.

conclusion

The following is a brief Q&A to summarize the whole paper:

Q: Why is HTTPS secure? A: HTTPS ensures the transmission security, preventing the transmission process from being monitored and data from being stolen, and confirming the authenticity of the website.

Q: How does HTTPS transfer work? A: HTTPS requests, the client by the server to return the certificate to the client to authenticate certificate, after verification by the local generating random Numbers are used to transform symmetric encryption algorithm, through the certificate of public key encryption transmission of the random number to the server, the server receives the random number is obtained by decrypted, after data interaction through symmetric encryption algorithm and decryption.

Q: Why do YOU need a certificate? A: It protects against “man-in-the-middle” attacks and provides proof of identity for websites.

Q: Can PACKETS be captured if HTTPS is used? A: Packets will be captured. HTTPS only prevents users from having their communications monitored without their knowledge. If users actively grant credit, A “middleman” network can be constructed, and proxy software can decrypt the transmitted content.


BLOG address: www.liangsonghua.com

Pay attention to wechat public number: songhua preserved egg bulletin board, get more exciting!

Introduction to our official account: We share our technical insights from working in JD, as well as JAVA technology and best practices in the industry, most of which are pragmatic, understandable and reproducible