It’s better not to work for this kind of company!

[[415021]]

Hello everyone, I am Xiaolin. Last week, a reader encountered this question during an interview:

The interviewer told him that the TLS handshake process in HTTPS can perform three handshakes at the same time. Then, the reader had read my article before and it said "first perform TCP three-way handshake, then perform TLS four-way handshake". He told this to the interviewer, and the interviewer said he was wrong, so he felt very confused.

Let’s not worry about whether what the interviewer said, “The TLS handshake process in HTTPS can perform three handshakes at the same time” is correct.

However, the interviewer said that "the process of establishing an HTTPS connection first performs a TCP three-way handshake, and then a TLS four-way handshake", which is wrong. It is obvious that the interviewer's level is problematic. It is better not to go to such a company!

If I meet such an interviewer during an interview, I will directly capture the network packets of the HTTPS establishment process for him on the spot, and then show it to him, and slap him in the face.

For example, the following is the four-way handshake process of TLSv1.2 based on the RSA algorithm:

Isn't it a three-way handshake first, and then a TLS four-way handshake? Interviewer, do you feel embarrassed?

However, the number of TLS handshake processes depends on the version.

The TLSv1.2 handshake process basically requires four times, that is, it takes 2-RTT to complete the handshake before sending a request, while TLSv1.3 only needs 1-RTT to complete the TLS handshake, as shown in the figure below.

Generally speaking, no matter how many times the TLS handshake is done, it must first go through the TCP three-way handshake before it can be done, because HTTPS is implemented based on the TCP transmission protocol, and a reliable TCP connection must be established before the TLS handshake can be done.

Is what the interviewer said, "The TLS handshake process in HTTPS can perform three handshakes at the same time" correct?

This scenario is possible, but it can only happen under certain conditions. If you don't state any prerequisites, saying this would be like being a hooligan.

So under what conditions can this scenario happen? The following two conditions must be met at the same time:

• The TCP Fast Open function is enabled on both the client and the server, and the TLS version is 1.3;
• The client and server have completed a communication.

So how is this done? Let's first understand the TCP Fast Open function and the characteristics of TLSv1.3.

TCP Fast Open

Let's first understand what is TCP Fast Open?

Under normal circumstances, if you want to use the TCP transport protocol for communication, before the client and the server communicate, they must first go through the TCP three-way handshake and establish a reliable TCP connection before the client can send data to the server.

Among them, the first and second TCP handshakes cannot carry data, but the third TCP handshake can carry data, because at this time the client's TCP connection status is already ESTABLISHED, indicating that the client has completed the TCP connection establishment.

Even if the third handshake carrying data from the client is lost in the network, if the client does not receive a response message from the server for the data within a certain period of time, the timeout retransmission mechanism will be triggered, and the client will retransmit the third handshake message carrying the data until the number of retransmissions reaches the system threshold, and the client will destroy the TCP connection.

After talking about regular TCP connections, let's take a look at TCP Fast Open.

TCP Fast Open is used to bypass the TCP three-way handshake to send data. After Linux kernel version 3.7, the TCP Fast Open function is provided, which can reduce the delay in establishing a TCP connection.

To use the TCP Fast Open function, both the client and the server must support it.

However, if the TCP Fast Open function is enabled and you want to bypass the TCP three-way handshake to send data, you must establish the communication process after the second one.

The process when the client establishes a connection for the first time is as follows:

Specific introduction:

• The client sends a SYN message that contains the Fast Open option, and the cookie of this option is empty, which indicates that the client requests the Fast Open Cookie;
• A server that supports TCP Fast Open generates a cookie and places it in the Fast Open option in the SYN-ACK message to send back to the client;
• After receiving the SYN-ACK, the client caches the Cookie in the Fast Open option locally.

Therefore, the first time the client and server communicate, the normal three-way handshake process is still required. Afterwards, the client has a cookie, which can be used to prove to the server TCP that the previous three-way handshake with the client IP address has been successfully completed.

For subsequent communications between the client and the server, the client can carry application data during the first handshake, thereby bypassing the three-way handshake to send data. The whole process is as follows:

I will describe this process in detail:

• The client sends a SYN message, which can carry "application data" and previously recorded cookies;
• A server that supports TCP Fast Open will verify the received Cookie: If the Cookie is valid, the server will confirm the SYN and "data" in the SYN-ACK message, and then deliver the "application data" to the corresponding application; If the Cookie is invalid, the server will discard the "application data" contained in the SYN message, and the SYN-ACK message it sends later will only confirm the corresponding sequence number of SYN;
• If the server accepts the "application data" in the SYN message, the server can send the "response data" before the handshake is completed, which reduces the time consumption of 1 RTT caused by the handshake;
• The client will send an ACK to confirm the SYN and "application data" sent back by the server, but if the "application data" sent by the client in the initial SYN message is not confirmed, the client will resend the "application data";
• The subsequent data transmission process of the TCP connection is consistent with the normal situation without TCP Fast Open.

Therefore, if both the client and the server support the TCP Fast Open function, then after the initial communication process is completed, the subsequent communication between the client and the server can bypass the three-way handshake to send data, which reduces the time consumption of 1 RTT caused by the handshake.

TLSv1.3

After talking about TCP Fast Open, let’s take a look at TLSv1.3.

At the beginning, I also mentioned that the TLSv1.3 handshake process only takes 1-RTT time. The entire handshake process is as follows:

The third handshake of a TCP connection can carry data. If the client sends the first handshake data of TLSv1.3 in the third handshake, does it mean that "the TLS handshake process in HTTPS can perform three handshakes at the same time"?

No, because the server can only conduct a subsequent TLSv1.3 handshake with the client after receiving the client's third TCP handshake. Another powerful feature of TLSv1.3 is the session recovery mechanism. When reconnecting, TLSvS1.3 only needs 0-RTT, uses the "pre_shared_key" and "early_data" extensions, and establishes a secure connection and sends encrypted messages immediately after the TCP connection. The process is as follows:

TCP Fast Open + TLSv1.3

As we know above, if both the client and the server support the TCP Fast Open function, the client can bypass the three-way handshake and send data directly during the second or later communication process, and the server does not need to wait until the third handshake is received before sending data.

If the TLS version of HTTPS is 1.3, the TLS process only requires 1-RTT.

Therefore, if "TCP Fast Open + TLSv1.3" is used, the TLS and TCP handshake processes can be performed simultaneously during the second and subsequent communications.

If the TLSv1.3 0-RTT session resumption process is based on the TCP Fast Open scenario, not only can the TLS and TCP handshake processes be performed simultaneously, but the HTTP request can also be completed during this period.

Summarize

Finally, let’s summarize.

"HTTPS first performs a TCP three-way handshake, and then a TLSv1.2 four-way handshake." There is nothing wrong with this statement. Only those who doubt that this statement is wrong have problems.

"The TLS handshake process in HTTPS can perform three handshakes at the same time." This scenario is possible, but it is tantamount to being a hooligan to say this without mentioning any prerequisites. The following two conditions must be met at the same time:

• The TCP Fast Open function is enabled on both the client and the server, and the TLS version is 1.3;
• The client and server have completed a communication;

So, did the "interviewer" learn anything?