HTTP 和 HTTPS 有什么区别？TLS 怎样防止窃听、篡改和冒充？

🧑‍💻 面试官：HTTPS 比 HTTP 多了什么？

🙋‍♂️ 我：通常是在 HTTP 外面加 TLS，提供传输加密、完整性保护和服务端身份验证。

🧑‍💻 面试官：为什么只加密还不够？攻击者也可以给我一个公钥。

🙋‍♂️ 我：需要验证公钥属于我想访问的服务，而不是任意一方。

🧑‍💻 面试官：网页有小锁，但后端允许用户读取别人的订单。TLS 能拦住吗？

TLS 要保护「传给谁、路上能否被看见或改动」，它不负责决定用户能看哪一笔订单。

面试速答（60 秒版）

HTTP 定义请求和响应的语义，HTTPS 通常指通过 TLS 保护的 HTTP 通信。HTTP/3 使用 QUIC，而 QUIC 也集成了 TLS 1.3 的安全机制。

TLS 主要处理保密性、完整性和身份验证。以常见的 TLS 1.3 证书握手为例，客户端验证证书和域名，双方通过密钥协商得到会话密钥，再用对称加密保护后续数据。

证书不是把网页内容直接加密的工具，也不是网站业务一定可信的证明。传输加密的终点如果是反向代理，后面一段链路还需要单独保护。

因此，HTTPS 能减少传输途中的窃听、篡改和冒充风险，但不能替代登录、订单权限、输入校验或服务端安全。浏览器显示小锁，不等于整个应用没有漏洞。

传输安全与业务权限分开

假设浏览器提交订单查询。HTTP 规定方法、路径、状态码、字段和响应等含义，但这些语义本身不提供密码学保护。

如果使用没有加密的传输，中间网络节点可能看到内容，也可能改变内容。HTTPS 让这些 HTTP 数据在受保护的连接中传输；服务器最终解密以后，仍然按 HTTP 语义处理。HTTP 语义标准 RFC 9110区分了 HTTP 与 HTTPS 的访问要求。

常见 HTTP/1.1、HTTP/2 可以通过 TLS 连接；HTTP/3 的运输方式不同，不能把所有 HTTPS 都画成“HTTP→TLS→TCP”。

如果客户端只接受对方随便提供的公钥，攻击者就可能冒充订单服务，与客户端建立一个“很加密”的连接。

因此，客户端要检查证书链是否受信任、访问域名是否匹配、证书是否在有效期及其他必要条件内。服务端还要在握手中证明自己拥有相应私钥，不是只把别人的证书文件发过来。

证书把身份验证与密钥联系起来，但普通网站证书并不认证每一项业务承诺。一个诈骗网站也可能为自己的域名取得有效证书，因此小锁不能证明“值得转账”。

这里看常见的证书加临时密钥协商握手，不展开 PSK 恢复和所有可选路径。

客户端与服务端交换握手信息和密钥协商所需的公开材料，各自计算共享秘密，并派生后续会话密钥。它们不是把完整会话密钥原样放到网络上传给对方。

服务端的 CertificateVerify 使用签名证明相应私钥持有者参与了这次握手，Finished 又对握手过程进行确认。后续应用数据使用对称加密及完整性保护，而不是每个 HTTP 字节都用证书公钥来加密。TLS 1.3 标准 RFC 8446定义了这些机制。

如果受保护的记录被改动，校验会失败，不能让攻击者悄悄把“退款 10 元”改成“退款 1000 元”后仍正常通过。

证书认证与临时密钥协商不同

假设浏览器到网关使用 HTTPS，网关解密后再以普通 HTTP 请求后端。

浏览器到网关这一段受到保护，不表示网关到后端也已经加密。网关还能看见明文，因此需要把它放在可信边界内，保护后端链路，并避免日志记录密码、完整令牌等敏感信息。

代理、终端设备或者服务器被攻陷时，加密传输本身也不能防止它们读取已经解密的数据。分析安全方案时，要沿数据经过的每一段检查，不能只看浏览器地址栏。

TLS终止后的内部明文边界

需要。常见证书握手主要验证服务端，业务仍需要确认用户身份，并检查对象权限。

即使用户已经登录，也不能让他通过改订单编号读取别人的订单。这个检查要在服务端执行，TLS 没有订单归属信息。

关闭以后，客户端可能仍然加密，却失去了确认对方身份的关键保护，容易接受冒充服务。

应修复证书链、域名或信任配置，而不是把验证关掉当成生产解决方案。测试环境也应限制范围，避免把不安全选项带上线。

需要非常谨慎。早期数据存在重放风险，不能默认适合有副作用的请求。

是否使用要结合业务幂等和协议防护；不能因为减少一次等待，就把创建订单或付款自动放进去。会话恢复不等于所有安全属性都与完整握手完全一样。

HTTP：规定应用请求响应语义。

HTTPS：通过安全传输保护 HTTP，注意 HTTP/3 的运输差异。

TLS：保密、完整性与身份验证，各有对应机制。

证书：帮助确认对方身份，不直接加密全部业务内容。

应用边界：登录、对象权限和内部链路仍要单独保护。