How does HTTPS ensure web security? (code example)

The content of this article is about how HTTPS ensures Web security? (Code sample) has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

HTTPS (full name: HyperText Transfer Protocol over Secure Socket Layer) is to ensure the security of data transmission between the client and the server. In the past two years, Internet giants such as Google, Baidu, and Facebook have begun to vigorously promote HTTPS. Many large Internet companies at home and abroad have also enabled full-site HTTPS. This is also the future development trend of the Internet. As For front-end engineers, understanding the principles of HTTPS is also a required course.
2019 is not far away from the use of HTTPS on the entire network. Here are a few requirements put forward by major Internet companies to encourage the use of HTTPS:
1. Google’s search engine algorithm allows websites that use HTTPS to be used in searches Ranked higher;
2. Apple requires that all applications in the App Store must use HTTPS encrypted connections;
3. WeChat mini programs also require the use of HTTPS protocol;
4. A new generation of HTTP/ 2 The support for the protocol needs to be based on HTTPS;
5. The new version of chrome has marked the HTTP protocol website as unsafe

Hidden danger: Why add S to HTTP?

The HTTP protocol has been quite excellent and convenient since its birth. However, HTTP does not only have good sides. Everything has two sides, and its shortcomings are also obvious:

• Communication is transmitted in clear text, and the content may be eavesdropped

• The identity of the communicating party is not verified, so it is possible to encounter masquerading

• The integrity of the message cannot be proven, so it may have been tampered with.

In addition, HTTP itself has many shortcomings. Moreover, there are also deficiencies (which can also be said to be vulnerabilities or security holes) in actual applications of certain specific web servers and specific web browsers. In addition, web applications developed with programming languages ​​such as Java and PHP There may also be security vulnerabilities.

1. Communication using plain text may be eavesdropped

Since HTTP itself does not have the encryption function, it cannot be used to protect the entire communication (communication using the HTTP protocol) request and response content) are encrypted. Therefore, HTTP messages are sent in clear text. If you want to ask why not encrypting communication is a disadvantage, it is because, according to the working mechanism of the TCP/IP protocol suite, the communication content may be peeped on all communication lines.
The so-called Internet is composed of networks that can be connected to the whole world. No matter where the server in the world is communicating with the client, some network equipment, optical cables, computers, etc. on this communication line cannot be individuals. private property, so it is not ruled out that malicious peeping may occur at some point.
Even if the communication has been encrypted, the communication content will be peeked into, which is the same as the unencrypted communication. It just means that if the communication is encrypted, it may be impossible to decipher the meaning of the message information, but the encrypted message itself will still be seen.
Eavesdropping on communications on the same segment is not difficult. Just collect the data packets flowing on the Internet. The analysis of the collected data packets can be left to those packet capture or sniffing tools.

2. If the identity of the communicating party is not verified, it may be disguised.

The request and response in the HTTP protocol will not confirm the communicating party. In other words, there are similar issues such as "whether the server is the host actually specified by the URI in the request, and whether the returned response is really returned to the client that actually made the request."
During HTTP protocol communication, since there is no processing step to confirm the communicating party, anyone can send a request. At the same time, as long as the server receives the request, as long as the IP address and port number of the sending end are not restricted by the Web server. , no matter who the other party is, a response will be returned, so there will be various hidden dangers:

• It is impossible to determine whether the web server that the request is sent to the target is the server that returns the response according to the true intention. , it may be a disguised web server.

• It is impossible to determine whether the client returned by the response is the client that received the response according to the true intention. It may be a disguised client.

• Unable to determine whether the other party being communicated has access rights. Because some web servers store important information that points to permissions for communications sent to specific users.

• It is impossible to determine where the request came from and who made it.

• Even if the request is meaningless, it will be accepted in full. Unable to prevent DoS attacks (Denial of Service, Denial of Service attacks) under massive requests.

3. The integrity of the message cannot be proven and may have been tampered

The so-called integrity refers to the accuracy of information. Failure to demonstrate its completeness usually means that it cannot be judged whether the information is accurate.
Therefore, during the period after the request or response is sent and before the other party receives it, there is no way to know even if the request or corresponding content has been tampered with.
In other words, there is no way to confirm that the request and response sent are the same as the request and response received. The file content may have been changed to other content during transmission. In this case, an attack in which the request or response is intercepted by an attacker during transmission and tamper with the content is called a Man-in-the-Middle attack (MITM).

Solution: HTTP encryption authentication integrity protection = HTTPS

With so many HTTP shortcomings mentioned above, naturally we have to solve them in HTTPS. Let’s take a look. How HTTPS ensures the security of our data transmission.

1. HTTPS is actually HTTP wrapped in an SSL shell

HTTPS is not a new protocol at the application layer. The HTTP communication interface part is replaced by SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols.
Usually, HTTP communicates directly with TCP. When using SSL, it becomes communicating with SSL first, and then SSL communicates with TCP. Simply put, HTTP used in combination with SSL is called HTTPS (HTTP Secure, Hypertext Transfer Security Protocol) or HTTP over SSL.
After adopting SSL, HTTP has the encryption, certificate and integrity protection functions of HTTPS. SSL is a protocol independent of HTTP, so not only the HTTP protocol, but other protocols such as SMTP and Telnet that run at the application layer can be used with the SSL protocol. It can be said that SSL is the most widely used network security technology in the world today.

The encryption principle of HTTPS

In modern encryption algorithms, the encryption algorithm is public, and the encryption algorithm is public. The key is kept secret. In this way the security of the encryption method is maintained.

Encryption and decryption require a key. If there is no key, there is no way to decrypt the password. In other words, anyone with the key can decrypt the ciphertext.

HTTPS uses asymmetric encryption technology and symmetric encryption technology in the encryption process.

Symmetric encryption algorithm

Adopts the encryption method of single-key cryptography system. The same key can encrypt and decrypt information at the same time. This encryption method is called symmetric encryption, also known as Single key encryption.

The symmetric encryption algorithm will be called the shared key encryption algorithm below.

Suppose now, SSL uses a symmetric encryption algorithm during the communication process, which means that the client and the server share a key at the same time.

So, to encrypt using a shared key, the key must be sent to the other party. At this time, if the communication process is monitored and the key is obtained by the attacker, then the meaning of encryption will be lost at this time.

So, is there any way to solve this problem? The answer is yes, that is, use two keys.

Let’s first look at the asymmetric encryption algorithm using two keys.

Asymmetric encryption algorithm

Contrary to the symmetric encryption algorithm, the asymmetric encryption algorithm requires two keys for encryption and decryption. These two keys are paired, namely the public key and the public key. key (public key) and private key (private key).

Generally, the public key can be made public and is mainly used to encrypt plain text. Correspondingly, the private key cannot be made public and is used to decrypt ciphertext encrypted by the public key.

It is worth noting that the ciphertext encrypted by the public key can only be decrypted by the corresponding private key, but the ciphertext encrypted by the private key can be decrypted by the corresponding public key.

Above, public key encryption and private key decryption are used for encryption, and private key encryption and public key decryption are used for signature. Related uses will be discussed later.

The asymmetric encryption algorithm will be called the public key encryption algorithm below.

So now, assume that the server now generates a pair of public key and secret key.

When the client sends a request to negotiate with the server for the first time, the server generates a pair of public and private keys.

Next, the server sends the public key to the client (plain text, no encryption is required). After receiving it, the client randomly generates a key and uses the public key sent by the server for encryption.

Then, the client sends the key encrypted with the public key to the server. After the server receives it, it uses the paired private key to decrypt it and obtains the key randomly generated by the client.

At this time, the keys held by the client and the server are the same. At this point, the key exchange process is completed.

So when communication starts, the shared key encryption method described above can be used to encrypt.

Use at the same time

Possibly, some friends will ask, why go to all the trouble to use asymmetric encryption, and then obtain the same key for shared key encrypted communication Woolen cloth?

Since public key encryption is more complex to process than shared key encryption, the efficiency of using public key encryption during communication is very low.

So, we need to use asymmetric encryption to ensure the security of the key during the key sharing process, and then use the symmetric encryption algorithm during the communication process. This is the most reasonable design method. It ensures safety while ensuring performance.

Therefore, HTTPS adopts a hybrid encryption mechanism that uses both shared key encryption and public key encryption. Public key encryption is used in the key exchange phase, and shared key encryption is used in the subsequent communication message exchange phase.

The above is probably the process of using symmetric encryption and asymmetric encryption. It seems that the process is perfect, but there is still a problem: how to ensure the correctness of the public key passed by the server. In other words, it is to ensure that it cannot be intercepted and tampered with.

Use certificates to ensure the correctness of the public key

If you are now preparing to establish communication with a server using public key encryption, how to prove that the client has received The public key is the public key issued by the server as originally expected? Perhaps, during the transmission of the public key, the real public key may have been replaced by the attacker.

To solve this problem, you can use public key certificates issued by digital certificate authorities and their related ones.

The following describes the business process of the Digital Certificate Certification Authority (CA):

First, the server operator applies for a public key to the Digital Certificate Authority. After the digital certificate certification authority determines the identity of the applicant, it will digitally sign the applied public key, then distribute the signed public key, put the public key into the public key certificate and bind it to Together.

Let’s translate the above paragraph in vernacular:
First, the CA will issue a certificate to the applicant. The contents of this certificate include: the issuer, the purpose of the certificate, and what is included with the server application. Public key, server encryption algorithm, HASH algorithm used, certificate expiration time, etc.
Next, perform a HASH evaluation on the content mentioned above to get a HASH value.

Then, use the CA’s private key to encrypt, thus completing the digital signature. After encrypting with the CA's private key, a signature similar to a human fingerprint is generated. Any attempt to tamper with the certificate will be discovered by the digital signature.
Finally, attach the digital signature to the end of the digital certificate and transmit it back to the server.
Next, the server will send the public key certificate issued by the digital certificate certification authority to the client. At this time, the client can use the public key of the digital certificate authority to verify it. Once the verification is successful, the client can be sure that the public key is trusted.

Let’s translate it in vernacular:
After the client obtains this digital certificate, it can use the public key corresponding to the CA private key to decrypt the digital signature at the end of the digital certificate and obtain the original HASH value.
Next, the client calculates the HASH value for the content of the certificate according to the HASH algorithm in the certificate. If the HASH value decrypted by the CA public key is the same as the HASH value obtained by calculation, then the authentication passes, otherwise it fails.
If the authentication passes, you can obtain the server's public key.

Where does the CA public key on the client come from?
When most browser developers release versions, they will internally implant the public keys of commonly used certification authorities in advance. In this way, it is convenient for the client to verify the authenticity of the digital certificate.

The specific process is like this (the process of digital signature is simplified in the picture):

It is actually used here Asymmetric encryption algorithm, except now this encryption algorithm is used for signature instead of encryption.

Use private key encryption and public key decryption. It is used by the holder of the public key to verify whether the content encrypted by the private key has been tampered with, but it is not used to ensure whether the content has been obtained by others.

Using public key encryption and private key decryption is the opposite. It does not guarantee that the information will be intercepted and tampered with by others, but it does guarantee that the information cannot be obtained by the middleman.

Client certificate

Not only server certificates can be used in HTTPS, but also client certificates can be used. Use client certificate for client authentication, which has the same function as server certificate.

Since the client needs to install the client certificate to obtain the certificate, it also faces the problem of cost.

Therefore, the current situation is that extremely high-security certification authorities can obtain client certificates but only for special-purpose services. For example, those businesses that can support the cost of client certificates.

For example, the bank’s online banking uses client certificates. When logging into online banking, the user is not only required to confirm the input of ID and password, but also the user's client certificate is required to confirm whether the user accesses online banking from a specific terminal.

Secure communication mechanism of HTTPS

In order to better understand HTTPS, Xiaosi drew the following picture for everyone to observe the communication steps of HTTPS:

Step 1 : The client starts SSL communication by sending a Client Hello message. The message contains the specified version of SSL supported by the client and a list of encryption components (the encryption algorithm used, key length, etc.).

Step 2: When the server can perform SSL communication, it will respond with a Server Hello message. Like the client, the SSL version and encryption components are included in the message. The contents of the server's cryptographic component are filtered out from the received client's cryptographic component.

Step 3: The server then sends the Certificate message. The message contains a public key certificate.

Step 4: Finally, the server sends a Server Hello Done message to notify the client that the initial phase of the SSL handshake negotiation is over.

Step 5: After the first SSL handshake is completed, the client responds with a Client Key Exchange message. The message contains a random password string called Pre-master secret used in communication encryption. The message has been encrypted with the public key from step 3.

Step 6: Then the client continues to send Change Cipher Spec messages. This message will prompt the server that communications after this message will be encrypted using the Pre-master secret key.

Step 7: The client sends a Finished message. This message contains the overall validation value of all messages connected so far. Whether this handshake negotiation can succeed depends on whether the server can correctly decrypt the message.

Step 8: The server also sends a Change Cipher Spec message.

Step 9: The server also sends a Finished message.

Step 10: After the exchange of Finished messages between the server and the client, the SSL connection is established. Of course, the communication will be protected by SSL. From here, communication with the application layer protocol begins, that is, sending HTTP requests.

Step 11: Application layer protocol communication, that is, sending HTTP response.

Step 12: Finally the client disconnects. When disconnecting, a close_notify message is sent. Some omissions have been made in the above figure. After this step, a TCP FIN message is sent to close the communication with TCP.

In the above process, when the application layer sends data, it will append a message digest called MAC (Message Authentication Code). MAC can check whether the message has been tampered with, thereby protecting the integrity of the message.

Now there is a question, what is the use of the three random numbers generated in the whole process? Also, when conducting HTTP communication later, which key is used for encryption, and how to ensure the integrity of the message.

Look at the picture below.

For the client:

After generating the Pre-master secret, it will combine the original A and B random numbers , use the DH algorithm to calculate a master secret, and then derive the hash secret and session secret based on this master secret.

For the server:

After decrypting and obtaining the Pre-master secret, it will combine the original A and B random numbers and use the DH algorithm to calculate a master secret, and then use this The master secret derives the hash secret and session secret.

The master secret on the client and server is derived based on three random numbers. It will not be transmitted on the network. Only both parties know it, and no third party will know it. At the same time, the session secret and hash secret derived by the client are exactly the same as those of the server.

So now if both parties start to use symmetric algorithm encryption to communicate, which one will be used as the shared key? The process is like this:

Both parties use a symmetric encryption algorithm to encrypt, use hash secret to perform an operation on the HTTP message to generate a MAC, attach it to the end of the HTTP message, and then use session-secret to encrypt all data. (HTTP MAC) and then send.

The receiver first uses the session-secret to decrypt the data, then obtains the HTTP MAC, and then uses the same algorithm to calculate its own MAC. If the two MACs are equal, it proves that the data has not been tampered with.

At this point, the entire process is introduced.

The above is the detailed content of How does HTTPS ensure web security? (code example). For more information, please follow other related articles on the PHP Chinese website!