HTTP与HTTPS的区别：TLS加密如何保护你的数据安全

当你打开一个登录页面，输入密码并点击提交，浏览器和服务器之间到底发生了什么？表面上看，这个过程很简单：浏览器发送一个 HTTP 请求，服务器返回一个 HTTP 响应。真正的问题不在两端，而在于浏览器和服务器之间那段看不见的网络旅程。正是这段旅程，让 HTTP 和 HTTPS 表现出天壤之别。

本文将从底层网络握手出发，逐层拆解 HTTP 的三大安全缺陷，以及 HTTPS 如何通过 TLS 加以弥补，帮助你建立一个清晰完整的心智模型。

HTTP 的工作方式与三大安全缺陷

在浏览器发送应用数据之前，通常需要先建立一条网络连接。对于经典的 HTTP/1.1 和 HTTP/2，这条路径依赖 TCP 三次握手（HTTP/3 改用基于 QUIC 的机制，本文暂不展开）。

TCP（Transmission Control Protocol，传输控制协议）是互联网协议栈中传输层的核心协议，它提供面向连接的、可靠的字节流传输服务。在经典的 OSI 七层模型中，TCP 位于第四层（传输层），向上为应用层（HTTP、FTP、SMTP等）提供可靠传输的抽象，向下依赖网络层（IP协议）完成实际的数据包路由。TCP 之所以如此重要，是因为底层的 IP 协议本身是"尽力而为"的——它不保证数据包一定到达，也不保证到达顺序。TCP 在此基础上通过序列号、确认机制、滑动窗口和拥塞控制等机制，为上层应用构建了一条看似连续可靠的数据流。

三次握手的设计目的是为了防止历史连接请求的重复初始化造成混乱——如果只有两次握手，服务器无法区分一个新的连接请求和一个网络中延迟到达的旧请求。更具体地说，假设客户端曾发出一个连接请求但该请求在网络中滞留了很久，如果只有两次握手，当这个过期请求最终到达服务器时，服务器会误认为这是一个新连接并分配资源等待数据，而客户端对此一无所知。三次握手通过要求客户端对服务器的确认再次确认，确保双方都明确知道对方已准备好通信。

三次握手的过程是：客户端先发送 SYN（Synchronize）请求，服务器回复 SYN-ACK 确认，客户端再返回一个 ACK。SYN 标志位用于同步双方的序列号（Initial Sequence Number, ISN），这些序列号通常是随机生成的32位整数，它们在后续数据传输中用于确保数据包的有序到达和重传机制的正确工作。每传输一个字节，序列号递增一，接收方通过确认号告知发送方已成功接收到哪个位置的数据。至此，TCP 连接建立完成。

对于明文 HTTP，连接一建立，浏览器就可以立刻发送请求。但问题也随之而来——整条 HTTP 报文都以明文形式在网络上传输，包括请求行、请求头、Cookie 和请求体。如果这是一个登录表单，那么用户名和密码就能被任何能观察流量的人直接读取。

在一个共享网络环境中，这可能是一个恶意的 Wi-Fi 接入点，也可能是位于客户端与服务器之间的代理或其他机器。这类攻击在安全领域被统称为中间人攻击（Man-in-the-Middle Attack, MITM）。实施中间人攻击的技术手段多种多样：在局域网中，攻击者可以通过 ARP 欺骗（伪造 ARP 响应，将自己伪装为网关）来截获同一网段内的流量；在更大范围内，攻击者可以通过 DNS 劫持（篡改 DNS 响应，将域名解析到恶意服务器）或 BGP 劫持（操纵路由器的路由表，将流量引导至攻击者控制的网络路径）来实现流量拦截。2015年，GitHub 曾遭受"大炮"攻击，其原理正是中间设备在传输途中向 HTTP 响应注入恶意 JavaScript；一些 ISP 也被发现在用户的 HTTP 页面中注入广告代码以获取收入。

更糟的是，如果攻击者能够篡改传输中的流量，他们甚至可以在响应到达浏览器之前修改内容——比如在网页中注入恶意 JavaScript 代码，或者替换软件下载链接指向含有木马的文件。

归结起来，HTTP 提供了标准化的消息格式，却存在三个根本性缺陷：

• 缺乏隐私性：数据以明文传输，任何中间方都能读取；
• 无法验证服务器身份：你无法确认对方就是真正的服务器；
• 无法保证消息完整性：报文在传输途中可能被悄悄篡改。

HTTPS 如何通过 TLS 建立安全隧道

HTTPS 通过在 HTTP 之上叠加 TLS（Transport Layer Security，传输层安全协议） 来解决上述三个问题。TLS 的前身是 SSL（Secure Sockets Layer），由 Netscape 公司在1990年代中期设计。SSL 经历了 2.0 和 3.0 两个主要版本后，由 IETF 接手标准化并更名为 TLS。目前 SSL 的所有版本以及 TLS 1.0、1.1 都已因安全漏洞被废弃，现代浏览器要求至少使用 TLS 1.2，而 TLS 1.3（2018年发布，RFC 8446）是当前推荐的版本。这也是为什么人们至今仍习惯说"SSL 证书"，但现代 HTTPS 实际使用的是 TLS。

TLS 1.3 相比 TLS 1.2 带来了多项重大改进。首先，握手往返次数从 TLS 1.2 的两次 RTT（Round-Trip Time）缩减为一次 RTT，这意味着建立安全连接的延迟减少了一半。其次，TLS 1.3 引入了 0-RTT 恢复模式——对于之前已建立过连接的服务器，客户端可以在第一条消息中就附带加密的应用数据，实现零往返延迟的连接恢复（尽管 0-RTT 数据存在重放攻击的风险，需要应用层配合防护）。第三，TLS 1.3 大幅精简了密码套件列表，移除了所有已知不安全的算法——包括 RC4、3DES、CBC 模式的分组密码、静态 RSA 密钥交换、静态 DH 密钥交换等，只保留了五个密码套件，全部基于 AEAD 加密且强制前向保密。

这里有一个关键认知：HTTPS 并没有替换 HTTP，而是把 HTTP 报文放进了一条加密隧道中传输。它的本质就是 "HTTP over TLS"。

在经典的 TCP 路径下，开头与普通 HTTP 完全一样——浏览器仍然先完成 TCP 三次握手。但握手完成后，浏览器不会立即发送 HTTP 请求，而是先发起 TLS 握手。

TLS 握手承担两项核心任务：

1. 让浏览器确认自己正在与真正的服务器通信，而不是某个冒充者；
2. 让浏览器和服务器协商出共享密钥，用于保护后续的通信内容。

TLS 握手第一步：验证服务器身份

TLS 握手从 Client Hello 开始。这条消息告诉服务器浏览器支持哪些 TLS 版本和加密算法选项（称为"密码套件"，Cipher Suite）。密码套件的命名格式揭示了其组成，例如 TLS_AES_256_GCM_SHA384 表示使用 AES-256-GCM 进行加密、SHA-384 进行哈希。在 TLS 1.3 中，Client Hello 还会附带客户端的密钥共享参数（key_share 扩展），以减少握手往返次数——这是 TLS 1.3 实现 1-RTT 握手的关键优化。服务器随后返回 Server Hello，选定本次连接的参数，并发送自己的证书。

证书是网站的"身份证明文件"。它包含域名信息、服务器的公钥、有效期、颁发者信息，并由浏览器已经信任的**证书颁发机构（CA）**签名。证书的格式遵循 X.509 标准，这是一个由 ITU-T 定义的公钥证书格式规范，自1988年首次发布以来已成为互联网 PKI 的基石。

证书颁发机构（Certificate Authority）是一种受信任的第三方组织，负责验证网站运营者的身份并为其颁发数字证书。浏览器和操作系统内置了一组"根证书"，这些根 CA 构成了整个互联网 PKI（Public Key Infrastructure，公钥基础设施）信任体系的锚点。实际部署中，根 CA 通常不直接为终端网站签发证书，而是通过"中间 CA"形成证书链：根 CA 签署中间 CA 的证书，中间 CA 再签署网站证书。这种层级设计有两个好处：一是根 CA 的私钥可以离线保存在硬件安全模块（HSM）中减少泄露风险；二是如果中间 CA 出现问题，可以单独吊销而不影响整个信任体系。目前全球主要的 CA 包括 Let's Encrypt（提供免费证书，极大推动了 HTTPS 的普及——截至2024年，已为超过3亿个域名颁发证书）、DigiCert、Sectigo 等。

为了防止 CA 被入侵后悄悄为恶意方签发证书，Google 于2013年提出了**证书透明度（Certificate Transparency, CT）**机制。CT 要求所有公开信任的证书必须被记录到公开的、只能追加的日志服务器中。域名持有者可以监控这些日志，一旦发现有未经授权的证书被签发，就能及时发现并采取行动。目前，Chrome 浏览器要求所有新签发的证书必须包含至少两个来自不同运营商的 CT 日志签名收据（SCT），否则将不被信任。

在信任这条连接之前，浏览器会对证书进行一系列检查：

• 证书是否过期？过期则拒绝；
• 证书是否匹配当前主机名？不匹配则拒绝；
• 证书链是否能追溯到受信任的 CA？浏览器会逐级验证签名，从网站证书到中间 CA 再到根 CA；
• 证书是否已被吊销？浏览器通过 OCSP（Online Certificate Status Protocol） 向 CA 实时查询证书状态，或检查 CRL（Certificate Revocation List） 来确认证书未被撤销。为避免 OCSP 查询本身带来的隐私和性能问题，现代部署通常使用 OCSP Stapling——由服务器主动获取 OCSP 响应并在 TLS 握手中附带给客户端，避免浏览器直接联系 CA；
• 服务器是否能证明它掌握与证书公钥匹配的私钥？（在 TLS 1.3 中，服务器通过对整个握手记录的哈希摘要进行数字签名来证明这一点，这个签名使用的算法通常是 RSA-PSS 或 ECDSA）

只要任何一项检查失败，浏览器就会中止连接并显示安全警告。

正是这套机制，防止了某台随机服务器假冒你的银行、邮箱提供商或内部管理后台。

TLS 握手第二步：在不可信网络上交换密钥

证书解决了身份问题，但它本身并不加密每一个字节的应用数据。加密需要浏览器和服务器拥有共享密钥——而这需要在一个不可信的网络上完成密钥交换。

许多 HTTPS 教程仍然用较老的 TLS 1.2 RSA 密钥交换作为讲解模型：客户端生成一个预主密钥（pre-master secret），用服务器的公钥加密后发送出去；由于只有服务器拥有匹配的私钥，因此只有它能解密。双方随后据此推导出会话的对称密钥。

这个模型有助于理解为什么会涉及公钥和私钥，但它并不是现代 HTTPS 的实际做法。

在 TLS 1.3 中，静态 RSA 密钥交换已被移除。证书仍用于身份验证，但共享密钥通常通过临时（Ephemeral）Diffie-Hellman 密钥交换来生成。

Diffie-Hellman 密钥交换协议由 Whitfield Diffie 和 Martin Hellman 于1976年提出（发表在论文《New Directions in Cryptography》中），是公钥密码学的开创性成果之一。其核心依赖"离散对数问题"的计算困难性：给定一个大素数 p 和生成元 g，已知 g^a mod p 的结果，要反推出指数 a 在计算上是不可行的。举一个简化的例子：Alice 选择私有指数 a，计算 A = g^a mod p 并公开发送；Bob 选择私有指数 b，计算 B = g^b mod p 并公开发送。Alice 收到 B 后计算 B^a mod p = g^(ab) mod p；Bob 收到 A 后计算 A^b mod p = g^(ab) mod p。双方得到相同的值 g^(ab) mod p 作为共享密钥，而窃听者只能看到 g^a mod p 和 g^b mod p，在计算上无法得出 g^(ab) mod p。

现代 TLS 1.3 中使用的是基于椭圆曲线的变体（ECDHE，Elliptic Curve Diffie-Hellman Ephemeral），它能用更短的密钥长度（如256位椭圆曲线密钥提供相当于3072位RSA密钥的安全强度）提供同等安全保障，从而减少计算开销和带宽消耗。TLS 1.3 支持的椭圆曲线包括 X25519（由密码学家 Daniel J. Bernstein 设计，因其实现简洁和抗侧信道攻击的特性而被广泛采用）和 P-256（NIST 标准曲线）。在实际部署中，X25519 已成为最流行的选择。

简单来说，客户端和服务器各自交换临时的公开值，同时各自保留自己的私钥。基于这些信息，双方能够独立计算出相同的共享密钥，而这个密钥本身从不在网络上传输。

这一细节至关重要，因为它带来了前向保密性（Forward Secrecy）：即使有人今天录下了加密流量，日后又窃取了服务器的证书私钥，他们仍然无法解密那些历史会话——因为临时的握手密钥早已消失。

前向保密性在实践中意味着每次 TLS 会话都使用独立生成的临时密钥对。即使攻击者长期录制加密流量（这在国家级监控场景中并非罕见——2013年斯诺登披露的文件表明，NSA 的 MUSCULAR 项目正是通过在数据中心之间的光纤链路上抓取流量来进行大规模监控），并在未来某天通过入侵服务器获得了其长期私钥，也无法回溯解密过去的通信内容。这与旧式 RSA 密钥交换形成鲜明对比——在 RSA 模式下，所有会话的对称密钥都依赖同一把服务器私钥来保护，一旦私钥泄露，所有历史流量都将暴露。正因如此，TLS 1.3 强制要求使用具备前向保密性的密钥交换算法。

密钥交换背后的数学很复杂，但目标很简单：握手结束时，客户端和服务器持有相同的密钥；观察者能看到握手消息，却无法据此推算出密钥。

加密传输：对称加密保护真正的 HTTP 数据

此刻，浏览器已经知道两件事：它在与哪台服务器通信，以及它拥有了保护连接的密钥。现在，浏览器终于可以发送 HTTP 请求了。

这一次，HTTP 请求不再以可读文本形式出现在网络上。请求路径、请求头、Cookie 和请求体全部被加密。观察者或许仍能看到一些连接元数据（比如服务器 IP 地址、通过 SNI 扩展暴露的域名），但无法读取或悄悄篡改 HTTP 报文本身。

关于 SNI（Server Name Indication） 泄露的隐私问题值得深入讨论。SNI 是 TLS 扩展字段，客户端在 Client Hello 中以明文携带目标域名，目的是让同一 IP 地址上托管多个 HTTPS 站点的服务器知道该出示哪张证书。但这也意味着网络观察者（如 ISP 或防火墙）可以看到用户正在访问哪个网站，即便无法读取具体内容。为解决这一隐私缺陷，IETF 正在推进 ECH（Encrypted Client Hello） 标准——它将 SNI 等敏感字段加密在一个外层"掩护"握手中，使得观察者只能看到通用的前端域名而非真实目标。此外，配合 DNS over HTTPS（DoH） 或 DNS over TLS（DoT） 对 DNS 查询进行加密，可以进一步防止网络观察者通过 DNS 流量推断用户访问的网站。

服务器解密数据、处理 HTTP 请求，然后返回一个加密的 HTTP 响应。

那么，为什么握手之后要切换到对称加密？因为对称加密足够快，适合处理大批量数据。对称加密算法（如 AES-256-GCM、ChaCha20-Poly1305）使用同一把密钥进行加密和解密，其运算本质是位运算和置换，在现代 CPU 上（尤其是支持 AES-NI 硬件指令集的处理器）可以达到每秒数 GB 的吞吐量。AES-NI 是 Intel 于2010年引入的 CPU 指令集扩展，将 AES 的核心运算（SubBytes、ShiftRows、MixColumns等）直接实现在硬件中，使得 AES 加解密速度提升5-10倍，同时消除了软件实现中常见的缓存计时侧信道攻击风险。ChaCha20-Poly1305 则是 Google 推广的替代方案，专为没有 AES 硬件加速的设备（如早期的 ARM 移动处理器）设计，在纯软件实现中性能优于 AES-GCM。

非对称加密（公私钥）在身份验证和密钥协商上很有用，但涉及大数模幂或椭圆曲线点乘等运算，速度通常比对称加密慢2-3个数量级。以具体数字为例，在典型硬件上，AES-256-GCM 的加密吞吐量可达数 GB/s，而 RSA-2048 签名运算每秒仅能完成几百到几千次。因此 TLS 的设计采用了"混合加密"策略：用非对称机制完成一次性的身份认证和密钥协商，然后用协商出的对称密钥保护后续所有数据传输。握手完成后，连接中的绝大部分内容都是常规 HTTP 数据——请求头、Cookie、JSON、HTML、图片、API 响应，这些都需要在整个连接生命周期内获得高效的加密与完整性保护。

值得一提的是，现代 TLS 使用的 AEAD（Authenticated Encryption with Associated Data）模式（如 AES-GCM）同时提供加密和消息认证，这意味着任何对密文的篡改都会被接收方立即检测到——这正是 HTTPS 解决"消息完整性"问题的具体机制。AEAD 的工作原理是在加密数据的同时计算一个认证标签（Authentication Tag），解密时接收方会重新计算标签并与收到的标签比对，任何哪怕一个比特的篡改都会导致标签不匹配，接收方将丢弃整个记录并终止连接。这比早期 TLS 版本中将加密和 MAC（消息认证码）分开处理的方式更安全，避免了诸如 Padding Oracle 攻击等针对"先加密后 MAC"或"先 MAC 后加密"方案的攻击。

完整的心智模型：HTTP 与 HTTPS 的分层关系

把所有环节串起来，我们就得到了一个清晰的分层模型：

• TCP 负责建立可靠的连接（确保数据包有序到达、丢包重传）；
• TLS 把这条连接变成受保护的安全通道（身份验证 + 密钥协商 + 加密传输 + 完整性校验）；
• HTTP 负责承载请求与响应（定义方法、路径、头部、状态码等语义）。

在明文 HTTP 中，报文直接穿越网络。在 HTTPS 中，浏览器先验证服务器身份、生成全新的会话密钥，然后同样的 HTTP 报文通过加密通道传输。

从网络协议栈的视角看，这个分层非常优雅：HTTP 层完全不需要知道底层是否加密，TLS 层也不关心上层传输的是 HTTP 还是其他协议（事实上 TLS 也被用于保护 SMTP 邮件传输、FTPS 文件传输、数据库连接如 PostgreSQL/MySQL 的客户端-服务器通信等场景）。每一层各司其职，通过清晰的接口组合在一起。这种分层设计也是为什么 HTTP/3 能够将传输层从 TCP 切换到 QUIC（基于 UDP 构建的可靠传输协议），而上层的 HTTP 语义几乎不需要改变——QUIC 在自身协议内整合了 TLS 1.3，将传输层握手和加密握手合二为一，进一步将连接建立延迟缩短至 1-RTT 甚至 0-RTT。

同样的 HTTP，不同的安全模型——这正是那个多出来的字母 S 的意义所在。

核心要点

• HTTP 的三大安全缺陷是：明文传输（隐私性）、无法验证身份（真实性）、无法防篡改（完整性）
• HTTPS = HTTP + TLS，本质是将 HTTP 报文装入加密隧道
• TLS 握手完成两件事：通过证书链验证服务器身份，通过临时 Diffie-Hellman 交换协商共享密钥
• 前向保密性确保即使服务器长期私钥泄露，历史会话仍然安全
• 混合加密策略：非对称加密用于一次性密钥协商，对称加密（AEAD 模式）用于高效保护海量应用数据
• 分层架构使得 TCP、TLS、HTTP 各司其职，互不耦合