Interviewer: Do you understand secure data transmission?

Seeing this title, many people will say with certainty that they can answer this question! It is to use HTTPS for secure transmission.

Yes, it is excellent. Do you know how the underlying HTTPS ensures data security? Let’s move on to today’s topic: how HTTPS achieves secure data transmission.

[[343999]]

HTTPS Awareness

HTTPS is actually a security protocol consisting of HTTP + SSL protocols.

We know that the process from when we input the URL to when the page is presented is based on the HTTP protocol. The HTTP protocol ensures the basis for our network data transmission, but the security cannot be guaranteed. The SSL protocol can solve the security problem by acting on the Http protocol.

HTTPS guarantees the following three things:

• Data content encryption
• Data integrity protection (digital summary, digital signature)
• Identity Authentication

HTTPS security key points:

• Handshake phase: Use asymmetric encryption technology to encrypt the public key
• Transmission phase: Encrypt the message using symmetric encryption technology

Since HTTPS has an additional process of encrypting the public key using an asymmetric encryption algorithm, it takes longer to establish a connection than HTTP.

The handshake phase ensures that the connection is secure, so subsequent data transmission can be transmitted securely. Therefore, a less time-consuming symmetric encryption algorithm can be used to encrypt and transmit messages.

HTTPS deconstructed:

In the above picture, we can see the role of the SSL protocol. Before understanding the SSL protocol that ensures data security, let us first understand some concepts related to data security.

Encryption and decryption related concepts

1. Symmetric encryption

Aliases: private key encryption, single key algorithm, traditional cryptographic algorithm.

Concept: It means using the same key for encryption and decryption, so the decryption key can be deduced from the encryption key, and the encryption key can also be deduced from the decryption key.

Common symmetric encryption algorithms: DES (Data Encryption Standard), AES (Advanced Encryption Standard), RC4, IDEA

2. Asymmetric encryption

Aliases: Public Key Cryptography

Concept: The public key is open to the public, and the private key is stored in the hands of both ends of the communication. The client and the encrypted public key form a key pair, and the server and the encrypted public key form another key pair. The encryption and decryption keys are paired.

Limitation: The length of the encrypted content cannot exceed the length of the public key

3. Digital Abstract

Alias: Digital Fingerprint

Concept: The plaintext is a string of ciphertext of fixed length (128 bits) generated by a one-way hash function.

4. Digital Signature

Concept: Hybrid application of asymmetric key encryption technology and digital summaries

(1) Digital Signature Process

• The sender uses the hash function (H) to generate a digital summary A from the original text.
• The sender uses his own private key to encrypt the digital summary A and generate the ciphertext CypherA
• Send the ciphertext CypherA together with the original text to the receiver

(2) Digital signature verification (information integrity) process

• The receiver uses the hash function (H) to generate a digital summary B from the received original text (B === A, the H function is the same)
• The receiver uses the public key to decrypt the received encrypted ciphertext (CypherA) and obtains the digital summary B'
• Compare B' and B to see if they are equal. If they are equal, it means that the received information is complete and the message is indeed signed and sent by the sender (because the private key is only known to the sender), and has not been modified during the transmission process; otherwise, the information has been modified.

Finally, compare whether the digital summary A is equal to the digital summary A'. You can also use the Hash() function in reverse to restore the summary A' to get the plaintext, and compare whether the changed plaintext is consistent with the original text (both are pig).

Digital signature is an encryption process, and digital signature verification is a decryption process. A digital signature involves a hash function, the receiver's public key, and the sender's [private key].

(3) Pseudocode

 // Single-item Hash function
 function Hash (plainText) { // Pass in plain text parameters
 // Plaintext encryption process
  const encrypt encryptedAbstract = encrypt(plainText)
 // Returns a fixed-length (128-bit) digital digest
 return encryptedAbstract
 } 
 
 // The sender uses his own private key to encrypt the digital summary generated by the plaintext to generate the ciphertext CypherA
 function doEncrypt (senderPrivateKey, encryptedAbstract) {
  const CypherA = encrypt (senderPrivateKey, encryptedAbstract)
 return CypherA
 } 
 
 // Send message
 function sendMessage (plainText) {
  const encryptedAbstract = Hash (plainText)
  const CypherA = doEncrypt (senderPrivateKey, encryptedAbstract) // Encryption
 return {
 CypherText: CypherA,
 originText: plainText
 }
 } 
 
 // The receiver decrypts using the public key
 function doDecrypt (publicKey, encryptedAbstract) {
  const decrypt decryptedAbstract = decrypt(publicKey, encryptedAbstract)
 return decryptedAbstract
 } 
 
 // Receive message
 function receiveMessage (CypherA, plainText) {
  const encryptedAbstract = Hash (plainText)
  const decryptedAbstract = doDecrypt (publicKey, encryptedAbstract) // Decrypt
  if ( decryptedAbstract === encryptedAbstract) {
 console.log('1, the sender is true') // Confirmation from the sender of the message
 console.log('2, the message is complete') // Confirmation of message integrity
 }
 } 
 
 const message = sendMessage (plainText) // Digital signature process
 receiveMessage (message.CypherText, message.originText) // Digital signature authentication process

5. Digital Certificate

In the above digital signature process, how can we ensure that the public key is trustworthy? This is the necessity of digital certificates.

Digital certificates are mainly used for encryption, signature, and identity authentication.

Digital certificates are issued by a certification authority (CA). CA verifies the identity of the holder before issuing the certificate and when using the certificate. It enables the client to identify whether the public key comes from a legitimate server.

A certificate authority (CA) issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made public but is kept secret by the end user who generates the key pair. A certificate is also a confirmation or verification by the CA that the public key contained in the certificate belongs to the individual, organization, server, or other entity named in the certificate. The CA's obligation in such a scenario is to verify the applicant's credentials so that users and relying parties can trust the information in the CA's certificate.

When you visit a website using HTTPS (secure connection), the website's server will use a certificate to prove the identity of the website to the browser (such as Chrome). The public key information contained in the certificate is trustworthy. If the certificate does not exist, the certificate has been tampered with, or the certificate is invalid, the browser will prompt you in the upper left corner that the website is not secure.

Signature verification chain: client <- server <- CA

Contents of the digital certificate:

• Name of the certificate authority
• The digital signature of the certificate itself
• Certificate holder public key
• Hash algorithm used for certificate signing
• ... etc

Public Keys and Digital Signatures

After understanding these basic concepts, let's move on to today's topic: how the SSL protocol ensures secure data transmission.

SSL/TLS

1. SSL (Secure Socket Layer)

Use encryption technology to ensure that data cannot be stolen during network transmission.

2. TLS (Transport Layer Security)

Used to provide confidentiality and data integrity between two applications.

This protocol is based on the SSL3.0 protocol and can be considered as the SSL3.1 version. It just uses some more secure strategies based on SSL3.0 to make data more secure. Other protocol layers and functions are consistent with SSL. Those who are interested can learn about its differences and advantages over SSL.

The role of SSL/TLS protocol:

• Data encryption to prevent theft
• Protect the integrity of data and ensure that it cannot be altered
• Authentication, ensuring data is sent to the correct client and server

As you can see, these are the three points where the HTTPS protocol comes into play.

So, how does the SSL protocol encrypt our data for secure transmission?

3. SSL and TLS handshake process

(1) The client informs the server of the security protocol version (such as TLS1.0), encryption algorithm, compression method, and random number CRandom1 that it supports;

(2) The server responds for the first time and returns to the client the version of the security protocol, encryption algorithm, compression method, random number SRandom, and a digital certificate (server certificate);

(3) The client verifies the certificate sent by the server. After verification, it performs the following operations:

• The client generates a random number CRandom2 again
• Use the public key in the server certificate to encrypt the data and generate a random number CRandom3
• Send a ChangeCipherSpec (coding change) message notification (informing the server that I am ready to encrypt and transmit data using the encryption suite we agreed on before), the hash value of all previous messages, and the encrypted data CRandom3 for server verification
• Use the encryption algorithm confirmed with the server to encrypt the three random numbers CRandom1, CRandom2, and CRandom3 to generate a Session Secret (this is the symmetric encryption key used when the symmetric encryption algorithm is used to transmit data later, and can also be used for session recovery to save SSL handshake time)

(4) The server responds again:

• Use your own private key to decrypt CRandom3 and verify the decrypted data
• Send a ChangeCipherSpec (coding change) message notification (inform the client that I am also ready to encrypt data using the encryption suite and Session Secret we agreed on previously)
• Use Session Secret to encrypt a Finish message and send it to the client to verify whether the encryption and decryption channel established by handshake is successful.

After the above four steps, the client and the server have determined the key and can encrypt and transmit the message.

At this point, the handshake process ends.

The security of the entire handshake phase depends on whether the third random number CRandom3 can be cracked, because this random number is encrypted using the server's public key and decrypted using the server's private key; the private key is only stored on the server itself.

After all the handshake phases are completed, application data can be transmitted using symmetric encryption technology.

QA

1. How does the client verify the received certificate?

The certificate itself tells the client how to verify the authenticity of the certificate. In other words, the certificate tells how to generate a certificate number based on the content of the certificate. After receiving the certificate, the client generates a certificate number according to the method on the certificate. If the generated certificate number is the same as the certificate number on the certificate, then the certificate is authentic.

2. The security of the public key is confirmed by the certificate, but the certificate is issued by the issuing authority. How to confirm that the issuer is trustworthy?

Through the certificate chain.

• root: Root certificate, a digital certificate issued by a certificate authority (CA) to itself, that is, it authenticates itself. In the above figure, the root certificate is issued by DigiCert Global Root CA itself.
• Intermediates: Intermediate certificates. The root CA generates a pair of public and private keys, and uses the private key to "encrypt" the information of the intermediate CA and the public key to generate a signature, which is then encapsulated to obtain an intermediate certificate. It should be noted that there may be more than one intermediate CA. The upper-level CA also issues certificates to the lower-level CA according to this logic. Here, the intermediate CA is RapidSSL RSA CA 2018, which issues certificates to end users.
• end-user: end user (certificate). The end certificate in the figure is the digital certificate used by *.juejin.im.

It can be seen that the certificate chain is composed of multiple certificates layer by layer. The public key of the terminal certificate is used to encrypt messages for users, and the public keys in the certificates of other layers are used to decrypt the fingerprint signature of the certificate of the next layer. The root certificate of the highest layer is self-signed, that is, it is issued to itself, so the root certificate must be credible (can't you trust yourself?^^)

Summarize

The secure transmission of data over the network relies on the SSL protocol, and the network transmission protocol is HTTP, which constitutes the HTTPS protocol. To ensure efficient communication security between the client and the server, HTTPS must use a symmetric encryption algorithm, but the process of negotiating the symmetric encryption algorithm requires the use of an asymmetric encryption algorithm to ensure security. However, the process of directly using asymmetric encryption is not safe in itself, and there is a possibility that the middleman will tamper with the public key. Therefore, the client and the server do not directly use the public key, but use a certificate issued by a digital certificate issuing agency to ensure the security of the asymmetric encryption process itself.

In this way, a symmetric encryption algorithm is negotiated through these mechanisms, and both parties use the algorithm to encrypt and decrypt data during transmission, thus solving the communication security problem between the client and the server.