Moment For Technology

HTTPS Connection Process

Posted on Aug. 8, 2022, 7:12 p.m. by 尚慧君
Category: The back-end Tag: The back-end

HTTP communication uses plain text without encryption, so security cannot be guaranteed. Enter a credit card number on a Web page, for example, and if the communication line is tapped, the credit card number is exposed.

In order to solve these problems, encryption and authentication mechanisms need to be added to HTTP. We call HTTP with encryption and authentication mechanisms HTTPS (HTTP Secure).

The macro

The whole HTTPS connection process is quite complex, involving network and encryption, so let's first take a macro look at how HTTPS is connected, and then refine the points in the connection process, please see the following figure

  1. The negotiation between the client and server is used to determine the SSL version, encryption algorithm, and key length
  2. During the negotiation, the server sends a public key certificate to the client. The client uses the public key of the authentication authority to confirm the validity of the certificate and then extracts the public key
  3. The client uses the obtained public key to encrypt a random password string called pre-master secret, which is used in communication encryption generated by the client, and sends it to the server
  4. The server uses the private secret key to decrypt the data sent, and retrieves the pre-master secret
  5. The server and client generate master_secret from pre-master secret, PRF(pre_master_secret, "master secret", clienthello.random + serverHello.random), Random and serverHello. random Are exchanged between the server and client during negotiation, and then master_secret is used to generate symmetric encryption keys
  6. The client and server use symmetrically encrypted keys for subsequent data transmission

details

The SSL and TLS

SSL (Secure Sockets Layer) protocol was originally developed by Netscape to Secure online transactions. The protocol protects customer data through encryption and ensures transaction security through authentication and integrity checks. To achieve this goal, SSL is implemented at the application layer directly above TCP.

What does SSL have to do with TLS?

The IETF later changed the name to Transport Layer Security (TLS) when standardizing SSL. Many people use TLS and SSL interchangeably, but they are not strictly the same because they refer to different versions of the protocol.

Typically, HTTP communicates directly with TCP. When SSL is used, it evolves to communicate with SSL first and then with SSL and TCP. In short, HTTPS is HTTP in the shell of THE SSL protocol.

With SSL, HTTP has the encryption, certificate, and integrity protection features of HTTPS.

SSL is independent of HTTP. Therefore, SSL can be used with other protocols, such as SMTP and Telnet, that run on the application layer. SSL is the most widely used network security technology in the world today.

TLS runs on top of the Reliable Transport Layer (TCP), which means that TCP's "three-way handshake" must be completed first.

Symmetric and asymmetric encryption

Symmetric encryption: also called shared key encryption, encryption and decryption use the same key. When the server sends the secret key to the client, it is vulnerable to hijacking and loses the security effect.

Asymmetric encryption: Also called public key encryption, asymmetric encryption has two secret keys, one is called a private key and the other is called a public key. As the name implies, a private key cannot be known to anyone else, whereas a public key can be freely distributed and available to anyone. The party that sends the ciphertext uses the public key for encryption. After receiving the encrypted message, the other party uses its private key to decrypt the encrypted message.

HTTPS uses asymmetric encryption in pre_master_secret exchange to securely negotiate symmetric encryption keys.

HTTPS After obtaining the symmetric encryption key, use the symmetric encryption algorithm to encrypt the sent data.

Certification authority

There are some problems with the public key. How can the client know that the received public key is indeed the server's public key and has not been replaced by an attacker in transmission?

In this case, a digital Certificate Authority (CA) and a public key Certificate issued by it are required.

The server operator applies for a public key from a digital certificate Authority. After identifying the identity of the applicant, the digital certificate Authority will digitally sign the applied public key, allocate the signed public key, and bind the public key into the public key certificate.

The server sends the certificate to the client, and the client authenticates the digital signature on the certificate with the public key of the DIGITAL certificate Authority. Once the authentication is successful, the client knows two things: first, the public key of the authentication server is a real and valid digital certificate authority. Second, the server's public key is trustworthy.

How can a client obtain the public key of a DIGITAL Certificate Authority? Most browser developers release their versions internally with a public key from a common certification authority.

HTTPS secure communication flow

With the big picture and details out of the way, let's take a look at HTTPS's complete communication flow, which starts after the TCP handshake

Step 1: The Client sends a Client Hello packet to start SSL communication. The packet contains the specified VERSION of SSL supported by the client and the Cipher Suite list (encryption algorithm and key length).

Step 2: When SSL communication is enabled, the Server responds with Server Hello packets. As with the client, the message contains the SSL version as well as the encryption component. The server's encryption component content is filtered from the received client encryption component.

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

Step 4: The Server sends a Server Hello Done packet to notify the client that the INITIAL SSL handshake negotiation is complete.

Step 5: After the first SSL handshake, the Client responds with a Client Key Exchange packet. The packet contains a random password string called pre-master secret, which is used in communication encryption. The packet is encrypted with the public key in Step 3.

Step 6: The client sends the Change CipherSpec packet. The packet prompts the server that the communication after the packet is encrypted with the pre-master secret key.

Step 7: The client sends a Finished packet. The packet contains the overall checksum of all packets so far connected. Whether the handshake negotiation can succeed depends on whether the server can decrypt the packet correctly.

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

Step 9: The server also sends a Finished packet.

Step 10: After exchanging Finished packets between the server and client, the SSL connection is established. Of course, the communication is protected by SSL. This is where application layer protocol communication starts, that is, sending HTTP requests.

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

Step 12: Finally disconnect from the client. When the connection is disconnected, the close_notify packet is sent. After this step, a TCP FIN packet is sent to close the communication with TCP.

The serious version of the communication flow is shown below

conclusion

HTTPS connection process is quite complex, this article is just a brief introduction to the whole framework, there are many details worth discussing. As for the depth of the discussion, completely depends on your needs, after all, for some work, do not know HTTPS can do.

data

  1. The definitive guide to Web Performance

  2. The illustration of HTTP

  3. HTTPS pre-master-secret to master-secret process?

The last

If you like my article, you can follow my public account (Programmer Malatang)

My personal blog is shidawuhen.github. IO /

Review of previous articles:

technology

  1. HTTPS Connection Process
  2. Current limiting 2
  3. Seconds kill system
  4. Distributed systems and consistency protocols
  5. Service framework and registry for microservices
  6. Beego framework use
  7. Discussion on Micro-service
  8. TCP Performance Optimization
  9. Current limiting implementation 1
  10. Redis implements distributed locking
  11. Golang source BUG tracking
  12. The implementation principle of atomicity, consistency and persistence of transactions
  13. CDN request process details
  14. Common Cache tips
  15. How to effectively connect with third-party payment
  16. Gin framework concise version
  17. InnoDB locks and transactions
  18. Algorithm is summarized

Reading notes

  1. Agile revolution
  2. How to exercise your memory
  3. Simple Logic - After reading
  4. Hot Wind - After reading
  5. Analects of Confucius - After reading
  6. Sun Tzu's Art of War - Reflections from reading

thinking

  1. Project process management
  2. Some thoughts on project management
  3. Some thoughts on product manager
  4. Thinking about programmer career development
  5. Thinking about code review
  6. Markdown editor recommends - Typora
Search
About
mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.