应用层————HTTPS协议

有了前面HTTP的讲解，对于HTTPS的讲解，我们主要把重点放在如何保证数据安全的进行交互。

1.背景知识

1.1 HTTPS是什么

HTTP 协议以明文方式传输数据，所有内容（包括密码、个人信息等）在网络中都是可读的，这使得数据在传输过程中存在被窃取、篡改或伪造的风险。

HTTPS 并非全新协议，而是在 HTTP 基础上增加了一层加密层（SSL/TLS）。它通过加密、认证和完整性校验三大机制，确保数据传输的安全性。

SSL/TLS 是目前被广泛认可并采用的官方加密标准，几乎所有重要网络通信（如网银、电商、社交媒体）都依赖它保障安全。然而，这种普及性也使其成为黑客攻击的重点目标。

随着密码学研究深入和计算能力提升，旧的加密算法可能被发现存在漏洞。为应对不断演变的安全威胁，相关机构会定期发布新的协议版本和安全套件，修复已知漏洞并引入更强大的加密机制，确保通信安全能够跟上技术发展步伐。

1.2 什么是密文

加密就是把明文（要传输的信息）进行一系列变换生成密文。

解密就是把密文进行一系列变换还原成明文。

明文和密文是通过一系列算法进行转化的。

在这个加密和解密的过程中，往往需要一个和多个中间的数据辅助进行这个过程，这样的数据称为密钥。

1.3 为什么要加密？

运营商劫持：由于我们通过网络传输的任何数据包都会经过运营商的网络设备（路由器、交换机等），那么运营商的网络设备就可以解析出我们传输的数据内容进行篡改。点击下载按钮，其实就是在给服务器发送一个HTTP请求，获取到HTTP响应，其实就包含了该APP的下载链接。运营商劫持之后，就发现这个请求是我们要下载的APP，那么就自动把交给用户的响应篡改成QQ浏览器的下载地址。

所以，因为HTTP内容是明文传输的，明文数据会经过路由器、WiFi热点、通信服务运营商、代理服务器等多个物理节，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对信息进行加密。

1.4 常见的加密方式

1.4.1 对称加密

• 采用单钥密码系统的加密方式，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的。
• 特点：算法公开、计算量小、加密速度快、加密效率

1.4.2 非对称加密

• 需要两个密钥来进行加密和解密：公开密钥（用于对明文加密）和私有密钥（用于对密文解密）。
  • 两种常见用法：
    • 公钥加密 → 私钥解密（用于保密通信）：我用你的公钥加密信息 → 只有你有私钥才能解密
    • 私钥加密 → 公钥解密（用于数字签名）：服务器用私钥 “加密” 一段数据摘要 → 任何人用服务器的公钥都能解密
• 特点：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂而使得加密解密速度没有对称密钥加密解密的速度快、用公钥加密就只能由拥有私要的人来解密。

公钥通常以明文形式传输
公钥本来就是设计成公开的，所以它的传输方式一般就是明文：

• 在 TLS/SSL 握手 时，服务器会把包含公钥的证书明文发给客户端
• 这个证书在网络上传输时，任何能抓包的人都能直接看到公钥内容
• 中间人甚至可以替换掉这个证书（如果没有额外验证机制）

1.5 数据摘要&&数据指纹

数据指纹：数据指纹并不是一种加密机制，但可以用来判断数据有没有被篡改。

• MD5：MD5 可以判断文件是否被篡改，它会先对原始文件计算 MD5 哈希值并保存，接收方获取文件后重新计算 MD5，若与原始值一致则文件未被篡改，否则说明内容已改变。这个MD5哈希值就是就是该文件的数据指纹。

应用场景

百度网盘的秒传就运用了这个原理，当用户发起上传请求时，百度网盘客户端会先计算文件的 MD5 哈希摘要（即数据指纹）。客户端将这些指纹和文件信息发送到服务器，服务器在数据库中进行摘要匹配。如果资源服务器中已有相同指纹的文件，那就说明已有其他用户上传过相同文件，服务器就直接为用户创建一个指向该文件的软链接，实现秒传；如果没有匹配项，则需要完整上传文件，并存入数据库与资源服务器，供后续用户秒传使用。

1.6 数字签名

数据摘要经过加密就得到数字签名。

2.HTTPS工作流程

既然要保证数据安全，就要进行加密。网络传输中不再直接传输明文而是加密后的“密文”。加密的方式有很多，但是整体可以分成两大类：对称加密和非对称加密。

2.1 方案1：只使用对称加密

优点

• 通信双方持有相同密钥，可直接对数据进行加密解密
• 即使数据被截获，黑客若无密钥也无法还原内容
• 加密解密速度快，适合大数据量传输

缺点

• 密钥分发困难：需在通信前安全地将密钥传递给对方
• 密钥管理复杂：
  • 多客户端场景下，使用相同密钥安全性极低
  • 为每个客户端分配不同密钥会产生庞大的管理开销
• 更新维护不便：密钥更换需所有客户端同步更新，实际操作困难
• 安全性依赖密钥保密：一旦密钥泄露，所有通信内容都可能被破解

2.2 方案2：只使用非对称加密

问题

1. 时间消耗久：非对称加密算法计算复杂度高，处理速度慢，大量数据传输时会造成明显延迟。

2. 只能保证单向安全

• 客户端→服务器：用服务器公钥加密，只有服务器私钥能解密，这部分安全
• 服务器→客户端：
  • 若服务器用私钥加密数据，任何拥有公钥的人都能解密
  • 公钥通常以明文形式传输，易被中间人截获
  • 中间人拿到公钥后可解密所有服务器发送的数据
  • 导致服务器到客户端的通信不安全

2.3 方案3：双方都使用非对称加密

  1.   服务器拥有公钥S与对应的私钥S'，客户端拥有公钥C与对应的私钥C'。
2.   客户端和服务端交换公钥。
3.   客户端给服务器发送信息：先用S对数据加密再发送，只能由服务器解密，因为只有服务器有私钥S'
4.   服务端给客户端发送信息：先用C对数据加密再发送，只能由服务器解密，因为只有服务器有私钥C'

问题

1. 效率低

• 计算开销大：非对称加密算法复杂度高，直接加密大量数据速度慢
• 双向加密负担重：客户端和服务器都需进行大量公钥 / 私钥运算

2. 安全问题

• 公钥真实性无法验证：公钥交换过程中没有身份验证机制
• 中间人攻击风险高：
  • 攻击者可截获并替换双方公钥
  • 分别与客户端和服务器建立独立加密通道
  • 完全控制和窃取通信内容
• 缺乏完整性保障：只加密不签名，无法确保数据在传输中未被篡改

2.4 中间人攻击——针对1、2、3方案

1. 服务器具有非对称加密算法的公钥S，私钥S'
2. 中间人具有非对称加密算法的公钥M，私钥M'
3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端
4. 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端。
5. 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，自己形成对称秘钥X，用公钥M加密XXXX，形成报文发送给服务器。
6. 中间人劫持后，直接用自己的私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
7. 服务器拿到报文，用自己的私钥S'解密，得到通信秘钥X
8. 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的。

本质：客户端无法验证服务器发来的公钥是否合法。

2.5 方案4：非对称加密+对称加密

流程

1. 服务端准备：生成非对称密钥对（公钥 S、私钥 S'）
2. 获取公钥：客户端通过 HTTPS 请求获取服务端公钥 S
3. 密钥协商：
4. 客户端生成随机对称密钥 C
5. 用公钥 S 加密 C 并发送给服务器
6. 密钥解密：服务器用私钥 S' 解密获取对称密钥 C
7. 数据传输：后续通信使用对称密钥 C 加密所有数据

优势

• 安全性高：密钥交换过程安全，中间设备无法获取对称密钥
• 性能优化：仅在握手阶段使用非对称加密，后续通信使用高效的对称加密
• 数据安全：即使数据被截获，没有密钥也无法解密

潜在问题

• 公钥信任问题：客户端需确保获取的公钥确实来自目标服务器（防止中间人攻击）
• 初始握手风险：首次公钥传输若被篡改，整个通信将不安全
• 密钥管理：服务端私钥需妥善保管，泄露则整个系统被攻破
• 前向安全性：若长期使用同一对称密钥，过去的通信记录可能被解密

2.6 方案5：非对称加密+对称加密+证书认证

2.6.1 CA认证

服务端使用 HTTPS 前的准备

• 需向 CA 机构申领一份数字证书
• 证书中包含证书申请者信息、公钥信息等
• 服务器将证书传输给浏览器，浏览器从中获取公钥
• 证书相当于 "身份证"，证明服务端公钥的权威性

实际上的CA证书并不是挂着墙上的证书，而是要安装在服务器里的电子文件。

证书申请流程

1.生成 CSR（证书签名请求）

• 需将域名、申请者信息及公钥打包
• 可本地完成或通过在线工具生成
• 在线生成时系统会自动生成公钥与私钥，并提供 CSR 下载

2.提交审核

• 将 CSR 提交给权威 CA 机构审核
• CA 验证申请者身份及域名所有权
• 可选择正规证书申请服务商代为处理

3.签发证书

• 审核通过后 CA 签发证书

CA 签发证书的机制

• CA 使用自己的公钥和私钥进行签发，与客户端 / 服务端密钥对无关
• 签发过程：

                1.对证书内容（明文）计算 MD5 等数据摘要

                2.用 CA 私钥对摘要进行非对称加密，形成数字签名

• 此签名机制与 HTTPS 传输过程无关，注意不要混淆

客户端验证证书流程

证书由两部分组成：

• 明文内容（含申请者信息、公钥等）
• CA 的数字签名

• 用 CA 公钥解密签名得到摘要
• 对证书明文重新计算摘要
• 比对两者是否一致：
  • 一致：证书未被篡改且确实由该 CA 签发
  • 不一致：证书可能被篡改或来源不可信

2.6.2 引入证书后的通信流程

关键点：客户端只认CA的公钥，这就意味着只有CA能够进行证书的签发，因为CA本身就有私钥。中间人没有资格形成全新证书。

2.6.3 常见问题

2.6.3.1 中间人有没有可能篡改的证书？

• 就算中间人篡改了证书的明文，由于他没有CA机构的私钥，所以无法哈希之后用私钥加密形成签名，那么也就没有办法对篡改后的证书形成匹配的签名。
• 如果强行篡改客户端收到该证书后发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

2.6.3.2 中间人有没有可能把整个证书调包呢？

• 因为中间人没有CA私钥，所以无法制作假的证书。
• 所以中间人只能向CA申请真证书，然后用自己申请的证书进行调包。
• 这个确实能做到证书的整体调包，但是别忘记证书明文中包含了域名等服务端认证信息，如果整体调包，客户端依旧能够识别出来。（世界上不可能有相同的域名）
• 永远记住中间人没有CA私钥，所以对任何证书都无法进行合法修改，包括自己的。

2.6.3.3 为什么摘要内容在网络传输的时候一定要加密形成签名？

常见的摘要算法有MD5和SHA系列，以MD5为例，我们不需要研究具体的计算签名的过程，只需要了解MD5的特点：

• 定长：无论多长的符串，计算出来的md5值都是固定长度（16字节版本或32字节版本）。
• 分散：源字符串只要改变一点点，最终得到的MD5值都会差别很大。
• 不可逆：通过原字符串生成的md5很容易，但是通过md5还原成原串理论上是不可能的。

因为md5有这样的特性，我们可以认为如果两个字符串的md5值相同，则认为这两个字符串相同。

2.6.3.4 为什么签名不直接加密，而是要先哈希形成摘要？

缩小签名密文的长度，加快数字签名的验证签名的运算速度。

2.6.4 完整流程

2.6.5 总结

第一组（非对称加密）

• 服务器端：持有与证书对应的私钥（生成 CSR 时一并生成）
• 客户端：通过操作系统 / 浏览器内置可信 CA 列表，持有 CA 公钥
• 作用：
  • 服务器发送带数字签名的证书
  • 客户端用 CA 公钥验证证书签名
  • 确保证书未被篡改且来源可信
  • 安全获取服务器公钥

第三组（对称加密）

• 组成：客户端与服务器共享的对称密钥
• 作用：
  • 用于后续所有数据传输的加密和解密
  • 保证通信内容的机密性

对称密钥是整个 HTTPS 安全体系的核心：

• 第二组非对称加密：为了安全地将对称密钥从客户端传给服务器
• 第一组非对称加密：为了让客户端安全获取第二组的公钥

这种设计既保证了安全性（通过非对称加密），又保证了性能（通过对称加密）。