HTTPS related knowledge

Why HTTPS?

Because HTTP is not secure.

  1. confidentialityHTTP is used during communicationclear, which makes it possible for communications to be eavesdropped. Encryption is the most common way to prevent eavesdropping. The encryption mode is as follows:
    • Communication encryption: There is no encryption mechanism in HTTP. SSL or TSL can be used for encryption.
    • Content encryption: Encrypts the communication content, including the content contained in packets.
  2. Integrity: HTTP cannot verify packet integrity. Therefore, data may be subjected to man-in-the-middle attacks during transmission, resulting in packet tampering.
  3. Identity authentication: HTTP does not confirm the identity of the request and reply parties, so the identity may be disguised. HTTPS’s SSL provides not only encryption services, but also a certificate that identifies the communication party. The certificate is provided by a trusted third-party organization, and it is extremely difficult to forge the certificate. Therefore, the identity of the corresponding party can be confirmed as long as the corresponding party can confirm the certificate.

What is HTTPS?

The HTTPS port number is 443, and the HTTP port number is 80. So how can HTTPS be secure? The implementation is based on the “S”. The underlying protocol of HTTPS is SSL/TLS. In other words, HTTPS is HTTP with SSL shell, that is, HTTP+ encryption + authentication + integrity protection =HTTPS.

What is the SSL/TLS

HTTPS does not have anything to do with itself. It is supported by SSL/TLS. What is SSL/TLS?

SSL isSecure interface layerTLS is a very good secure communication protocol. When it was developed to v3, the Internet engineering group renamed it TLSTransport layer securityCurrently, the most widely used version is 1.2. In addition to HTTP, SSL/TLS also accepts other application protocols, such as FTP=>FTPS.

How does HTTPS address these three risks?

Through hybrid encryption, the confidentiality of information is guaranteed

According to the key usage, there are two encryption modes: symmetric encryption and asymmetric encryption. Symmetric encryption encrypts the shared key, that is, the key must be sent to the other party. However, in the Internet environment, how to forward the key? Encryption is meaningless if the eavesdropped key falls into the hands of an attacker. Asymmetric encryption uses a pair of asymmetric keys, one called a private key and one called a public key. As the name implies, the private key cannot be known to anyone, and the public key can be obtained by anyone. The usage mode is as follows: the sender encrypts the packet with the public key, and the recipient decrypts the packet with the private key without worrying about the key being eavesdropped and stolen by an attacker. Because asymmetric encryption is based on large numbers, it is slow. Another disadvantage is that asymmetric encryption requires more bits for encryption of the same strength. So HTTPS takes the best of both and combines them for communication. Asymmetric encryption is used in the stage of exchanging keys, and symmetric encryption is used in the stage of establishing communication exchange messages.

The algorithm is used to achieve integrity

Algorithms are often referred to as hash functions and hash functions, which can generate unique fingerprints for data to verify the integrity of data. Before the client sends data through the fingerprint algorithm to calculate the clear, when sending the clear + fingerprint encryption, together sent to the server, the server receives after decryption, in with the same digest algorithms have received clear fingerprints, compared with the fingerprint of carried in the message, if the same fingerprint, then to be complete.

The risk of impersonation is solved by placing the server public key in the digital certificate

As mentioned above, encryption can ensure the confidentiality of packets. In this process, there is also a public key trust problem. How to ensure that the public key is not modified? To solve the above problems, you can use a public key authentication certificate issued by a digital certificate authority, that is, CA authentication. As long as the certificate is trusted, the public key is trusted.

HTTPS link establishment process

In HTTP, a request packet is sent immediately after a connection is established, but HTTPS requires another “handshake” processThe TLS handshake. The TLS handshake process is shown in the figure below:TLS completes the handshake with two round trips (four messages). Take a look at the handshake process:

  1. Browser sendClient HelloMessage, the following information:
    • SSL/TLS version supported by the client, for example, TLS1.2
    • Supported cipher suites, such as ECDHE
    • A random number C generated by the client is used to generate the subsequent session key
  2. After receiving the Client Hello message, the server sends itServer Hello
    • Verify the SSL/TLS protocol version. Disable encrypted communication if the browser does not support it
    • Confirm the list of cipher suites and select the most appropriate encryption algorithm, such as ECDHE
    • The random number S generated by the server is used to generate the subsequent session key
    • The server also sends the certificate to the client to prove identity
  3. The Client responds with a Client Key Exchange. After receiving the message from the server, the client uses the browser or the CA public key in the system to verify the authenticity of the digital certificate. If the certificate is ok, the client extracts the server’s digital certificate from the digital certificateThe public keyIs used to encrypt packets.
    • A random number that is encrypted by the public key of the server mentioned above to protect it from hackers. This random number plus the other two random numbers generated above will each generate the master key of the encrypted session using the encryption algorithm agreed in the session.
    • Notification that the encrypted communication algorithm changes, and subsequent messages are encrypted with the session key
    • Finished Message, notifying the end. Make a summary of all the data you sent and encrypt it so the server can verify it
  4. Final response from the server.
    • Notification of encrypted communication algorithm changes
    • Finished Message, notifying the end. Make a summary of all previously sent data and encrypt it for the client to verify

Often meet test summary

Q: Why do YOU need a certificate?

A: Prevent “man-in-the-middle” attacks and determine the identities of both parties in A conversation

Q: Can PACKETS be captured when HTTPS is used?

A: Packets can be captured, but the plaintext cannot be seen and tampered with

Q: What is the encryption process of HTTPS?

A: The client requests and authenticates the public key from the server. The public key encrypts the random number generated during the TLS handshake to generate the session key. The two parties use the session key for encrypted communication.

Q: How does the client verify the validity of the certificate during the HTTPS handshake

A: A digital certificate contains the serial number, purpose, issuer, expiration date, and public key. If you simply send this information to the browser, the middleman can easily change the public key into his own public key. The solution is to use A digital signature. Generate a summary of the certificate information, encrypt the summary with the CA private key, and generate a digital signature. The server sends the digital certificate to the browser along with the digital signature, which can’t be modified by a middleman (this changes the summary and makes the digital signature non-repudiable). The browser takes the digital certificate and verifies its credibility against a “certificate chain”.

Q: This section describes HTTPS man-in-the-middle attacks

A: Tampered data was intercepted during transmission. CA certificate can solve the problem of man-in-the-middle attack