Understanding HTTPS: How Encryption, Authentication, and Integrity Secure the Web

1 Introduction

Baidu recently launched site‑wide HTTPS for secure search, automatically redirecting HTTP requests to HTTPS. This article introduces the HTTPS protocol and briefly discusses the significance of deploying site‑wide HTTPS.

2 HTTPS Overview

HTTPS can be seen as HTTP + TLS. HTTP is the familiar application‑layer protocol used by most web applications. TLS (Transport Layer Security), formerly SSL, provides encryption, authentication, and integrity. The diagram below shows the layering of HTTP over TLS.

TLS consists of five components: application data protocol, handshake protocol, alert protocol, encrypted message authentication protocol, and heartbeat protocol. TLS itself is transported by the Record protocol, whose format is shown in the right‑most part of the diagram.

Commonly used HTTP version is HTTP/1.1. Frequently used TLS versions are TLS 1.2, TLS 1.1, TLS 1.0, and SSL 3.0. SSL 3.0 is insecure due to the POODLE attack, yet a tiny fraction of browsers still use it. TLS 1.0 also has known weaknesses (e.g., RC4, BEAST). TLS 1.2 and TLS 1.1 are currently considered safe and are recommended. TLS 1.3 promises major security and performance improvements, though its release date is not yet fixed. HTTP/2, evolved from SPDY, also brings significant efficiency gains over HTTP/1.1.

3 HTTPS Features

Baidu adopts HTTPS primarily to protect user privacy and prevent traffic hijacking. Plain HTTP transmits data in clear text, allowing intermediaries (e.g., Wi‑Fi hotspots, routers, proxies) to sniff search queries, inject ads, or block access. HTTPS encrypts the communication, authenticates the server, and ensures data integrity, thereby thwarting these attacks.

HTTPS provides three core protections:

Content encryption – data between browser and server is encrypted, preventing eavesdropping.

Identity authentication – the client verifies it is communicating with the legitimate Baidu service, mitigating DNS hijacking.

Data integrity – ensures content cannot be altered or forged by third parties.

4 HTTPS Principles

4.1 Content Encryption

Encryption algorithms fall into two categories: symmetric (same key for encryption and decryption) and asymmetric (public‑key encryption). Symmetric encryption offers high performance but suffers from key distribution challenges. Asymmetric encryption solves key exchange problems by allowing the browser and server to negotiate a temporary symmetric key securely.

Common asymmetric key‑exchange algorithms include RSA, DH, DHE, ECDH, and ECDHE. RSA is simple and widely supported; ECDHE offers forward secrecy and better performance but requires ECC support. Because many clients still lack ECDHE, a hybrid approach (RSA + ECDHE) is often recommended.

4.1.1 RSA Key Exchange

RSA security relies on the difficulty of factoring large integers. A typical RSA key generation example:

Choose two primes p=13 and q=19, compute n=p·q=247.

Compute φ(n)=(p‑1)(q‑1)=216. Choose e=17 such that 1 Find d such that e·d ≡ 1 (mod φ(n)); here d=89.

In practice, (n,e) form the public key, (n,d) the private key, with n typically a 2048‑bit integer. The public key is embedded in the server’s X.509 certificate.

RSA Handshake (TLS 1.2)

Client sends ClientHello with a random nonce.

Server replies ServerHello, its own random nonce, and its certificate containing public key P.

Client generates a 48‑byte pre‑master secret, encrypts it with P, and sends it to the server.

Server decrypts with its private key, both sides derive the master secret using a PRF function.

This exchange requires two round‑trips, contributing to HTTPS latency.

4.1.2 ECDHE Key Exchange

ECDHE combines Diffie‑Hellman key exchange with elliptic‑curve cryptography (ECC). The handshake adds a ServerKeyExchange message containing the server’s temporary ECDH public key and a signature.

Client sends ClientHello with supported curves and point formats.

Server replies ServerHello and ServerKeyExchange (ECDH public key + signature).

Client verifies the signature, computes the shared secret, and sends ClientKeyExchange with its own ECDH public key.

Server computes the same shared secret; both now have the symmetric key for the session.

4.2 Symmetric Encryption

After key exchange, the session uses symmetric encryption. Stream ciphers like RC4 are deprecated; ChaCha20 is a modern, fast alternative. Block ciphers historically used AES‑CBC, but vulnerabilities (BEAST, LUCKY13) favor AES‑GCM despite higher computational cost.

4.3 Authentication

Authentication relies on PKI and digital certificates (X.509 v3). A certificate contains:

tbsCertificate (to‑be‑signed fields such as version, serial number, issuer, validity, subject, public key, extensions).

signatureAlgorithm.

signatureValue.

The certificate chain (root → intermediate → leaf) enables browsers to verify trust. Digital signatures are created by hashing the tbsCertificate and encrypting the hash with the CA’s private key; verification uses the CA’s public key.

5 HTTPS Deployment Costs

While HTTPS adds CPU overhead (especially during asymmetric handshakes) and may introduce latency, proper optimization (e.g., session resumption, HTTP/2, SPDY) mitigates impact. Certificate costs are modest; free options like Let’s Encrypt are widely used. For most small‑to‑medium sites, additional hardware is unnecessary.

6 Conclusion

Large internet companies have already adopted site‑wide HTTPS, and Baidu’s rollout pushes the Chinese ecosystem forward. Understanding HTTPS fundamentals—encryption, authentication, integrity, and performance considerations—helps engineers design secure, efficient web services.