HTTPS：更安全的HTTP，从加密原理、数字证书到TLS 握手全解析

彻底搞懂 HTTPS：从加密原理、数字证书到 TLS 协议全解析

一、前言

日常上网时，我们总能看到浏览器地址栏的安全小锁，访问百度、知乎等网站时，HTTP 明文链接会自动强制重定向为 HTTPS。服务器通过返回 307 重定向状态码，引导用户跳转到加密地址。

所有人都知道 HTTPS 更安全，但绝大多数人并不清楚：HTTP 到底有什么漏洞？HTTPS 靠什么防抓包、防中间人攻击？非对称加密、数字签名、CA 证书、TLS 协议各自扮演什么角色？

本文基于 HTTPS 核心底层逻辑，从 HTTP 缺陷入手，一步步拆解加密原理、身份认证、证书机制与 TLS 握手全过程，帮你体系化吃透 HTTPS 完整知识体系。

二、HTTP 的致命短板：明文传输极易被中间人攻击

HTTP 最核心的问题是所有数据均以明文传输，没有任何加密保护。

就像传递一封无任何遮挡的信件，网络中间人可以轻易通过抓包工具，截获请求参数、账号密码、隐私数据，甚至篡改服务器响应内容，伪造页面信息。

而HTTPS 诞生的核心目的 ，就是给 HTTP 通信 "上锁"，构建一条加密、可认证、防篡改的安全传输通道，从根源抵御中间人抓包攻击。

三、加密核心原理：对称加密与非对称加密配合使用

3.1 加密的基础困境

简单上锁通信逻辑：通信双方用一把钥匙加解密。但有一个致命问题：钥匙怎么安全传给对方？如果直接在网络中传输密钥，极易被中间人截获，后续加密也就形同虚设。这就需要引入非对称加密来解决密钥分发难题。

3.2 非对称加密核心概念

非对称加密拥有两把密钥，成对出现、分工明确：

• 公钥（public key）：完全公开，任何人都可以获取、不怕被截获
• 私钥（private key）：必须自己保管，绝不对外泄露

核心规则：公钥加密的数据，只能用对应私钥解密。

3.3 HTTPS 密钥交换完整流程

1. 客户端发起连接请求，服务器将自身公钥发给客户端；
2. 客户端生成一个随机对称密码，用服务器公钥进行加密；
3. 客户端把加密后的密码发给服务器；
4. 服务器用自己的私钥解密，拿到这个随机对称密钥；
5. 后续所有业务数据，都用这个对称密钥做对称加密传输，不再使用公钥、私钥。

3.4 为什么不全程用非对称加密？

很多人会有疑问：既然非对称加密这么安全，为什么业务数据还要改用对称加密？原因很简单：非对称加密计算量大、运算复杂、速度极慢，不适合网页实时大批量数据通信。

所以 HTTPS 采用最优组合方案：慢速安全的非对称加密 只负责传递对称密钥，高速高效的对称加密负责传输日常业务数据，兼顾安全性与性能。

四、数字签名：解决身份识别与防伪造

密钥加密只能保证数据不被窃听，但又出现新问题：怎么确认消息是谁发的？

举例：小红公布公钥后，小明可以用公钥加密消息发给小红，老王也可以这么做。小红无法区分消息来源，无法辨别是小明还是伪造者发送。

这时就要用到非对称加密的另一能力：私钥签名、公钥验签。

数字签名工作逻辑

1. 通信方小明拥有自己的公钥、私钥，公钥对外公开；
2. 小明用自己的私钥对消息进行签名；
3. 小红收到消息后，用小明的公钥验证签名；
4. 验签通过：消息一定是小明本人发送，且中途未被篡改；
5. 验签失败：消息为伪造或被中途篡改，直接丢弃。

应用场景区分

• 普通网站（百度、知乎）：无需客户端签名认证，区分用户依靠账号密码、Cookie、Session、Token；
• 银行、支付、企业内网等高安全场景：必须要求客户端签名认证，严格校验身份，杜绝伪造接入。

五、CA 数字证书：解决公钥被中间人冒充问题

加密和签名都完善后，仍存在一个致命漏洞：公钥本身可能被中间人篡改冒充。

中间人冒充场景

小红向小明发送自己的公钥，中间人中途截获公钥，把自己的公钥伪装成小红公钥发给小明。小明不知情，用假公钥加密密钥，中间人解密后就能全程窃听通信，完全伪装服务器。

想要解决公钥可信度问题，必须引入权威 CA 机构 + 数字证书机制。

CA 证书申请与颁发流程

1. 网站将自身域名、真实公钥提交给权威 CA 机构；
2. CA 严格审核网站真实身份信息；
3. CA 用自己的私钥对网站信息和公钥进行签名；
4. 生成合法数字证书，颁发给网站服务器。

浏览器证书校验流程

1. 浏览器访问 HTTPS 网站，服务器不直接发公钥，而是返回 SSL 数字证书；
2. 电脑、手机系统内置各大权威 CA 的公钥；
3. 浏览器用内置 CA 公钥验证证书签名；
4. 验签通过：证书合法、公钥真实可信；
5. 验签失败：判定证书伪造，浏览器直接阻断访问，提示不安全；
6. 验证通过后，浏览器从证书中取出正版公钥，进行后续密钥协商。

CA 证书的核心作用：给网站公钥做权威背书，证明公钥真实有效，杜绝中间人冒充篡改。

六、TLS 协议：HTTPS 的安全外壳

6.1 HTTPS 本质公式

HTTPS = HTTP + TLS

HTTPS 并没有改变 HTTP 原有请求、响应报文结构，内层依旧是原汁原味的 HTTP 明文报文，只是外层被TLS 协议加密包裹，相当于给 HTTP 加了一层安全防护壳。

6.2 TLS 协议核心三大作用

TLS 在 TCP 三次握手完成之后进行TLS 握手，只做三件事：加密、认证、防篡改。

1. 身份认证：校验服务器 CA 证书合法性，确认对方真实身份；
2. 密钥协商：通过非对称加密 + 证书，安全协商出对称加密密钥；
3. 加密传输 + 防篡改：全包 HTTP 报文进行加密，同时通过 Hash 算法做完整性校验，防止数据被篡改。

七、结语

简单梳理整条逻辑链：HTTP 明文传输不安全 → 引入非对称加密安全传递对称密钥 → 对称加密保证业务传输速度 → 数字签名解决身份识别与防伪造 → CA 数字证书杜绝公钥中间人冒充 → TLS 协议统一实现认证、加密、防篡改，最终构成 HTTPS 安全体系。