Why do YOU need HTTPS?

Because HTTP is transmitted in plaintext, the middleman can obtain the plaintext data (thus enabling tampering with the data). That’s where HTTPS comes in!

What is HTTPS?

HTTPS = HTTP + SL/TLS, SSL is also called Secure Sockets Layer (SSL), which was changed to TLS Transport Layer Security when V3 was developed. The main purpose is to provide data integrity and confidentiality by adding a gatekeeper between HTTP and TCP.

How to ensure data integrity?

HTTPS does three things to achieve integrity and confidentiality

  • Encryption: Encrypts the transmitted data.
  • Data consistency: Ensures that data will not be tampered with during transmission
  • Identity authentication: Determine the true identity of the other party.

1. Summary algorithm

We can add a summary to the content, digest the content again after transmission to the server, and see if the results of the two summaries are the same (we can tell if the data has been tampered with based on the summary) because the tampered data must be different from the original summary

2. Symmetric encryption (sender and receiver have a public key)

Symmetric encryption realizes the encryption and decryption of the same secret key through XOR operation, which is the core of symmetric encryption.

Disadvantages: multiple transmissions from the same receiver can be easily cracked.

AES(Advanced Encryption Standard) ChaCha20 is the most common symmetric Encryption algorithm introduced by Google.

AES encryption steps:

  1. The plaintext is divided into several plaintext blocks according to 128 bits (16 bytes). Each plaintext block is a 4*4 matrix
  2. Fills the last plaintext block with the chosen padding
  3. Each plaintext block is encrypted into a ciphertext block using AES encryptor and secret key
  4. All ciphertext blocks are combined to form the final ciphertext result

3. Asymmetric encryption (sender and receiver both have a key sender gets a public key receiver gets a private key)

  • Private key encryption public key decryption
  • Public key encryption Private key decryption

Only half the problem… Although we can rely on two sets of keys to achieve communication, the problem is that the performance and efficiency are not high. The more data is added, the more complex the decryption grows exponentially.

Public and private keys in RSA algorithms (also used in CA certificates)

4. Mixed encryption

To put it simply: symmetric encryption + asymmetric encryption. Through asymmetric encryption to solve the problem of secret key transmission, data transmission using symmetric encryption problem (public and private key + random number) (ultimately used for communication secret key or generated by the client)

Even at this point, there’s still a problem: since a man-in-the-middle attack can forge a public key, you don’t know who sent it to you.

Digital Certificates and Certificate Authority (CA)

Since anyone can publish a public key, we need an asymmetric cryptographic application to authenticate each other. Prevent man-in-the-middle attacks.

1. Certificate encryption process

  1. When the client access server, the server will generate your own private key and public key – > pass public key to CA authentication (CA institution has its own public key private key, it will be the content for a signature (the certificate with the private key to sign directly to the content is too much, so we put the certificate for the (hash), with the results of the private key encryption); This step is largely done on the server and in the CA organization

The client determines the expiration date, issuer, whether the certificate has been modified, and whether the certificate has been revoked. 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 root certificate.

  1. The client needs to get the public key of the server. The client will put the root certificate in the operating system, so after receiving the certificate, it can verify the signature (decrypted with the built-in CA public key, which can decrypt the summary) and then pass the plaintext summary again to match the summary I decrypted, if always then the public key is valid. At this time someone asked: if the server public key in the plaintext is not the public key exposed? Since the CA part is to ensure that the server’s public key is not tampered with, the middleman cannot decrypt the data sent by the client, so there is no problem.

    Again: The core purpose of the above two steps is to prevent the server’s public key from being tampered with

  2. Create session key for long connection communication…

Note:
  • Public key type: RSA(1024Bits) RSA(2048Bits) ECDHE….
  • Encryption based on the private key, can only be decrypted with the public key: used for identity authentication
  • Public Key management: Public Key Infrastructure(PKI)
    • There are digital certificate recognition agencies that associate the user’s personal identity with the public secret key
    • Public key digital certificate
      • CA information, public key user information, public key, signature of authority, validity period
    • PKI user
      • A user who registers a public key with a CA
      • Users who want to use a registered public key

2. How do I confirm the validity of the certificate?

After the client obtains the certificate verification signature, it detects the revocation status, and the CA deploys a list of certificate validity information in two places.

  1. Go to the CRL server (THE CRL server is based on the linked list structure and has limited efficiency)
  2. Go to the OCSP responder

Three. Handshake process

The TLS handshake process can have a look at the image below (this is based on TLS1.2, as for TLS1.3 can open a hole again)

I’m going to focus on 1 to 4 and it’s a process.

  1. Client sends “Client Hello”
  2. The Server sends “Server Hello” and puts the certificate in it
  3. Configure an encryption policy based on the encryption suite sent from the server
  4. Change the server encryption suite

With that done, let’s look at the most important negotiation part of the process, the encryption suite.

Encryption suite

The packet capture tool can capture fields such as cipher suit: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA during the handshake. Cipher suit is an encryption suite negotiation field used in the handshake phase. It can be regarded as the encrypted and decrypted cipher book used by the server and client for negotiation. After successful negotiation, the cipher suit is used to decrypt the private conversations between the two ends. TLS(protocol)_ECDHE(Key exchange protocol)_RSA(signature algorithm)_WITH_AES_256_CBC(symmetric encryption algorithm)_SHA(message authentication code)

Test TLS site security suite support

ECDHE protocol:

Here’s how ECDHE works

  1. The client passes a random number C to the server
  2. The server also passes a random number S to the client
  3. The server gives the client a serverParmas (DH parameter)
  4. Client gives server a clientParams (DH parameter)

Server session key = random number C + random number S + serverParams + clientParams Client session key = random number C + random number S + serverParams + clientParams Server session key == Client-side session keys (from which to negotiate a session secret key)

And random number C and random number S function:Prevents man-in-the-middle Dos attacks. If the same random number is checked twice, no response is receivedThe ECDHE protocol is based on the Diffie-Hellman (DH) algorithm to generate session secret keys. The DH parameters are in plain text and can be obtained by the middleman. However, the intermediate values generated in the DH algorithm cannot be obtained, which ensures high session security.

DH Upgrade ECDH(Based on Elliptic Curves)

Because DH algorithm has a lot of multiplication, the operation is slow. ECDH is generated based on Elliptic Curve Cryptography (ECC). Faster, shorter keys for equal security.

The differences between RSA and DH are as follows: RSA is determined by the client. The length of RSA is used to improve the decryption difficulty. DH is negotiated by both parties

In theory, any encryption can be broken by a high-powered device, so how else?

Quantum communication (based on the light wave-particle duality curve), the principle is that each additional communication node will directly affect the accuracy of information, so that both sides of the communication are aware of eavesdropping.

Four, to sum up

The whole HTTPS process can be summarized as symmetric + asymmetric + digest algorithm (Hash/MD5 / SHA).

advantages

  1. Increasing data accuracy and reliability (secure and reliable), using HTTPS protocol to authenticate users and servers, ensuring that data is sent to the right clients and servers.

  2. Increases the cost of man-in-the-middle attacks

    • HTTPSIs the most secure solution under the current architecture, although not absolutely secure, but it significantly increases the cost of man-in-the-middle attacks.

  3. SEO is friendly and easy to get better search rankings

    • Google jump in 2014 search algorithm, adoptedHTTPSEncrypted sites will rank higher in search results.
    • Baidu also released a Baidu pair in 2018HTTPSThe supportive attitude of the site indicatesHTTPSWill influence search ranking as one of the best features.

Shortcomings and limitations

  1. High energy consumption
  • Request loading: It takes more time and computing power than HTTP because of the additional layer of handshake encryption.
  • Increased cost: The use of certificates costs money, DV OV EV three certificates are each more expensive than the other, although they are all about the same

Tips: CA certificates are classified into DV, OV, and EV, and DV is the lowest. EV is the highest, after legal, audit strict verification, can prove the identity of the site owner

  1. HTTPS connection caching is not as efficient as HTTP

HTTPS connection caching is not as efficient as HTTP, increases data overhead and power consumption, and even compromises existing security measures.

  1. There are still limitations
    • CA certificates Man-in-the-middle attacks are also possible in cases where countries can control the CA root certificate. Reference to Snowden…
    • Some of the lower-version encryption suites still in use in TLS1.2 are at risk of being forcibly cracked

Article Reference link

1. The Transport Layer Security (TLS) Protocol Version 1.1

2. Hypertext Transfer Protocol — HTTP/1.1

3. Understand the PRINCIPLES, processes, and practices of HTTPS

4. TLS & Perfect Forward Secrecy