HttpEncryption

Why do I need encryption?

Because the content of http is transmitted in clear text, it will pass through many physical nodes, such as intermediate proxy server, router, wifi hotspot, communication service operator and so on. If the information is hijacked in the process of transmission, the content of transmission will be completely exposed, and the transmitted information can be tampered with without being detected by both parties. This is a man-in-the-middle attack. So the information needs to be encrypted.

Symmetrical encryption

A secret key that encrypts a piece of content and can only be used to decrypt the original content. Transmission process:

1. A key is generated by the server and transmitted to the browser in clear text. two。 The browser encrypts the content with a key and returns it to the server.
2. The server decrypts the content with the key. Defect: the key is hijacked by the middleman.

Asymmetric encryption

Two keys, one public key and one private key. The content encrypted with the public key can only be solved with the private key. Similarly, the content encrypted by the private key can only be solved by the public key. Transmission process:

1. The server transmits the public key plaintext to the browser.
2. The browser encrypts the content with a public key and returns it to the server.
3. The server decrypts the content with the private key. The middleman cannot decrypt the transmission even if it is hijacked to the public key. Defect: the public key can decrypt the content passed from the server to the browser.

Asymmetric Encryption (Improved)

Use two sets of public and private keys Drawback: asymmetric encryption algorithms are very time-consuming

Asymmetric encryption + symmetric encryption mixed encryption (HTTPS)

Transmission process:

1. The server transmits the public key to the browser. two。 The browser randomly generates a key X for symmetric encryption, encrypts it with the public key and passes it to the server.
2. The server decrypts the key X with the private key.
3. So both parties have key X. After that, all data of both parties are encrypted and decrypted with key X. Vulnerabilities:
4. The middleman prepared a pair of public keys B and private keys B. two。 When the server transmits the public key A to the browser, the middleman returns it to the browser with its own public key B, and saves the public key A.
5. The browser encrypts the content with the public key B, the middleman decrypts the content with his own private key B, and then adjusts the packet to the original public key An and returns it to the server.
6. The server decrypts the content hijacked by the middleman with the private key A. Need to be resolved: prove in step 2 that the public key received by the browser must be the public key sent from the server, not the counterfeit of the middleman.

CA certification

Vulnerability: forged CA certificate.

Digital signature

Generate a "signature" for the content, and you can detect whether it has been tampered with by comparing whether the content and the signature are consistent. The process of generating a digital signature:

1. CA has a pair of asymmetric encrypted private and public keys.
2. CA hash the plaintext information of the certificate.
3. Encrypt the value after hash with a private key to get a digital signature. Browser validation process:

the main task is to decrypt the digital signature. Compare it with the content.

1. Get the content and digital signature encrypted by the CA private key. two。 The encrypted digital signature is decrypted with the public key of the CA mechanism, and the digital signature is obtained. because CA is an organization trusted by browsers, browsers keep the public key of CA.
2. Hash the digital signature using the hash algorithm described in the certificate to get the content protected by the digital signature.
3. Comparing whether the [content protected by digital signature] is equal to the content indicates that the certificate is credible.

Why do I need hash?

What you get after hash is that the encryption and decryption of fixed-length information is much faster.

How to prove that the CA public key is trusted?

The browser holds the CA public key. How can you prove that the public key is trusted? The operating system and browsers themselves will preinstall some root certificates they trust (such as CA certificates).

Does HTTPS have to shake hands at the SSL/TLS layer to transfer the key in each request?

The server maintains a session ID for each browser (or client software), which is passed to the browser during the TSL handshake phase, and the key is cached to session. There is no need for duplicate authentication during the session.