The introduction

“Can you talk about HTTPS?”

“A more secure protocol than HTTP.”

“…”

If you say this in an interview, it’s almost “gg.” In fact, HTTPS can be quite informative when it comes to developing an answer. Learn more about what HTTPS is, why it is secure, and how to implement it.

This article is a little longer, so be patient.

What is HTTPS?

HTTPS is a secure HTTP channel, which is simply the secure version of HTTP. It is secure because it sends HTTP packets to a security layer (implemented through SSL) to encrypt the packets before sending them to TCP.

Advantages of packet encryption

  • Ensure that the conversation between the client and server cannot be eavesdropped by others
  • Ensure that the data sent by both parties will not be modified halfway
  • Make sure both parties are real clients/servers and not fake ones

Think of A message as A letter written by A to B. A puts the message in A locked box so that no one else can access the message or tamper with it.

Encryption mechanism

Just a few terms

  • Plaintext: indicates unencrypted packets
  • Ciphertext: packets encrypted using the encryption algorithm
  • Key: A parameter that changes the behavior of an encryption algorithm

Let’s say we have an encryption function, and the algorithm is as follows

function E(key, p) {
    // Move each letter of p to the right. For example, if the key is 3, A-->D, B-->E...
}

E(3."AB"); // DE  
Copy the code

Plaintext: AB —— ciphertext: DE” —— Key: 3

If we have different keys then our encryption function will execute differently.

Here’s a look at some common encryption mechanisms.

Symmetric encryption

As we talked about earlier, we encrypt messages so that we can keep our conversations secret, so that only we can read them, but no one else can. So we’re gonna have to agree on some kind of encryption, like when you and I pass notes to each other and put them in a box, and then only we have the key to that box. He can’t open the box if anyone else gets it, so there’s no way to steal anything.

Symmetric encryption means this: the sender encrypts the plaintext with the key, and the receiver decrypts it with the same key.

Although security is guaranteed, there are still two problems:

  • When the sender and the sender agree on the key, the key needs to be transmitted over the network. As a result, the key may be leaked and the security is not guaranteed.
  • The sender and receiver must have a shared key before they can talk to each other. Imagine, if N clients all want to establish secure communication with the server, then the server needs to keep N keys, and N and clients communicate with N servers, then there will be N^2 keys, which is very inconvenient to manage.

Asymmetric encryption

Asymmetric encryption and symmetric encryption work in reverse. Symmetric encryption uses the same key, while asymmetric encryption uses two different keys: public key and private key. The contents encrypted by one key can only be unlocked by the other key.

The public key is well known, while the private key is held only by the host.

The server generates public key A and private key B. When the client wants to send A packet to the server, the client first finds the public key of the server, encrypts the packet based on public key A, and the server decrypts the packet using private key B. Similarly, when the server wants to send a packet to the client, it first finds the public key C of the client and encrypts the packet according to the public key C, and the client decrypts the packet using its private key D.

In order to ensure information security and facilitate key management.

Thus, the difference between symmetric and asymmetric encryption is:

. Symmetric encryption Asymmetric encryption
The key Same key for encryption and decryption Public and private keys, one encrypted and the other decrypted
Key management Large number of keys, inconvenient Each host manages only one pair of public and private keys
security Insecure (not that the mechanism is insecure, but that the key may be leaked when both parties agree on it) Security (no dialog agreement key required)
Encryption/decryption speed fast slow

So what mechanism does HTTPS use?

HTTPS Encryption Mechanism

HTTPS encrypts packets symmetrically.

A complete HTTPS exchange

(1) The client establishes a TCP connection to port 443 (HTTPS’s default port) through TCP three-way handshake

(2) The client establishes the security layer through SSL handshake

(3) The client sends HTTP packets to the SSL security layer. The security layer encrypts the packets and sends them to TCP –> IP –>…

(4) Similarly, the server sends a response, and the client receives it and decrypts it to the application layer through SSL security layer

(5) SSL security layer shutdown notification

(6) TCP closes the connection

From the preceding description, we can clearly see that packet encryption and decryption are performed at the SSL layer.

So how is the security layer encrypted? How is the key contracted? All of this has to do with step (2).

The SSL handshake

(1) The client sends an alternative encryption algorithm to the server and requests a certificate.

The client says, “Hey, kid. I have a bunch of encryption algorithms that I support, so you pick one and send it to me. By the way, send me a copy of your ID card to have a look, I am afraid that the server I connect is forged.”

(2) The server sends the selected encryption algorithm and certificate

The server says, “EMMM… I think encryption algorithm A is good. Let’s use it. A certificate is also issued to you to prove that I am not a bad person.”

(3) The client saves the encryption algorithm and secret key A selected by the server for future encryption, encrypts A with the server’s public key B and sends it to the server, and the server decrypts it with its own secret key C to get A. From then on, both the client and the server use the agreed encryption algorithm and secret key A for symmetric encryption.

See? Asymmetric encryption is used to transmit symmetric encrypted secret key A in the network, and then symmetric encryption is used for all packets.

(4) The client and server inform each other to start the encryption process.

After the SSL handshake we can happily send and receive encrypted messages.

The above is the whole process of HTTPS encryption, but it does not constitute a complete HTTPS. A complete HTTPS requires packet security and identity security. Encryption only ensures packet security, but does not ensure correct identity.

Imagine that A and B write to each other and exchange box keys, and then send the letter in the box. The encryption behavior above makes the contents of the letter written between A and B not accessible to others, but what if IT is not B who communicates with A in the first place? If the thief C communicates with A disguised as B, then A will exchange the key with C during SSL and C can steal the contents of the letter from A to B.

We use digital certificates for identity authentication.

The digital certificate

Structure of a message containing a digital certificate:

Remember step (1) from the SSL handshake? The client asks the server for a certificate that the server can use to prove its identity. The certificate contains some basic information about the server, such as the DNS host name of the site, the organization name of the site, and the public key of the site (the public key is issued to enable client SSL to perform handshakes (3)). The certificate information includes the serial number, certificate signature algorithm, and expiration date of the certificate.

A digital signature

A certificate is an ID card for a site, but an ID card can also be forged, and to make sure the certificate is genuine we need a digital signature. We use a signature algorithm to generate a value for the certificate content, which we call a “summary.” The digest is then encrypted with the private key of the host, and the encrypted content is our digital signature.

If the decrypted public key results in a summary that does not match the generated summary, there are two possible scenarios

  • The sender identity is not the destination host
  • The certificate sent by the destination host is tampered with. Procedure

Digital certificates and encryption constitute a complete HTTPS transaction.

conclusion

  • HTTPS is secure because of two guarantees
    • Conversations between the two parties are encrypted so that no one can steal them
    • The identities of both parties are real, preventing thieves from forging identities
  • Content security
    • Asymmetric encryption Mechanism Encryption “Key required for symmetric encryption”
    • Symmetric encryption encrypts packets
  • Identity safe
    • The digital certificate
    • A digital signature
      • Identify the sender
      • Verify that the certificate has not been tampered with

Reference Books:

The Definitive GUIDE to HTTP