HTTPS

为什么 HTTP 不够安全

HTTP 的问题不在于“不能用”，而在于它默认把通信过程暴露在网络链路上。浏览器到服务器之间可能经过本机代理、公司网关、运营商网络、CDN、负载均衡等多个节点。只要某个中间节点能看到或改写流量，纯 HTTP 就很难保证通信可信。

HTTP 主要有三类风险：

• 窃听：请求 URL、Header、Cookie、表单内容和响应数据都是明文。登录态 Cookie、手机号、地址、订单信息都可能被旁路观察。
• 篡改：中间人可以修改响应内容，例如注入广告脚本、替换下载链接，或者修改接口返回值。
• 冒充：客户端无法确认自己连接的真的是目标服务器。攻击者可以伪装成服务端，诱导用户提交账号密码。

这三类风险分别对应安全通信里的三个目标：机密性、完整性、身份认证。HTTPS 的核心价值，就是在 HTTP 之外加上一层 TLS，把这三个目标补齐。

HTTPS 解决了什么问题

HTTPS 可以理解为：

HTTPS = HTTP + TLS

HTTP 仍然负责应用层语义，比如请求方法、状态码、Header、Body。TLS 负责在应用数据真正传输前，先建立一条安全通道。安全通道建立后，HTTP 报文会被加密、校验并发送。

对应 HTTP 的三类风险，HTTPS 的解决方式如下：

需要注意，HTTPS 保护的是传输链路，不是业务系统本身。接口鉴权、权限校验、XSS 防护、SQL 注入防护仍然需要单独做。HTTPS 能保证“路上不容易被偷看和篡改”，不能保证“服务端业务逻辑一定安全”。

对称加密和非对称密码学各自解决什么

面试里常问：为什么 HTTPS 既用对称加密，又用非对称密码学？答案很直接：对称加密适合传大量数据，非对称密码学适合解决身份认证、签名验证和密钥协商问题。

对称加密：快，但密钥分发困难

对称加密的特点是加密和解密使用同一把密钥。常见算法有 AES、ChaCha20。

它的优势是性能好，适合加密 HTTP 请求和响应正文。问题是：通信双方必须提前拥有同一把密钥。如果直接把密钥通过网络发过去，攻击者也能拿到，后续加密就没有意义了。

非对称密码学：能解决信任问题，但不适合直接加密大流量

非对称密码学有一对密钥：公钥和私钥。公钥可以公开，私钥必须由持有者保管。这里要区分三类能力：RSA 既可以用于加密也可以用于签名，ECDSA 主要用于数字签名，ECDHE 主要用于临时密钥交换。实际 TLS 配置里，它们经常组合出现，但职责并不相同。

它解决了两个关键问题：

• 身份认证：服务端用私钥完成签名证明自己持有证书对应的私钥，客户端用证书中的公钥验证签名。
• 密钥协商：双方可以在不直接传输最终会话密钥的情况下，协商出只有彼此知道的对称密钥。

密钥协商不是简单地“服务端把密钥加密发给客户端”。现代 TLS 更常见的是基于 ECDHE 这类临时密钥交换算法，让双方各自计算出同一个共享秘密，再通过密钥派生函数生成真正用于加密和完整性保护的会话密钥。

非对称运算计算成本高，不适合直接保护所有 HTTP 数据。所以 TLS 的常见做法是：握手阶段用非对称密码学完成认证和密钥协商，传输阶段用协商出的对称密钥加密应用数据。

数字证书：把公钥和域名绑定起来

只知道服务端公钥还不够。攻击者也可以生成一对公私钥，然后把自己的公钥发给浏览器。浏览器真正需要确认的是：这个公钥是不是属于我正在访问的域名。

数字证书就是为了解决这个绑定问题。证书里通常包含：

• 域名信息，例如 example.com，也可能包含多个 SAN 域名。
• 服务端公钥。
• 证书有效期。
• 证书用途，例如是否可用于 TLS Server Authentication。
• 颁发者信息。
• CA 对证书内容的数字签名。

客户端验证证书时，不是简单看“有没有证书”，而是会检查多项条件：

1. 证书是否在有效期内。
2. 访问的域名是否匹配证书中的域名或 SAN。
3. 证书链是否能追溯到本机信任的根 CA。
4. 证书签名是否正确。
5. 证书是否被吊销，具体依赖 OCSP、CRL 或浏览器策略。
6. 证书用途、算法强度、协议版本是否符合安全策略。

如果其中任何一项不满足，就可能出现浏览器证书错误、接口请求失败或命令行工具报 TLS 校验失败。

CA 信任链：浏览器为什么信任一个证书

CA 信任链的本质是“逐级担保”。操作系统或浏览器内置了一批根 CA 证书，根 CA 可以签发中间 CA，中间 CA 再签发站点证书。客户端只要能从站点证书一路验证到可信根 CA，就认为这张站点证书可信。

一条典型证书链是：

站点证书 -> 中间 CA 证书 -> 根 CA 证书

验证过程可以理解为：

• 站点证书由中间 CA 签名，客户端用中间 CA 的公钥验证站点证书签名。
• 中间 CA 证书由根 CA 签名，客户端用根 CA 的公钥验证中间 CA 签名。
• 根 CA 已经在本机信任库中，因此整条链成立。

线上经常遇到“浏览器正常，但某些客户端失败”的情况，原因可能是服务端没有配置完整中间证书链。浏览器可能会缓存或自动补全中间证书，而某些 SDK、容器镜像、旧系统不会自动补齐，于是校验失败。

TLS 握手：安全通道是怎么建立的

TLS 握手的目标有三个：协商协议参数、验证服务端身份、生成后续通信使用的对称密钥。RFC 8446 对 TLS 1.3 的目标描述很明确：防窃听、防篡改、防消息伪造。面试复习时，可以按下面这条主线理解 TLS 1.3 的完整握手：

ClientHello
  -> 支持的 TLS 版本、密码套件、随机数、SNI、ALPN、密钥交换参数

ServerHello
  -> 选择的 TLS 版本、密码套件、随机数、密钥交换参数

服务器发送证书与签名证明
  -> 客户端验证证书链、域名、有效期和签名

双方计算共享密钥
  -> 基于 ECDHE 等算法派生出握手密钥和应用数据密钥

Finished
  -> 双方验证握手过程没有被篡改

Application Data
  -> HTTP 数据开始通过对称加密传输

TLS 1.2 和 TLS 1.3 的差异也值得记住：

所谓前向安全性，是指即使服务端私钥未来泄露，攻击者也不能解密过去抓包保存下来的会话内容。ECDHE 这类临时密钥交换机制，就是为了降低长期私钥泄露带来的历史风险。

会话恢复：为什么第二次访问会更快

完整 TLS 握手需要证书验证、密钥交换和多次网络往返。对移动网络、高延迟链路或大量短连接场景来说，这部分成本很明显。会话恢复的目的就是复用之前握手得到的安全上下文，减少后续连接的握手开销。

常见机制有两类：

• Session ID / Session Cache：客户端带上之前的会话标识，服务端如果还能找到对应会话状态，就恢复会话。
• Session Ticket：服务端把会话状态加密成 ticket 发给客户端，客户端下次带回来，服务端解密后恢复。

TLS 1.3 里还有 PSK 和 0-RTT。0-RTT 可以让客户端在握手早期就发送应用数据，延迟更低，但它有重放风险。因此适合幂等请求，不适合支付、下单、转账这类有副作用的操作。

会话恢复优化的是握手成本，不等于永久跳过安全校验。客户端和服务端会受 ticket 有效期、PSK 身份、服务端配置、协议版本和安全策略约束；如果恢复条件不满足，通常会回退到完整握手。证书过期、域名不匹配、协议版本不兼容等问题，仍然可能导致新连接失败。

SNI 和 ALPN：一个连接前就要说清楚的上下文

SNI 和 ALPN 都出现在 TLS 握手阶段，经常和网关、证书、HTTP/2 排查相关。

SNI：告诉服务器我要访问哪个域名

SNI，全称 Server Name Indication。客户端会在 ClientHello 里带上目标域名。服务端或网关据此选择正确的证书和后端配置。

没有 SNI 时，同一个 IP 上托管多个 HTTPS 域名会很麻烦。服务端不知道该返回哪张证书，可能返回默认证书，最终导致域名不匹配。

排查证书不匹配时，除了看服务端证书文件，还要确认客户端是否带了 SNI、网关是否按 SNI 做了正确路由。

ALPN：协商 HTTP/1.1 还是 HTTP/2

ALPN，全称 Application-Layer Protocol Negotiation。客户端在 TLS 握手中声明自己支持的应用层协议，比如 h2 和 http/1.1，服务端选择其中一个。

如果 HTTP/2 没有生效，常见原因包括：

• 客户端没有在 ALPN 中声明 h2。
• 服务端或网关没有开启 HTTP/2。
• TLS 版本或密码套件不满足 HTTP/2 要求。
• 中间代理终止了 TLS，并在回源时降级为 HTTP/1.1。

SNI 影响“用哪张证书和哪套路由”，ALPN 影响“安全通道里跑哪种应用层协议”。这两个点都发生在真正发送 HTTP 请求之前。

常见误区

误区一：HTTPS 就一定绝对安全

HTTPS 只保证传输层安全，不保证业务逻辑安全。服务端如果存在越权、弱密码、XSS、CSRF、SSRF，攻击者仍然可以利用。HTTPS 是安全底座，不是安全终点。

误区二：证书只要没过期就没问题

证书过期只是最容易观察的一类问题。域名不匹配、证书链不完整、证书用途错误、根证书不被客户端信任、算法过旧，都可能导致失败。

误区三：非对称加密会加密所有传输内容

实际应用数据主要由对称加密保护。非对称能力主要用于身份认证和密钥协商。把所有数据都交给非对称加密，性能成本不现实。

误区四：用了 HTTPS，URL 就完全不可见

HTTPS 会加密路径、查询参数、Header 和 Body，但目标 IP、端口通常可见。传统 TLS 下，SNI 中的域名也可能明文暴露。ECH 是为了解决 ClientHello 中部分信息暴露的问题，但落地依赖客户端、服务端和 DNS 生态支持。

误区五：自签名证书和 CA 证书安全性完全一样

自签名证书也可以加密传输内容，但默认不被客户端信任。除非客户端显式安装并信任对应根证书，否则无法建立标准信任链。内网测试可以用自签名证书，公网服务不应依赖用户手动信任。

排查 HTTPS 问题的思路

HTTPS 问题不要只盯着“证书过期”。更稳妥的做法是按连接链路逐层排查。

1. 先确认错误发生在哪一层

常见现象可以粗分为：

• DNS 解析失败：域名无法解析或解析到错误 IP。
• TCP 连接失败：端口不通、防火墙拦截、负载均衡未监听。
• TLS 握手失败：证书、协议版本、密码套件、SNI、客户端信任库问题。
• HTTP 请求失败：握手成功后返回 4xx、5xx 或应用层超时。

如果浏览器显示证书错误，通常已经到 TLS 校验阶段；如果直接连接超时，可能还没进入 TLS。

2. 看证书链和域名匹配

重点检查：

• 当前访问域名是否在证书 SAN 中。
• 服务端是否返回完整证书链。
• 证书是否过期或尚未生效。
• 根 CA 是否被目标客户端环境信任。
• 网关是否因为 SNI 路由错误返回了别的证书。

命令行排查时可以用 openssl s_client 查看握手和证书链，用 curl -v 观察 TLS 版本、ALPN 结果和证书校验错误。生产排查中还要注意客户端环境差异：浏览器、Node.js、Java、移动端、容器镜像使用的信任库可能不一样。

3. 看协议版本和密码套件

老客户端可能只支持 TLS 1.0/1.1，现代服务端可能已经禁用这些版本。反过来，服务端如果只支持过旧算法，也可能被新浏览器拒绝。

排查时要确认：

• 客户端和服务端是否有共同支持的 TLS 版本。
• 是否有共同支持的密码套件。
• HTTP/2 是否需要 ALPN 协商成功。
• 中间网关是否终止 TLS 后又用另一套配置回源。

4. 看时间、缓存和会话恢复

证书校验依赖本机时间。本地时间严重错误时，证书可能被判断为未生效或已过期。

会话恢复也可能让问题表现得不稳定：老连接还能用，新连接失败；部分机器有 ticket，部分机器没有；网关集群 ticket key 不一致，导致恢复失败但完整握手成功。遇到这类问题，要区分完整握手失败和恢复路径失败。

面试回答可以怎么组织

如果面试官问“HTTPS 的原理是什么”，可以按下面顺序回答：

1. HTTP 是明文传输，存在窃听、篡改和冒充风险。
2. HTTPS 在 HTTP 和 TCP 之间加入 TLS，提供机密性、完整性和身份认证。
3. TLS 握手阶段通过证书和 CA 信任链验证服务端身份。
4. 握手阶段使用非对称能力进行密钥协商，生成对称密钥。
5. 应用数据阶段主要使用对称加密传输 HTTP 内容。
6. 为了优化性能，TLS 支持会话恢复；为了支持多域名和协议协商，握手里还有 SNI 和 ALPN。
7. 排查 HTTPS 问题时，按 DNS、TCP、TLS、HTTP 分层定位，再看证书链、SNI、ALPN、协议版本和客户端信任库。

这个回答既覆盖了主线，也能自然承接追问：证书怎么验证、为什么不全用非对称加密、TLS 1.2 和 1.3 有什么区别、HTTP/2 为什么依赖 ALPN、证书错误怎么排查。

总结

HTTPS 的主线并不复杂：HTTP 负责应用语义，TLS 负责建立安全通道。真正需要掌握的是每个机制为什么存在。

• HTTP 的核心风险是明文、可篡改、身份不可验证。
• HTTPS 通过 TLS 提供机密性、完整性和身份认证。
• 对称加密负责高效传输数据，非对称能力负责认证和密钥协商。
• 数字证书把域名和公钥绑定起来，CA 信任链让客户端能判断证书是否可信。
• TLS 握手完成参数协商、证书验证和密钥生成，会话恢复用于降低重复握手成本。
• SNI 决定多域名场景下该使用哪张证书，ALPN 决定 TLS 之上运行 HTTP/1.1 还是 HTTP/2。
• 线上排查要分层，不要把所有 HTTPS 问题都归因于“证书过期”。

记住这条链路，面试时就不会停留在“HTTPS 更安全”这种泛泛回答，也能把原理、性能和工程排查串成一套完整表达。