preface

The last article asked how tamper-proof HTTPS is. This article explains why HTTP is not secure and why HTTPS is secure. It also introduces how HTTPS communication process is encrypted, and what is a digital certificate and a signature. If the last article is to help you understand HTTPS encryption process, then this article is to take real network data packets to analyze HTTPS detailed handshake process, if you can match the process one by one, congratulations to you, congratulations to me, we did not waste time.

Before we get down to business, let’s answer the two questions from the previous article

  1. Why do Charles and other packet capture tools or browser consoles see HTTPS returns in clear text?

    HTTPS is the equivalent of HTTP + TSL (TSL and SSL are just different versions of TSL). As we all know, HTTP is a plaintext operation, which means that all encryption and decryption operations are in TLS, as shown in the following figure

    The browser belongs to the application layer above the application, so the output of the browser console has been decrypted through TLS. So why do Charles and other capture tools see it in clear text? Is it also because Charles is above the application layer? Not really! Charles acts as an intermediary agent during packet capture. The browser ===== and Charles====== are servers. Charles is a server for the browser and a client for the server. Charles requires the browser to install and trust its own certificate (equivalent to the server’s certificate) before capturing HTTPS packets. For details, see the following figure

    So you can see that Charles was able to see the clear text because you actively trusted his credentials

  2. Why do I need to hash a digital signature once?

    If you think about it, what happens if you don’t hash your signature? In fact, there is no impact, it still works, the certificate signed in plaintext and hash signed in plaintext, does not have any impact on the authentication. But why do a hash? Remember mentioned on the last article, asymmetric encryption is very time consuming and cost performance, to encrypt and to 100 characters in a character which is quicker, encryption bye think the thumb is the shorter the faster encryption, so reason came out, the certificate of clear basic it is very long, but after the hash is very short, and basic it is fixed length, Therefore, for the sake of performance, you need to hash the signature once

Good, the question is answered, if you have any questions, first calm analysis, then into the main topic

HTTPS detailed handshake process

HTTPS belongs to the application layer of Layer 7 protocols. It is based on TCP. Therefore, the HTTPS handshake must go through the TCP three-way handshake before the HTTPS symmetric key negotiation process is started.

I’ll explain HTTPS’s detailed handshake process with actual network packets

Then I opened the Wireshark tool, and sheepishly entered the following command line

curl https://www.baidu.com
Copy the code

There are actually two issues involved

  1. Why Wireshark and not Fiddler or Charles

    Fiddler and Charles are used to capture upper-layer application data such as HTTPS and HTTP after a link is established. Wireshark is used to capture data packets of all protocols (directly reading network adapter data). So we chose Wireshark

  2. Why curl instead of opening https://www.baidu.com in your browser

    Curl only sends one request. If you open Baidu with a browser, all resources in the Baidu page will also send requests, resulting in a lot of unnecessary data packets

Okay, here we go. Here we go:

Using curl to request https://www.baidu.com to capture all data packets using wireshark

Don’t panic if you encounter anything. Next, I will tell you slowly. (ACK message belongs to a TCP confirmation message, without explanation)

The first step

Explanation: TCP three handshake, this does not explain, if this is not clear, such as ACK, SEQ, MSS, WIN all represent what the meaning, this can be left a message in the interactive area, I as the case specialized to write a few TCP articles (this is too big, not a few is not introduced)

Step 2: The client sends client_hello

Description: The client sends client_hello, which contains the following content (please refer to the above figure) : 1. Include TLS version information 2. Random number (for subsequent key negotiation) random_C 3. Encryption suite candidate list 4. Compression algorithm candidate list 5. Extended Field 6. other

Step 3: The server sends server_hello

Description: After receiving client_hello from the client, the server sends server_hello and returns the negotiation result. 1. TLS protocol version 2. Cipher Suite 3. 4. Random number random_S 5. other

Step 4: The server sends the certificate

Description: After sending server_hello, the server starts to send its own certificate. As can be seen from the figure, the length of the packet containing the certificate is 3761, so the packet is divided into three packets in the TCP block to send the certificate

Ask yourself: 1. What are the criteria for segmentation? 2. When is segmentation and when is sharding? 3. What is MTU and MSS

Step 5: The Server sends the Server Key Exchange

Note: This type of handshake is sent for SSL handshakes that use the DHE/ECDHE asymmetric key negotiation algorithm. The RSA algorithm does not perform this handshake process (DH and ECDH do not send the server key exchange). That is, the packet does not need to be sent, depending on the encryption algorithm. For details about the RSA, DHE, ECDHE, and ECDH processes in SSL, see this article

Step 6: The Server sends Server Hello Done

Description: Inform the client server_hello message sending is complete

Client_key_exchange +change_cipher_spec+encrypted_handshake_message

Explanation: 1. Client_key_exchange sends its public key parameters to the server after verification. The client has actually calculated the key. 3. Encrypted_handshake_message Is used to test the validity and consistency of the key

Step 8: The server sends a New Session Ticket

The server gives the client a session, which is used for a period of time (before the timeout period) when both parties communicate with a negotiated key.

Step 9: The server sends change_cipher_spec

The server decrypts the parameters sent by the client, computes the negotiated key using the same algorithm, verifies the validity of the encrypted_handshake_message sent by the client, and sends the encrypted_handshake_message to inform the client that it can communicate with the negotiated key in the future

Step 10: The server sends the encrypted_Handshake_message

Note: The purpose is also to test the validity of the key. The client sends the packet to verify that the server can decrypt and the client can encrypt properly. On the contrary, the server sends the packet to verify that the client can decrypt and the server can encrypt properly

Step 11: Complete key negotiation and start sending data

Explanation: Data is also sent in segments

Step 12: Finish sending data, 4 TCP waves

Note: The red box means that the encrypted communication is sent by the client or server, which means that the encrypted communication needs to be interrupted for some reason, warning the other party not to send sensitive data, the server data will also have this packet, do not pay attention to

conclusion

Finally, use a diagram to illustrate the following process