Security is no longer an option, but a required course for every Internet technology practitioner. HTTP, HTTPS, SSL, TLS - Do you really understand what's going on behind the scenes? In this article, we will explain the core logic of modern encrypted communication protocols in a layman's and professional way, and help you understand the secrets "behind the locks" with a visual flow chart.
Why is HTTP "insecure"? --- Introduction
Remember that familiar browser warning?
"Your connection is not private."
Once a website does not deploy HTTPS, all of the user's information is streeted across the network in plaintext. Your login passwords, bank card numbers, and even private conversations can all be captured by a well-positioned hacker. The root cause of this is HTTP's lack of encryption.
So how does HTTPS, and the "gatekeeper" behind it, TLS, allow data to travel securely across the Internet? Let's break it down layer by layer.
HTTPS = HTTP + TLS/SSL --- Structure and Core Concepts
1. What is HTTPS in essence?
HTTPS (HyperText Transfer Protocol Secure) = HTTP + Encryption layer (TLS/SSL)
○ HTTP: This is responsible for transporting the data, but the content is visible in plaintext
○ TLS/SSL: Provides a "lock on encryption" for HTTP communication, turning the data into a puzzle that only the legitimate sender and receiver can solve.
Figure 1: HTTP vs HTTPS data flow.
"Lock" in the browser address bar is the TLS/SSL security flag.
2. What is the relationship between TLS and SSL?
○ SSL (Secure Sockets Layer): The earliest cryptographic protocol, which has been found to have serious vulnerabilities.
○ TLS (Transport Layer Security): The successor to SSL, TLS 1.2 and the more advanced TLS 1.3, which offer significant improvements in security and performance.
These days, "SSL certificates" are simply implementations of the TLS protocol, just named extensions.
Deep into TLS: The Cryptographic Magic Behind HTTPS
1. Handshake flow is fully resolved
The foundation of TLS secure communication is the handshake dance at setup time. Let's break down the standard TLS handshake flow:
Figure 2: A typical TLS handshake flow.
1️⃣ TCP Connection Setup
A client (e.g., a browser) initiates a TCP connection to the server (standard port 443).
2️⃣ TLS Handshake Phase
○ Client Hello: The browser sends the supported TLS version, cipher, and random number along with Server Name Indication (SNI), which tells the server which hostname it wants to access (enabling IP sharing across multiple sites).
○ Server Hello & Certificate Issue: The server selects the appropriate TLS version and cipher, and sends back its certificate (with public key) and random numbers.
○ Certificate validation: The browser verifies the server certificate chain all the way to the trusted root CA to ensure that it has not been forged.
○ Premaster key generation: The browser generates a premaster key, encrypts it with the server's public key, and sends it to the server.Two parties negotiate session key: Using both parties' random numbers and the premaster key, the client and the server calculate the same symmetric encryption session key.
○ Handshake completion: Both parties send "Finished" messages to each other and enter the encrypted data transmission phase.
3️⃣ Secure Data Transfer
All service data is symmetrically encrypted with the negotiated session key efficiently, even if intercepted in the middle, it is just a bunch of "garbled code".
4️⃣ Session Reuse
TLS supports Session again, which can greatly improve performance by allowing the same client to skip the tedious handshake.
Asymmetric encryption (such as RSA) is secure but slow. Symmetric encryption is fast but the key distribution is cumbersome. TLS uses a "two-step" strategy-first an asymmetric secure key exchange and then a symmetric scheme to efficiently encrypt the data.
2. Algorithm evolution and security improvement
RSA and Diffie-Hellman
○ RSA
It was first widely used during TLS handshake to securely distribute session keys. The client generates a session key, encrypts it with the server's public key, and sends it so that only the server can decrypt it.
○ Diffie-Hellman (DH/ECDH)
As of TLS 1.3, RSA is no longer used for key exchange in favor of the more secure DH/ECDH algorithms that support forward secrecy (PFS). Even if the private key is leaked, the historical data still cannot be unlocked.
| TLS version | key Exchange Algorithm | Security |
| TLS 1.2 | RSA/DH/ECDH | Higher |
| TLS 1.3 | only for DH/ECDH | More Higher |
Practical Advice that Networking Practitioners must Master
○ Priority upgrade to TLS 1.3 for faster and more secure encryption.
○ Enable strong ciphers (AES-GCM, ChaCha20, etc.) and disable weak algorithms and insecure protocols (SSLv3, TLS 1.0);
○ Configure HSTS, OCSP Stapling, etc. to improve overall HTTPS protection;
○ Regularly update and review the certificate chain to ensure the validity and integrity of the trust chain.
Conclusion & Thoughts: Is your business Really secure?
From plaintext HTTP to fully encrypted HTTPS, security requirements have evolved behind every protocol upgrade. As the cornerstone of encrypted communication in modern networks, TLS is constantly improving itself to cope with the increasingly complex attack environment.
Does your business already use HTTPS? Does your crypto configuration align with industry best practices?
Post time: Jul-22-2025
