Shulou(Shulou.com)06/01 Report--

What is the working principle of HTTPS? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

HTTPS needs a handshake between the client (browser) and the server (website) before transmitting data, and the password information of the encrypted data transmitted by both parties will be established in the handshake process. The TLS/SSL protocol is not only a set of encrypted transmission protocols, but also a work of art carefully designed by artists. Asymmetric encryption, symmetric encryption and HASH algorithms are used in TLS/SSL. The handshake process is described as follows:

1. The browser sends a set of encryption rules that it supports to the website.

two。 The website selects a set of encryption algorithms and HASH algorithms, and sends its identity information back to the browser in the form of a certificate. The certificate contains information such as the address of the website, the encrypted public key, and the authority of the certificate.

3. After the browser obtains the website certificate, the browser should do the following work:

A) verify the validity of the certificate (whether the authority issuing the certificate is legal, whether the address of the website contained in the certificate is the same as the address being visited, etc.), and if the certificate is trusted, a small lock will be displayed in the browser bar, otherwise it will be prompted that the certificate is not trusted.

B) if the certificate is trusted, or if the user accepts an untrusted certificate, the browser generates a random password and encrypts it with the public key provided in the certificate.

C) calculate the handshake message using the agreed HASH algorithm, encrypt the message with the generated random number, and finally send all the previously generated information to the website.

4. After receiving the data from the browser, the website should do the following:

A) use your own private key to decrypt the information and take out the password, use the password to decrypt the handshake message sent by the browser, and verify that the HASH is consistent with the message sent by the browser.

B) encrypt a handshake message with a password and send it to the browser.

5. The browser decrypts and calculates the HASH of the handshake message. If it is consistent with the HASH sent by the server, the handshake process ends, and then all communication data will be encrypted by the random password generated by the previous browser and encrypted by the symmetric encryption algorithm.

Here, browsers and websites send encrypted handshake messages to each other and verify, in order to ensure that both sides get the same password, and can encrypt and decrypt data normally, and do a test for subsequent real data transmission. In addition, the encryption and HASH algorithms commonly used by HTTPS are as follows:

Asymmetric encryption algorithm: RSA,DSA/DSS

Symmetric encryption algorithm: AES,RC4,3DES

HASH algorithm: MD5,SHA1,SHA256

The communication sequence diagram for HTTPS is as follows:

The difference between HTTPS and HTTP:

Https agreement needs to apply for a certificate from ca. Generally, there are few free certificates and a fee is required.

Http is a hypertext transfer protocol, information is plaintext transmission, and https is a secure ssl encrypted transmission protocol.

Http and https use completely different connections and different ports, the former being 80 and the latter 443.

The connection to http is simple and stateless.

HTTPS protocol is a network protocol built by SSL+HTTP protocol for encrypted transmission and identity authentication, which is more secure than http protocol.

1. Establish a connection protocol (three-way handshake)

(1) the client sends a TCP message with the SYN flag to the server. This is message 1 during the three-way handshake.

(2) when the server responds to the client, this is the second message in the three-way handshake, which carries both the ACK flag and the SYN flag. Therefore, it expresses the response to the client SYN message just now; at the same time, it marks SYN to the client, asking whether the client is ready for data communication.

(3) the customer must respond to an ACK message in the service segment again, which is message segment 3.

Why do you need "three-way handshake"

In the fourth edition of computer Network, Xie Xiren said that the purpose of the "three-way handshake" is "to prevent the invalid connection request message from suddenly being transmitted to the server, resulting in an error." In another classic "computer Network", the purpose of "three-way handshake" is to solve the problem of "delayed repeated packets in the network". These two unnecessary expressions actually clarify the same problem.

The example in Xie Xiren's edition of "computer Network" is that the "invalid connection request message segment" is generated in a case where the first connection request message segment sent by client is not lost, but is held up at a network node for a long time, so that it is delayed to reach server until some time after the connection is released. Originally, this is a message segment that has long been invalid. However, after server received this invalid connection request message segment, it was mistaken for a new connection request sent by client again. A confirmation message was sent to client, agreeing to establish a connection. Assuming that the "three-way handshake" is not used, a new connection is established as soon as the server issues an acknowledgment. Since client does not make a request to establish a connection at this time, it ignores the confirmation of server and does not send data to server. But server thinks that a new shipping connection has been established and has been waiting for data from client. In this way, many of the resources of server are wasted. The above phenomenon can be prevented by using the method of "three-way handshake". For example, in the case just now, client does not issue a confirmation to server's confirmation. Because server does not receive confirmation, it knows that client does not require the establishment of a connection. ". The main purpose is to prevent the server side from waiting and wasting resources.

2. Connection termination agreement (four waves)

Because the TCP connection is full-duplex, each direction must be closed separately. The principle is that when a party finishes its data sending task, it can send a FIN to terminate the connection in this direction. Receiving a FIN simply means that there is no data flow in this direction, and an TCP connection can still send data after receiving a FIN. The first party to perform the shutdown will perform an active shutdown, while the other party will perform a passive shutdown.

(1) the TCP client sends a FIN to turn off client-to-server data transmission (message segment 4).

(2) the server receives this FIN, and it sends back an ACK confirming that the sequence number is the received sequence number plus 1 (message segment 5). Like SYN, a FIN will take a sequence number.

(3) the server closes the connection of the client and sends a FIN to the client (message segment 6).

(4) the client segment sends back the ACK message confirmation, and sets the confirmation sequence number to receive the sequence number plus 1 (message segment 7).

Why do you need "four waves"?

Then some people may wonder why ACK is sent with SYN while ACK is not sent with FIN when shaking hands with tcp connection. The reason is that because tcp is in full-duplex mode, receiving FIN means that no data will be sent again, but you can continue to send data.

Introduction of each state during handshake and waving (see wiki:TCP for details)

3-way handshake process status:

LISTEN: this is also a state that is very easy to understand, indicating that some SOCKET on the server side is listening and can accept connections.

SYN_SENT: when the client SOCKET performs a CONNECT connection, it first sends the SYN message, so it then enters the SYN_SENT state and waits for the server to send the second message in the three-way handshake. The SYN_SENT status indicates that the client has sent a SYN message. (sender)

SYN_RCVD: this state echoes SYN_SENT remote vision. This state indicates that the SYN message has been received. Under normal circumstances, this state is an intermediate state during the three-way handshake session of the server-side SOCKET when establishing a TCP connection. It is very short. Basically, it is very difficult to see this state with netstat, unless you specifically write a client-side test program. The last TCP message during the three-way ACK handshake is deliberately not sent. Therefore, in this state, when receiving the ACK message from the client, it will enter the ESTABLISHED state. (server side)

ESTABLISHED: this is easy to understand, indicating that a connection has been established.

4 waving process status: (please refer to the figure above)

FIN_WAIT_1: this state should be well explained. In fact, the real meaning of FIN_WAIT_1 and FIN_WAIT_2 status is to wait for each other's FIN message. The difference between these two states is that when the SOCKET is in the ESTABLISHED state, it wants to close the connection actively and sends a FIN message to the other party, the SOCKET enters the FIN_WAIT_1 state. When the other party responds to the ACK message, it enters the FIN_WAIT_2 state. Of course, under the actual normal circumstances, no matter what the other party's circumstances are, he should respond to the ACK message immediately, so the FIN_WAIT_1 status is generally difficult to see, while the FIN_WAIT_2 status can sometimes be seen with netstat. (active party)

FIN_WAIT_2: this state has been explained in detail above. In fact, SOCKET in FIN_WAIT_2 state means semi-connection, that is, one party asks for a close connection, but also tells the other party that I still have some data to send to you (ACK information) for the time being, and then close the connection later. (active party)

TIME_WAIT: it means that you have received the FIN message from the other party and sent the ACK message. After waiting for 2MSL, you can return to the available state of CLOSED. If you receive a message with both the FIN flag and the ACK flag in the FIN_WAIT_1 state, you can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state. (active party)

CLOSING (relatively rare): this state is relatively special, should be rare in the actual situation, and is a relatively rare exception. Under normal circumstances, when you send a FIN message, you should first receive (or at the same time) the other party's ACK message, and then receive the other party's FIN message. But the CLOSING status indicates that after you send the FIN message, you do not receive the other party's ACK message, but also receive the other party's FIN message. Under what circumstances will this happen? In fact, if you think about it, it is not difficult to draw a conclusion: if both parties are close a SOCKET at almost the same time, then both parties will send FIN messages at the same time, that is, a CLOSING status will appear, indicating that both parties are closing the SOCKET connection.

CLOSE_WAIT: this state actually means that you are waiting for a shutdown. How do you understand it? When the other party close a SOCKET and send a FIN message to yourself, your system will no doubt respond to an ACK message to the other party, and then enter the CLOSE_WAIT state. Next, in fact, what you really need to consider is to see if you still have data to send to the other party. If not, you can also close the SOCKET, send the FIN message to the other party, that is, close the connection. So when you are in CLOSE_WAIT, all you need to do is wait for you to close the connection. (passive party)

LAST_ACK: this state is relatively easy to understand. It is a passive shutdown party that sends a FIN message and finally waits for the other party's ACK message. When you receive the ACK message, you can enter the CLOSED available state. (passive party)

CLOSED: indicates that the connection is broken.

For more information on the status diagram of TCP, please see:

After reading the above, have you mastered how HTTPS works? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.