Follow us, bookmark us, and meet us every day at 7:30 for daily Java content sharing.

Technical Analysis (Detailed Explanation of TLS Four-Way Handshake)
The total process of establishing an HTTPS connection is: TCP three-way handshake + TLS handshake.
We mainly focus on the TLS handshake process, which requires four key round trips (ClientHello -> ServerHello/Cert -> ClientKeyExchange -> ChangeCipherSpec/Finished):
Phase One: Establishing the Underlying Connection (TCP Handshake)
- • Client sends [SYN]
- • Server sends [SYN-ACK]
- • Client sends [ACK]
- • Result: A reliable TCP connection has been established, and data can now be sent.
Phase Two: TLS Handshake (The Security Handshake)
| Step | Message Name | Who Sends | Core Content | Purpose |
| 1 | Client Hello | Client | The TLS versions, cipher suites, compression algorithms supported by the client, and a random number A (Client Random). | To inform the server of its capabilities. |
| 2 | Server Hello | Server | Confirms the selected TLS version and cipher suite, sends a random number B (Server Random). | To confirm the final communication standards. |
| 3 | Certificate | Server | Server’s digital certificate (contains the server’s public key). | To prove its identity and send the public key needed for encryption. |
| 4 | Certificate Verify (optional) | Client | The client verifies the validity of the certificate (whether the CA is trusted, whether the certificate is expired, whether the domain matches). | To ensure the server is not a “man-in-the-middle”. |
| 5 | Client Key Exchange | Client | The client generates a pre-master secret and encrypts it with the server’s public key before sending it to the server. | To pass the unique “seed” needed to generate the symmetric key. |
| 6 | Server & Client Generate Session Key | Both parties | (internally calculated independently) Both parties use the pre-master secret + random number A + random number B to independently calculate the symmetric session key. | To determine the final communication cipher. |
| 7 | Finished | Both parties | Both parties send a “Finished” message, indicating “I am ready, from now on, all data will be encrypted with the new key”. | To verify whether both parties have correctly negotiated the same key. |
- • Final Result: Both parties securely share a symmetric key, and subsequent application layer data will be encrypted and transmitted using this key.
Story Scenario: Agent Meeting
The technical process is a rigorous protocol. Now, the story king will take you into a high-risk espionage operation to see how two agents establish a “secret encrypted phone line“.
- • Agent A (Client): Your computer.
- • Agent B (Server): Remote server.
Phase One: Establishing Basic Communication (TCP Handshake)
Agent A wants to call Agent B.
- • A: “Hello, can you hear me?” (SYN)
- • B: “I can hear you, please continue.” (SYN-ACK)
- • A: “Okay, the line is open.” (ACK)
- • Result: A basic phone line has been established. However, this phone line is not encrypted.
Phase Two: TLS Handshake – Authentication and Key Generation
Agent A knows this line is not secure, and he needs to establish a secure “encrypted channel” with B.
- 1. A Reveals Identity and Tools (Client Hello):A first sends a secret message: “Please reply! I support using X, Y, Z ciphers, and this is my private random number (A)”.” (indicating capabilities)
- 2. B Verifies Identity and Confirms Secret Message (Server Hello + Certificate):B receives the secret message and immediately replies.
- • B: “Received! We choose to use X cipher. This is my private random number (B).”
- • B: “To prove my identity, please check my official encryption seal (digital certificate).” (provides public key)
Story Summary:
| Handshake Phase | TCP (Three-Way Handshake) | TLS (Key Handshake) | TLS (Key Agreement) |
| Purpose | Establish Communication Line | Verify Identity, Confirm Encryption Rules | Generate Session Key |
| Core Elements | SYN, ACK | Digital Certificate (Public Key) | Pre-Master Secret (Encrypted with Public Key) |
| One-Sentence Summary | First, make a call | Verify Identity | Negotiate Cipher |
Conclusion:The core of establishing an HTTPS connection lies in using asymmetric encryption (public key/private key) to securely transmit a symmetric key (session key). Authentication ensures trust between the communicating parties, while the use of the symmetric key guarantees the efficiency of subsequent data transmission. Although this process is complex, it ensures the most fundamental trust and security in the web world.
Recommended Reading Click the title to jump
50 Java Code Examples: Master Lambda Expressions and Stream API
16 Major Java Code Transformations: “General Writing” VS “Advanced Writing” Ultimate Showdown, Watch Code Quality Soar!
Why Senior Java Developers Love Using the Strategy Pattern
Selected Java Code Snippets: Better Writing for 10 Common Programming Scenarios
Enhancing Java Code Reliability: 5 Best Practices for Exception Handling
Why You Rarely See if-else in the Code of Experts, Because They All Use This…
Still Crazy Injecting Other Services in Service? You Should Have Used Spring’s Event Mechanism Long Ago
Did you gain something from this article? Please share it with more people.
Follow “Java Content” and bookmark it to enhance your Java skills

❤️ Give a "Recommendation", it is the greatest support ❤️
.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}