HTTP vs HTTPS：区别在哪里、HTTPS 为什么更安全（应用层）

HTTP 是明文协议，链路上任何中间节点都能看到完整报文，由此产生窃听、篡改、冒充三类风险。HTTPS 通过在 HTTP 之下加入 TLS（Transport Layer Security，传输层安全协议），用混合加密和数字证书逐一补上这些短板。本文按”风险、设计、握手、对比、实践”的顺序展开。

HTTP 的三个风险

HTTP 报文以明文跑在 TCP 上，链路上的任何一环——同网段的攻击者、被入侵的路由器、不可信的代理——都能看到并改写内容。具体对应三类风险：

窃听：公共 Wi-Fi 下，攻击者抓包即可读到账号密码和 Cookie，进而劫持整个会话。
篡改：中间节点可以改写响应内容。运营商在网页里插入广告脚本就是典型案例——服务器返回的是干净页面，用户看到的却多了弹窗。
冒充：DNS 劫持可以把用户引向伪造服务器，而 HTTP 没有身份验证机制，客户端无从分辨对端真假。

三者分别对应机密性（Confidentiality）、完整性（Integrity）、身份认证（Authentication），HTTPS 的设计目标就是补齐这三块短板。

HTTPS 的核心设计

HTTPS 不是新协议，而是 HTTP over TLS：报文先交给 TLS 层加密，再走 TCP 传输。核心设计有两点。

混合加密

对称加密（Symmetric Encryption，如 AES-GCM）用同一把密钥加解密，速度快，适合加密大量数据，但密钥如何安全送达对端是个难题——直接在网上传密钥，等于把钥匙和锁一起寄出去。非对称加密（Asymmetric Encryption，如 RSA、ECDHE）基于公钥/私钥对，可以在公开信道上协商出共享秘密，但运算慢得多。

TLS 采用混合加密（Hybrid Encryption）：握手阶段用非对称算法完成身份认证和密钥交换，得到一把只有双方知道的会话密钥；此后所有 HTTP 数据都用会话密钥做对称加密。非对称算法只出现在握手的一小段时间里，业务数据全程走快速通道。

数字证书与 CA 信任链

非对称加密解决了密钥交换，但留下一个漏洞：客户端怎么确认收到的公钥确实属于目标服务器？攻击者完全可以把自己的公钥冒充成服务器的发过来，这就是中间人攻击（Man-in-the-Middle，MITM）。

解法是引入受信第三方——证书颁发机构（Certificate Authority，CA）。服务器运营者向 CA 提交身份材料和公钥，CA 审核后用自己的私钥对证书签名。操作系统和浏览器内置了受信任的根 CA 证书。客户端收到证书后做链式验证：用签发者的公钥逐级验证签名，直到锚定到本地信任的根；同时核对域名、有效期和吊销状态。全部通过，才认可这把公钥的身份。

TLS 握手流程

以 TLS 1.2 + ECDHE 的典型握手为例：

Client                                    Server
  | -------- ClientHello ---------------> |  版本、密码套件、随机数
  | <--- ServerHello + Certificate ------ |  选定套件，下发证书链
  | <--- ServerKeyExchange -------------- |  服务器临时 ECDHE 公钥（已签名）
  | ------- ClientKeyExchange ----------> |  客户端临时 ECDHE 公钥
  | ======= 双方派生同一把会话密钥 ======== |  之后全走对称加密

拆解为四步：

ClientHello：客户端发出支持的 TLS 版本、密码套件（Cipher Suite）列表和一个随机数。
证书下发与验证：服务器返回选定的套件、随机数和证书链，客户端按 CA 信任链验证服务器身份。
密钥交换：双方交换临时 ECDHE 公钥（服务器那份用证书私钥签名以防篡改），各自算出同一个预主密钥（Pre-Master Secret）。
会话密钥生成：预主密钥结合两个随机数派生出会话密钥，握手完成，后续报文全部对称加密。

RSA 与 ECDHE 两种密钥交换的关键差异是前向安全性（Forward Secrecy）：RSA 方式下预主密钥用服务器公钥加密传输，私钥一旦泄露，历史抓包流量可被全部解密；ECDHE 每次握手生成临时密钥对，用完即弃，长期私钥泄露也无法回溯解密旧会话。这正是 TLS 1.3 移除静态 RSA 密钥交换的原因。此外，TLS 1.3 相比 1.2 握手更快，并砍掉了 SHA-1、RC4、CBC 等过时算法，只保留 AEAD 类现代算法。

HTTP vs HTTPS 对比

维度	HTTP	HTTPS
默认端口	80	443
数据加密	明文传输	TLS 对称加密（AEAD）
身份认证	无	数字证书 + CA 信任链
完整性	无，可被篡改	篡改即解密失败
证书	不需要	需向 CA 申请并维护
性能开销	低	多一次 TLS 握手与加解密，可用会话复用缓解
SEO	无加成	搜索引擎给予排名倾斜

工程实践

开启 HSTS：通过响应头告诉浏览器”以后只走 HTTPS”，防止降级攻击，也省掉一次 301 跳转：

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

全站 HTTPS：只给登录页上 HTTPS 不够，Cookie 在明文页面照样泄露；HTTPS 页面也不要引用 HTTP 资源，混合内容会被浏览器直接拦截。
会话复用：Session ID 与 Session Ticket 让重复访问走简化握手，显著降低延迟和服务器开销。
认清边界：HTTPS 防的是链路中的窃听与篡改，不是绝对安全。用户主动信任抓包工具（如 Charles）的根证书，等于自己授权了一个中间人，HTTPS 照样能被解包；证书也管不了服务器被入侵、越权访问或 XSS 这类应用层问题。

面试视角

HTTPS 握手过程是怎样的？

四步：ClientHello（版本、套件、随机数）→ ServerHello 并下发证书链 → 验证证书后完成密钥交换（ECDHE 交换临时公钥，各自算出预主密钥）→ 派生会话密钥，此后全走对称加密。可补充 TLS 1.3 握手更快，且只保留前向安全的密钥交换方式。

为什么用混合加密，而不是全程非对称？

RSA 这类非对称算法运算量比 AES 高几个数量级，直接加密业务数据性能不可接受；而对称加密苦于密钥分发。混合加密让非对称只负责握手时的认证与密钥协商，大量业务数据走对称加密，两者各取所长。

中间人攻击为什么防不住伪造证书？

其实防得住，关键在于客户端的验证逻辑。中间人换成自己的证书后，签名链无法锚定到本地信任的根 CA，或域名不匹配，浏览器会直接弹出警告。真正危险的是用户无视警告继续访问，或设备被植入恶意根证书——那是信任锚被攻破，不是 TLS 协议本身的缺陷。

小结

HTTP 明文传输带来窃听、篡改、冒充三大风险，HTTPS 用 TLS 补上机密性、完整性与身份认证。
TLS 混合加密：非对称算法负责握手与密钥交换，对称算法保护业务数据，安全与性能兼顾。
数字证书与 CA 信任链解决公钥归属问题，是抵御中间人攻击的核心机制。
ECDHE 提供前向安全性，TLS 1.3 砍掉过时算法、加快握手；工程上还需 HSTS、全站 HTTPS 与会话复用配套落地。