Fun with HTTPS

Preface

Recently I was reading the book "Illustrated HTTP", and today I will learn about HTTPS.

text

HTTP

HTTP mainly has these shortcomings:

• The communication uses plain text (not encrypted), the content may be eavesdropped
• The identity of the communicating party is not verified, so it is possible to encounter masquerading
• Unable to prove the integrity of the message, so it may have been tampered with

These problems not only occur on HTTP, but also in other unencrypted protocols.

plaintext used in communication may be eavesdropped

Since HTTP itself does not have the function of encryption, it is also impossible to encrypt the entire communication (the content of the request and response of the communication using the HTTP protocol). That is, HTTP messages are sent in plain text (referring to unencrypted messages) to .

Even if the communication has been encrypted, the content of the communication will be peeped, which is the same as the unencrypted communication. It just means that if the communication is encrypted, it may be impossible for people to decipher the meaning of the message information, but the encrypted message information itself will still be seen.

may encounter masquerading without verifying the identity of the communicating party

The request and response in the HTTP protocol will not confirm the communicating party. That is to say, there are similar questions such as "whether the server is the host actually specified by the URI in the sending request, and whether the returned response is really returned to the client that actually made the request".

• Anyone can initiate a request

In HTTP protocol communication, since there is no processing step to confirm the communicating party, anyone can initiate a request. In addition, as long as the server receives the request, no matter who the other party is, it will return a response (but only on the premise that the IP address and port number of the sender are not restricted by the Web server settings)

The implementation of the HTTP protocol itself is very simple, no matter who sends the request will return a response, so if the communication party is not confirmed, there will be the following hidden dangers.

1. It is impossible to determine whether the Web server that the request is sent to the target is the one that returned the response as it really intended. It may be a disguised Web server.
2. It cannot be determined whether the client to which the response is returned is the one that received the response as it really intended. It may be a disguised client.
3. It is impossible to determine whether the communicating party has access rights. Because some web servers store important information, they only want to send specific users the communication authority.
4. It is not possible to determine where the request came from and who made it.
5. Even meaningless requests will be accepted in full. Unable to prevent DoS attacks (Denial of Service, denial of service attacks) under massive requests.

• Identify the opponent's certificate

Although the communication party cannot be determined using the HTTP protocol, it is possible if SSL is used. SSL not only provides encryption, but also uses a method called a certificate, which can be used to determine the party. The certificate is issued by a trusted third-party organization to prove that the server and client actually exist. In addition, forging certificates is extremely difficult from a technical point of view. Therefore, as long as the certificate held by the communicating party (server or client) can be confirmed, the true intention of the communicating party can be judged.

Through the use of certificates, it is proved that the communicating party is the expected server. This also reduces the risk of personal information leakage for individual users.

In addition, the client can complete the verification of personal identity by holding the certificate, and it can also be used for the authentication link of the Web site.

Unable to prove the integrity of the message, it may have been tampered

The so-called completeness refers to the accuracy of information. Failure to prove its integrity usually means that it is impossible to judge whether the information is accurate.

• The received content may be wrong

Since the HTTP protocol cannot prove the integrity of the communication message, after the request or response is sent and before the other party receives it, even if the content of the request or response is tampered with, there is no way to know. In other words, there is no way to confirm that the sent request/response and the received request/response are the same before and after.

Like this, the attack in which the request or response is intercepted and tampered with the content during transmission is called a Man-in-the-Middle attack (MITM)

Although there is a method to determine the integrity of a message using the HTTP protocol, it is in fact not convenient and reliable. The commonly used methods are MD5 and SHA-1 hash value verification methods, as well as digital signature methods used to verify files. In order to effectively prevent these drawbacks, it is necessary to use HTTPS. SSL provides authentication and encryption processing and digest functions. It is very difficult to only rely on HTTP to ensure integrity, so it can be used in combination with other protocols to achieve this goal.

HTTP + encryption + authentication + integrity protection = HTTPS

HTTP plus encryption processing, authentication and integrity protection is HTTPS

For HTTP, whether the server or the client, there is no way to confirm the communication party. Because it is very likely that it is not actually communicating with the originally intended communicating party. And also need to consider the possibility that the received message has been tampered with during the communication. In order to solve these problems in a unified manner, it is necessary to add encryption processing and authentication mechanisms to HTTP. We call HTTP with encryption and authentication mechanism added as HTTPS (HTTP Secure) .

HTTPS communication is often used on the web login page and shopping settlement interface. When using HTTPS communication, http:// is https:// is used instead. In addition, when the browser accesses a Web site with valid HTTPS communication, a lock mark will appear in the address bar of the browser. The way of displaying HTTPS will vary depending on the browser.

HTTPS is HTTP with an SSL shell

HTTPS is not a new protocol at the application layer. It's just that the HTTP communication interface part is replaced by SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols.

Normally, HTTP communicates directly with TCP. When using SSL, it evolves to communicate with SSL first, and then communicate with SSL and TCP. In short, the so-called HTTPS is actually HTTP in the shell of the SSL protocol.

After adopting SSL, HTTP has the functions of encryption, certificate and integrity protection of HTTPS.

SSL is a protocol independent of HTTP, so not only the HTTP protocol, but other protocols such as SMTP and Telnet running 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.

Public key encryption technology for mutual exchange of keys

Before explaining SSL, let's first understand the encryption method.

SSL uses an Public-key cryptography. In modern encryption methods, the encryption algorithm is public, but the key is kept secret. In this way, the security of the encryption method can be maintained. Both encryption and decryption use keys. Without the key, the password cannot be decrypted. On the other hand, anyone can decrypt it as long as they hold the key. If the key is obtained by an attacker, then encryption loses its meaning

• The dilemma of shared key encryption

The method of using the same key for encryption and decryption is called common key crypto system, also known as symmetric key encryption.

When encrypting with a shared key, the key must also be sent to the other party. But how can it be safely transferred? When the key is forwarded on the Internet, if the communication is monitored, the key may fall into the hands of an attacker, and at the same time it will lose the meaning of encryption. In addition, we must try to safely keep the received key.

• uses the public key of two keys to encrypt

The public key encryption method solves the difficulty of shared key encryption. public key encryption uses a pair of asymmetric keys. One is called private key, and the other is called public key. As the name implies, the private key cannot be known to anyone else, while the public key can be released at will and anyone can obtain it.

uses public key encryption. The party sending the ciphertext uses the other party's public key for encryption. After the other party receives the encrypted information, it uses its own private key for decryption. does not need to send the private key for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker.

In addition, it is extremely difficult to restore the original information based on the ciphertext and the public key, because the decryption process is evaluating the discrete logarithm, which is not easy to do. Taking a step back, if a very large integer can be factored quickly, there is still hope for password cracking. But in terms of current technology, it is not realistic.

• HTTPS uses a hybrid encryption mechanism

HTTPS adopts a hybrid encryption mechanism that uses both shared key encryption and public key encryption.

If the key can be exchanged securely, then it is possible to consider using only public key encryption for communication. However, compared with shared key encryption, public key encryption has a slower processing speed. So we should make full use of their respective advantages and combine multiple methods for communication. uses public key encryption in the key exchange process, and uses shared key encryption in the subsequent phases of establishing communication and exchanging messages.

Certificate to prove the correctness of the public key

Unfortunately, there are still some problems with public key encryption. That is, it is impossible to prove that the public key itself is a genuine public key. For example, when preparing to establish a public key encryption communication with a certain server, how to prove that the public key received is the public key issued by the originally expected server. Perhaps during the transmission of the public key, the real public key has been replaced by the attacker.

In order to solve the above problems, you can use digital certificate certification authority (CA, Certificate Authority) and its related agencies. The digital certificate certification authority is in the position of a third-party organization that can be trusted by both the client and the server.

Let's introduce the business process of digital certificate certification authority:

First, the operator of the server submits an application for the public key to the digital certificate certification authority. After the digital certificate certification authority has determined the identity of the applicant, it will digitally sign the applied public key, then distribute the signed public key, and put the public key into the public key certificate and bind it to Together. The server will send this public key certificate issued by the digital certificate authority to the client for public key encryption communication. Public key certificates can also be called digital certificates or directly called certificates.

The client receiving the certificate can use the public key of the digital certificate certification authority to verify the digital signature on that certificate. Once the verification is passed, the client can clarify two things:
First, the public key of the authentication server is a real and effective digital certificate certification authority.
Second, the server's public key is trustworthy.

Here the public key of the certification authority must be safely transferred to the client. When using the communication method, how to transfer it safely is a very difficult task. Therefore, when most browser developers release the version, they will implant the public key of the commonly used certification authority in advance.

HTTPS secure communication mechanism

In order to better understand HTTPS, let's 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, a list of encryption components (Cipher Suite) (the encryption algorithm and key length used, etc.).

Step 2: When the server is available for 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 content of the encryption component of the server is filtered from the received encryption component of the client.

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

Step 4: Finally, the server sends a Server Hello Done message to notify the client that the initial SSL handshake negotiation part ends.

Step 5: After the first SSL handshake ends, 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 in step 3.

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

Step 7: The client sends a Finished message. This message contains the overall check value of all messages connected so far. Whether the handshake negotiation can be successful is determined by 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 Finished messages of the server and the client are exchanged, the SSL connection is established. Of course, the communication will be protected by SSL. From here, the communication of the application layer protocol is started, that is, an HTTP request is sent.

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

Step 12: Finally, the client disconnects. When the connection is disconnected, a close_notify message is sent. The above figure has made some omissions. After this step, send a TCP FIN message to close the communication with TCP. In the above process, when the application layer sends data, a message digest called MAC (Message Authentication Code) is attached. MAC can find out whether a message has been tampered with, thereby protecting the integrity of the message.

The following is a diagram of the entire process. The figure illustrates the entire process of establishing HTTPS communication using only the server-side public key certificate (server certificate).

HTTPS also has some problems, that is, uses SSL, its processing speed will slow down .

There are two types of SSL slowness. One is slow communication. The other refers to the slow processing speed due to the massive consumption of resources such as CPU and memory. Compared with using HTTP, the network load may be 2 to 100 times slower. In addition to connecting with TCP and sending HTTP request responses, SSL communication is also required, so the overall processing traffic will inevitably increase.

Another point is that SSL must be encrypted. Both the server and the client need to perform encryption and decryption operations. Therefore, as a result, it consumes more hardware resources of the server and client than HTTP, resulting in increased load.

There is no fundamental solution to the problem of slower speed. We will use SSL accelerator (dedicated server) hardware to improve the problem. This hardware is dedicated for SSL communication. Compared with software, it can increase the calculation speed of SSL by several times. The SSL accelerator functions only during SSL processing to share the load.

Summarize

Today's knowledge about HTTPS is here to learn.

Reference: "Graphic HTTP"