Front knowledge

Symmetric encryption

  • Symmetric encryption algorithm is used earlier encryption algorithm, also known as shared key encryption algorithm. In symmetric encryption algorithms, only one key is used, and both sender and receiver use this key to encrypt and decrypt data. This requires that both encryption and decryption parties must know the encryption key beforehand.
    • Data encryption process: In a symmetric encryption algorithm, the data sender encrypts the plaintext (original data) and encryption key together to generate complex encrypted ciphertext for sending
    • Data decryption process: If the data receiver wants to read the original data after receiving the ciphertext, it needs to use the encryption key and the reverse algorithm of the same algorithm to decrypt the encrypted ciphertext so that the ciphertext can be restored to readable text

Asymmetric encryption

  • Asymmetric encryption algorithm, also known as public key encryption algorithm. Different from symmetric encryption algorithms, asymmetric encryption algorithms require two keys: a publickey and a privatekey. The public key and private key are a pair. If the public key is used to encrypt data, only the corresponding private key can be used to decrypt data. If data is encrypted with a private key, it can only be decrypted with the corresponding public key. Because encryption and decryption use two different keys, the algorithm is called asymmetric encryption.
    • If the public key is used to encrypt data, only the corresponding private key can be used to decrypt data. If the private key is used to encrypt data, only the corresponding public key can be used to decrypt data.
    • Example: Party A generates a pair of keys and discloses one of them to others as a public key. Party B who has obtained the public key encrypts the confidential information with the key and then sends it to Party A. Party A then decrypts the encrypted information with another private key (private key) saved by party A.

HTTPS concept

  • HTTP + SSL/TLS: Originally, HTTP data is directly thrown to TCP for processing and sending. In HTTPS, HTTP data is thrown to SSL/TLS for encryption, and then SSL/TLS is thrown to TCP. After receiving the packet, TCP also throws the packet to SSL/TLS for decryption, and finally to HTTP. Now it’s like a layer has been inserted between the two, so it’s commonly called SSL/TLS. (The difference between SSL and TLS is that TLS is an upgraded version of SSL. Optimize SSL and rename it TLS)

The communication process

  • Encryption prototype
    • HTTPS solves the problem of data transmission security by using encryption algorithms, specifically, the hybrid encryption algorithm, that is, the mixture of symmetric encryption and asymmetric encryption. If symmetric encryption is used and both parties need to use the same key, the key must be transmitted to the other party before data transmission. In this case, the key is likely to be intercepted and the encrypted data can be easily decrypted. Therefore, you need to ensure the security of the key during transmission. Asymmetric encryption transmission key, symmetric encryption transmission content

  • In the process of the above, the client to the server’s public KEY, generates a random code (both expressed with the KEY, the KEY is the follow-up for symmetric encryption KEY), then client using public KEY encryption and then sent to the server, the server using the private KEY to decrypt, so that both sides have the same KEY KEY, The two parties then use the KEY to symmetrically encrypt the interactive data. In asymmetric encryption transmission, even if a third party obtains the public KEY and encrypted KEY, it cannot crack the KEY without the private KEY (the private KEY is stored on the server and the risk of disclosure is minimal), thus ensuring the security of the following symmetric encryption data

  • Complete communication flow

  • 1. The client requests an HTTPS url and then connects to port 443 of the server.
  • 2. HTTPS servers must have a Certification Authority (CA) certificate. Certificates must be applied for and issued by a dedicated DIGITAL Certificate Authority (CA) after strict verification. The higher the security level, the more expensive it is). A private key and a public key are generated when a certificate is issued. The private key is kept by the server itself and cannot be disclosed. The public key is attached to the information of the certificate and can be made public. The certificate itself also comes with a certificate electronic signature, which verifies the integrity and authenticity of the certificate and prevents the certificate from being tampered with.
  • 3, the server responds to the client’s request and delivers the certificate to the client. The certificate contains the public key and a lot of other information, such as certificate authority information, user (company) information and certificate validity period, signature algorithm, etc. (Chrome browser can see the details of the certificate by clicking the lock symbol in the address bar and clicking the certificate)
  • 4. The client parses the certificate and verifies it. If the certificate is not issued by a trusted authority, or the domain name in the certificate is inconsistent with the actual domain name, or the certificate has expired, a warning is displayed to the visitor and he or she can choose whether to continue the communication
    • If there is nothing wrong with the certificate, the client retrieves the server’s public key A from the server certificate. The client also generates A random code KEY and encrypts it using the public KEY A

  • 5. The client sends the encrypted random code KEY to the server as the symmetric encryption KEY
  • 6. After receiving the random KEY, the server will use the private KEY B to decrypt it. After these steps, the client and server finally establish a secure connection, perfect solution to the symmetric encryption key leakage problem, then can use symmetric encryption for communication
  • 7. The server encrypts the data symmetrically using the KEY (random KEY) and sends it to the client. The client decrypts the data using the same KEY (random KEY)
  • 8. Both parties then use symmetric encryption to transmit all data

SSL/TLS handshake

Important concepts

  • Digital Certificate: In asymmetric encrypted communication, the server sends the public key to the client. During this process, the public key is likely to be intercepted and replaced by a third party, who can then pretend to be the server and communicate with the client. This is known as a man in the middle attack. The solution to this problem is to exchange the public key through a trusted third party. In this way, the server does not send the public key directly to the client, but requires the trusted third party, namely the Certificate Authority (CA), to merge the public key into the digital Certificate. The server then sends the public key along with the certificate to the client, and the private key is kept by the server for security
  • Digital signature: This concept is easy to understand, but it is similar to a person’s handwritten signature. It is used to ensure the legal identity of the data sender and the data content is not tampered with to ensure the integrity of the data. Unlike handwritten signatures, digital signatures change as text data changes. In the application scenario of digital certificates, the process for generating and verifying digital signatures is as follows:
    • The server abstracts the certificate content (commonly used algorithm is SHA-256, etc.), obtains the abstract information, encrypts the abstract information with the private key, and obtains the digital signature
    • The server sends the digital certificate along with the digital signature to the client
    • The client decrypts the digital signature with the public key to obtain the summary information
    • The client recalculates the certificate digest using the same information digest algorithm and compares the two digest information. If the two digest information are the same, the certificate is not tampered. Otherwise, certificate verification fails
  • Password specifications and CipherSuites (CipherSpecs and CipherSuites) : the algorithms used by the communication parties during the secure connection must comply with the password security protocol. CipherSpecs and CipherSuites define the valid cipher algorithm combinations. CipherSpecs is a combination of authentication encryption algorithms and message digest algorithms that both parties must agree to in order to communicate. CipherSuites defines a combination of three different encryption algorithms used in SSL/TLS secure connections
    • Key exchange and authentication algorithms used during the handshake (most commonly RSA)
    • Encryption algorithm (used for symmetric encryption after handshake, AES, 3DES, etc.)
    • Information digest algorithms (commonly used are SHA-256, SHA-1, MD5, etc.)

Handshake process

  • After the first step of the complete communication process, the requesting server needs to have a connection for communication. TLS handshake is the process of initiating HTTPS communication, similar to the three-way handshake for TCP connection establishment, in order to establish a secure connection:
    • Agree on versions of TLS to be used for communication (e.g. TLS1.0, 1.2, 1.3, etc.)
    • Determine the password combinations to be used by both parties
    • The client authenticates the server through the public key of the server and the digital signature on the digital certificate
    • Generates a session key that will be used for symmetric encryption after the handshake ends

  • 1. “Client Hello” message: The client sends a “Client Hello” message to the server to initiate a handshake request. This message contains TLS versions supported by the client and password combinations for the server to select, as well as a “Client Random” random string
  • 2. “Server Hello” message: The server responds to the client with a “Server Hello” message containing a digital certificate, a password combination selected by the server, and a “Server Random” random string
  • 3. Verification: The client verifies the certificate sent by the server to ensure the legal identity of the other party, including checking the digital signature, verifying the certificate chain, checking the validity period of the certificate and checking the withdrawal state of the certificate (withdrawal means that the certificate has become invalid).
  • 4. “premaster secret” string: The client sends the server another random string “premaster secret”, which is encrypted by the server’s public key and can only be decrypted by the corresponding private key
  • 5. Use private key: Server uses private key to decrypt “premaster secret”
  • 6. Generation of shared KEY: Client Random, Server Random and Premaster Secret are used by both client and server, and the same algorithm is used to generate the same shared KEY
  • 7. The client is ready: The client sends a FINISHED message encrypted with the shared KEY.
  • 8. The server is ready: The server sends a FINISHED message encrypted with the shared KEY.
  • 9. Secure communication: The handshake is completed and the two parties use symmetric encryption for secure communication.

Part of personal understanding

  • In order to prevent the certificate from being tampered with, the client decrypts the hash string using the public key and encrypts the certificate with the same digest algorithm. Then the hash string can be compared to verify whether the certificate is tampered with and the credibility of the certificate
  • The client generates A random A plaintext send server, the server to generate random B expressly, together with the certificate (contains the public key) send the client, the client has A public key, A randomly generated and encryption C to the server, the server decrypted, this time with ABC, on both sides agreed to shake hands with the first step of encrypted password combination algorithm, both sides can get the transport information symmetric key, This way you can encrypt your communications for secure communication