Why you need HTTPS

HTTP is transmitted in plaintext. In a broadcast domain (all devices connected to the same switch), all devices can receive the transmitted data (only the link layer protocol checks whether the MAC address is its own, and then discards it).

The security of its data may be wiretapped, tampered with, the identity of the sender is not reliable. So TLS(Transmission Security Protocol) provides encryption, digital signatures, and digital certificates to solve these three problems.

Encrypted – anti-eavesdropping

Encryption algorithms are divided into symmetric encryption and asymmetric encryption. TLS uses a combination of asymmetric encryption and symmetric encryption.

Symmetric encryption

Symmetric encryption, which uses the same key for encryption and decryption, is efficient, but cannot be transmitted directly on the network (directly spreading symmetric keys causes the key to be eavesdropped).

Asymmetric encryption

Asymmetric encryption is when one of a pair of keys is used to encrypt and decrypt (one is called a public key and one is called a private key). It can be encrypted with a public key or a private key.

Its advantage is that it can be used in network communication scenarios – all users of the network expose their public keys. The sender encrypts the data with the receiver’s public key so that only the receiver can unlock the encrypted data. But the disadvantage is the low efficiency of encryption and decryption.

  • Key negotiation algorithm is the principle of asymmetric encryption

A simple mathematical problem is used to simulate RSA, the core of asymmetric encryption

There are two formulae for calculating public and secret keys: each person’s private key is known only to himself, and the public key is public

3^ private key %17 = public key (can be seen from the public key is not inverse private key)

It is now specified that: A: (private key) 13 B: (private key) 15 Can be calculated as: A: (private key) 13 (public key) 12 B: (private key) 15 (public key) 6Copy the code

Final key:

Private key 13 of A + public key 6 of B 10 Private key 15 of B + public key 12 of B -> (key) 10

In this way, in the open network, A and B can negotiate A pair of public keys only known to both of them (the key must be obtained by the public key of one party and the private key of the other party).

A now wants to tell B A number K (sic), so puts him in an envelope labeled 12 (12 is A’s public key) and transmits K +10 (10 is the negotiated key) (encryption). After B receives the message, it sees 12 on the envelope and knows that it is A message from A. It calculates the secret key with A’s public key and gets 10, and then subtracts 10 (decryption).

Now the encryption transmission of information only needs to send and receive the public key can be complete, everyone discloses their public key, the receiver can get the public key, the sender to mark their public key in the envelope, the receiver can also get the sender’s public key.

While other eavesdropping can only get K +10 (ciphertext), since there is no private key of B, there is no way to calculate the key, so it is impossible to know the real data.

In this way, the sender encrypts the data with the receiver’s public key to ensure that only the receiver can understand the data sent by the sender.

Digital Signature – Tamper-proof

Encryption lets the sender not worry about the data being seen, but the receiver does not guarantee that the data it receives is trustworthy. The data could have been tampered with (i.e., someone could have changed the k+10 in the envelope to k+9).

Therefore, digital signature is introduced to ensure that B can determine whether the data has been modified by others when receiving the data.

A digital signature is similar to a verification code. It is attached to the end of the original file to be transferred. If the original file and the digital signature are modified, the verification fails.

  • Implementation of digital signature – private key encryption abstract

A digital signature is obtained by encrypting a summary of the original file with the sender’s private key. A digest is a hash map of the original file, which is faster to encrypt because of its small size.

When the receiver receives the original file and the digital signature, it does two things.

  1. Calculate the original file and get the abstract M
  2. Decrypt the digital signature with the public key of A and obtain the abstract of N

If the abstracts m and N are the same, the original file has not been tampered.

Note: digital signatures do not prevent eavesdropping, only ensure that the data sent is the same as the data received

Digital Certificates – Identity authentication

In the above process, A’s public key is used for decryption. So the question remains, is this public key reliable? Does user A really exist, or is it really user A?

So there are digital certificate authorities and digital certificates, which are used to authenticate the sender.

A digital Certificate Authority (CA) is the authority in communication that all users trust.

Sender A sends its public key to CA. The CA encrypts sender A’s public key with its private key, generates A certificate, and sends the certificate to A.

During subsequent communication, USER A first sends its own public key certificate (user A’s public key encrypted with the CA private key) to USER B. User B uses the CA public key to decrypt the received certificate. The public key is considered reliable only after decryption succeeds.

TLS handshake process

The TLS handshake process can be divided into two simple processes

  • The client obtains the CA certificate of the server, verifies its validity and obtains the public key of the server (to ensure that the received data is not tampered with).
  • The client and server generate the same key and then use the generated key to encrypt the communication
  1. -> The client sends a request to the server for encrypted communication, carrying a random number I
  2. <- The server responds. 3. The server CA certificate is sent to the client with a random number j
  3. The client verifies the CA certificate and obtains the public key of the server
  4. -> The client encrypts a random number k with the server’s public key and sends it
  5. The client and server generate the same key with three random numbers ijk respectively (symmetric key)
  6. <- The server sends the handshake completed message, then encrypts the communication using the symmetric key

Installing an Agent Certificate

When using Charles to capture packets, it acts as an intermediary between the client and the server, allowing all data to be captured.

However, when capturing HTTPS packets, the public key and private key of the server are used for data decryption. The public key is the certificate of the server, while the private key cannot be obtained. Therefore, all data is garbled.

So you need to

  1. Make the proxy act as the server for the client – install Charles’s certificate on the client, so that the encryption on the client uses Charles’s public key and the data on the client is readable to Charles.
  2. Let the proxy act as the client of the server — Charles itself communicates with the server using the server’s real certificate (public key).

That is, the certificate of the installed agent software is issued by the agent software and generated using the public key of the agent software. The client must install the certificate and trust Charles as the issuing authority.