Information Security 18 min read

Why HTTPS Beats HTTP: Inside SSL/TLS, Certificates & Secure Handshakes

HTTPS enhances web security over HTTP by encrypting data, authenticating parties with digital certificates, and employing a combined symmetric‑asymmetric handshake using SSL/TLS, which ensures confidentiality, integrity, and trust through certificate chains, hash functions, and secure key exchange mechanisms.

37 Mobile Game Tech Team
37 Mobile Game Tech Team
37 Mobile Game Tech Team
Why HTTPS Beats HTTP: Inside SSL/TLS, Certificates & Secure Handshakes

With the rapid development of the Internet, security has become increasingly important. Because humans are "greedy" and not satisfied with the security of plain HTTP, HTTPS was created. HTTPS far surpasses HTTP in security.

Problems with HTTP

Data is not encrypted: HTTP transmits data in clear text, exposing user privacy to any attacker who can capture the traffic.

Identity cannot be verified: Neither client nor server can confirm the other's identity because HTTP lacks a standard for authentication.

Data can be tampered with: During transmission, many intermediate nodes can modify the original data, and there is no mechanism to ensure the received data is exactly what the sender sent.

These issues lead to serious security problems, which prompted the birth of HTTPS.

HTTPS

HTTPS is not a new protocol; it is essentially HTTP plus additional security layers. It can be viewed as HTTPS = HTTP + SSL/TLS , where SSL/TLS provides encryption, authentication, and integrity.

SSL (Secure Sockets Layer) is the original security layer protocol; TLS (Transport Layer Security) is its successor. TLS 1.2 and TLS 1.3 are the most widely used versions today.

Both parties must negotiate and agree on the same protocol version before establishing a secure connection.

Before describing the HTTPS data‑transfer process, we need to understand a few concepts.

Encryption Algorithms

Key : a parameter used to transform plaintext to ciphertext and vice‑versa.

1. Symmetric algorithms

Use the same key for encryption and decryption.

Advantages: high efficiency, suitable for encrypting large amounts of data.

Disadvantages: securely sharing the key is difficult because the key exchange itself can be intercepted or altered.

2. Asymmetric algorithms

Use a pair of keys: a public key and a private key.

The public key is shared openly; the private key is kept secret.

Data encrypted with the public key can only be decrypted with the private key, and vice versa.

Advantages: solve the key‑exchange problem of symmetric algorithms.

Disadvantages: much slower and less efficient.

3. Hybrid (symmetric + asymmetric)

First use asymmetric encryption to exchange a symmetric key, then use the symmetric algorithm for the bulk of the communication. This combines the strengths of both methods.

Client requests the server; the server returns its public key.

Client encrypts a randomly generated symmetric key with the server’s public key and sends it to the server.

Server decrypts the symmetric key with its private key.

Both sides now use the symmetric key for fast, secure communication.

Digital Certificates

Certificates solve the "cannot verify identity" problem of HTTP. A digital certificate is an electronic credential issued by a Certificate Authority (CA) that binds a public key to an entity’s identity.

1. What is a digital certificate?

A digital certificate is like an ID card for the internet, used to verify the identity of the holder.

It contains the server’s public key, signature, and CA information. Clients verify the certificate, then obtain the server’s public key for encrypted communication.

2. Certificate generation

The CA hashes the certificate data, signs the hash with its private key, and returns the signed certificate to the server.

Steps:

Server creates a key pair and sends the public key and identity info to the CA.

CA hashes the information, signs the hash with its private key, producing a digital signature.

CA returns the signed certificate to the server.

When a client connects, the server presents the certificate.

3. Certificate distribution

Out‑of‑band (offline) distribution, e.g., pre‑installed on a device.

In‑band (online) download, where the user authenticates to the CA.

Public repositories or databases that can be queried.

4. Certificate verification

Clients use the CA’s public key to decrypt the signature, compare the resulting hash with a locally computed hash of the certificate data, and check expiration, revocation lists (CRL/OCSP), and the certificate chain.

Certificate validity period is set when issued (typically one year for individuals, three years for enterprises).
Revocation lists announce certificates that have been cancelled.

5. Certificate chain

A chain links the end‑entity certificate to a trusted root CA through one or more intermediate certificates. Browsers display the chain when you click the lock icon.

End‑user certificate (e.g., baidu.com) contains the server’s public key.

Intermediate certificates certify the end‑user certificate.

Root CA certificate is self‑signed and trusted by the operating system.

Hash Algorithms

Hash (digest) algorithms compress data into a fixed‑size fingerprint. Small changes in the input produce drastically different hashes, enabling integrity checks (e.g., MD5 for file comparison).

Encryption algorithms are reversible (can decrypt with a key).

Hash algorithms are irreversible; they produce a digital fingerprint, not the original data.

HTTPS Connection Process

Client initiates a request, sending supported TLS version, cipher suites, and a random number R1.

Server selects a cipher suite, generates its own random number R2, and returns R2 together with its certificate.

Client verifies the certificate, creates a pre‑master secret using R1, R2, and encrypts it with the server’s public key.

Server decrypts the pre‑master secret with its private key.

Both sides derive session keys (p1‑p6) from the pre‑master secret.

Client sends an encrypted handshake message (using p1) and a FIN flag.

Server validates the message, replies with its own encrypted handshake (using p1) and FIN.

Client validates the server’s message (using p2); the handshake completes and secure communication begins.

After this exchange, both parties can communicate securely.

<code>疑惑点:

1、客户端的随机数 R1、服务端的随机数 R2 的作用是什么?
答:双方通过交互各自的随机数后,双方都拥有了 R1、R2。客户端(client)利用 R1、R2 生成一个 pre-master secret,然后利用这三个数,生成会话密钥。 同样的服务端(server)也是利用这三个数生成会话密钥。

2、p1-p6 的作用是什么?
答:6个密钥 p1-p6 是用作后续的身份认证

3、Encrypted handshake message 是什么? 有什么用?
答:Encrypted handshake message 把当前自己收到的数据和发送的数据进行一次简单运算(hash+加密)。 这个报文的目的就是告诉对端自己在整个握手过程中收到了什么数据,发送了什么数据。来保证中间没人篡改报文。其次,这个报文作用就是确认秘钥的正确性。因为Encrypted handshake message是使用对称秘钥进行加密的第一个报文,如果这个报文加解密校验成功,那么就说明对称秘钥是正确的。</code>

Charles Proxy Capture HTTPS Principle

Charles acts as a man‑in‑the‑middle proxy. For the client, Charles appears as the server; for the server, Charles appears as the client.

Charles obtains the server’s public key and the symmetric key used for the HTTPS session, provided the client trusts and installs Charles’s CA certificate. This demonstrates that, while HTTPS is robust, it can be intercepted if the client accepts a malicious CA.

References

HTTPS Process Detailed Explanation

Charles HTTPS Capture Overview

TLS/SSL Protocol Deep Dive (Encrypted Handshake Message)

encryptionnetwork securityHTTPSSSL/TLSdigital certificates
37 Mobile Game Tech Team
Written by

37 Mobile Game Tech Team

37 Mobile Game Tech Team

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.