HTTPS协议原理

HTTPS属于应用层协议，它是在HTTP协议之上新增了加密层。HTTP协议以明文文本形式传输内容，在传输过程中易被篡改，存在安全隐患。而HTTPS通过加密技术，对传输数据进行加密处理，能有效防止数据在传输途中被窃取或篡改，保障信息传输的安全性与完整性。

1.关于加密

1.1.什么是"加密"

加密就是把明文（要传输的信息）进行一系列变换，生成密文。解密就是把 密文 再进行一系列变换，还原成 明文。在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为 密钥。

1.2.为什么要加密

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

2.常见的加密方式

2.1.对称加密

对称加密是采用单钥密码系统的加密方式，其核心特征是加密与解密共用同一密钥 —— 同一密钥可同时完成明文到密文的加密操作，以及密文到明文的解密操作，因此也被称为单密钥加密。

- 常见对称加密算：DES、3DES、AES、TDEA、Blowfish、RC2 等

- 特点：算法公开、计算量小、加密速度快、加密效率高

对称加密其实就是通过同一个 "密钥"，把明文加密成密文，并且也能把密文解密成明文。

一个简单的对称加密：按位异或：

假设 明文 a = 1234，密钥 key = 8888
则加密 a ^ key 得到的密文 b 为 9834。然后针对密文 b 再次进行运算 b ^ key，得到的就是原来的明文 1234。

2.1 非对称加密

需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

- 常见非对称加密算法(了解)：RSA，DSA，ECDSA

- 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

非对称加密要用到两个密钥，一个叫做 "公钥"， 一个叫做 "私钥"。公钥和私钥是配对的。最大的缺点就是运算速度非常慢，比对称加密要慢很多。

  - 通过公钥对明文加密，变成密文
  - 通过私钥对密文解密，变成明文
也可以反着用
  - 通过私钥对明文加密，变成密文
  - 通过公钥对密文解密，变成明文

非对称加密的数学原理比较复杂，涉及到一些 数论 相关的知识。这里举一个简单的生活上的例子。

A 要给 B 一些重要的文件，但是 B 可能不在。于是 A 和 B 提前做出约定：

B 说：我桌子上有个盒子，我给你一把锁，你把文件放盒子里用锁锁上，然后我回头拿着钥匙来开锁取文件。

在这个场景中，这把锁就相当于公钥，钥匙就是私钥。公钥给谁都行(不怕泄露)，但是私钥只有 B 自己持有，持有私钥的人才能解密。

3.数据摘要 && 数据签名

数字指纹（又称数据摘要），其核心原理是通过单向散列函数（Hash 函数） 对原始信息进行运算，生成一串固定长度的二进制串（即数字摘要）。它并非加密机制，核心作用是校验数据完整性 —— 通过对比摘要是否一致，可快速判断原始数据是否被篡改。

摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，这类算法的本质是 无限输入映射到有限输出，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）。

数字摘要与加密算法的核心区别在于：摘要过程不可逆（无 “解密” 环节，无法从摘要反推原始信息），仅用于数据一致性校验；而加密算法是可逆的，核心作用是信息保密。

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

4.加密方案

4.1 方案 1 - 只使用对称加密

如果通信双方都各自持有同一个密钥 X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容是啥了。

但事情没这么简单。服务器同一时刻其实是给很多客户端提供服务的，这么多客户端，每个人用的秘钥都必须是不同的（如果是相同那密钥就太容易扩散了，黑客就也能拿到了）。
因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情 

比较理想的做法，就是能在客户端和服务器建立连接的时候，双方协商确定这次的密钥是什么

但是如果直接把密钥明文传输，那么黑客也就能获得密钥了！！此时后续的加密操作就形同虚设了。因此密钥的传输也必须加密传输！

但是要想对密钥进行对称加密，就仍然需要先协商确定一个 "密钥的密钥"。这就成了 "先有鸡还是先有蛋" 的问题了。因此，仅依靠对称加密无法完成安全的密钥协商，这种方案并不具备可行性。

4.2 方案 2 - 只使用非对称加密

基于非对称加密的机制，若服务器先将公钥以明文形式传输给浏览器，浏览器后续向服务器发送数据时，便可先用该公钥加密后再传输。从客户端到服务器的信道看似安全 —— 毕竟只有服务器持有对应的私钥，能解密公钥加密的数据，但这一过程仍存在隐藏风险。

真正的问题在于服务器到浏览器的反向信道安全：若服务器用自身私钥加密数据发送给浏览器，浏览器虽可通过之前获取的公钥解密，但该公钥是通过明文传输获得的，一旦被中间人劫持，中间人同样能利用此公钥解密服务器发送的信息。更关键的是，公钥明文传输本身就存在 “身份认证缺失” 的漏洞：浏览器无法确认收到的公钥是否来自目标服务器，若公钥被中间人替换，客户端与服务器的双向通信都会被劫持 —— 客户端用黑客公钥加密的数据会被黑客解密，服务器用自身私钥加密的数据也会被持有虚假公钥的中间人窃取，最终导致双向通信的窃听与篡改风险。

4.3.方案 3 - 双方都使用非对称加密

（1）服务端拥有公钥 S 与对应的私钥 S'，客户端拥有公钥 C 与对应的私钥 C'。

（2）客户和服务端交换公钥。

（3）客户端→服务端通信：客户端先用服务端公钥 S 加密数据，再发送至服务端，理论上仅服务端可通过私钥 S' 解密。

（4）服务端→客户端通信：服务端先用客户端公钥 C 加密数据，再反馈至客户端，理论上仅客户端可通过私钥 C' 解密。

该方案看似实现了双向加密通信，但实际存在两大致命缺陷，导致其无法在实际场景中应用：

 - 效率极低，无法适配大数据传输。非对称加密算法的底层逻辑涉及大整数模运算、指数运算等复杂数学操作，运算效率远低于对称加密（约为对称加密的 1/1000~1/100）。

- 安全漏洞未解决，仍面临中间人攻击。未解决公钥身份认证的问题，公钥交换阶段仍以明文传输，中间人可轻易劫持并替换双方公钥 —— 将服务端公钥 S 替换为自身公钥 H，将客户端公钥 C 也替换为自身公钥 H。此时：
        - 客户端用虚假公钥 H 加密数据，中间人用自身私钥 H' 解密获取原始信息，再用真实公钥 S 加密后转发给服务端；

        - 服务端用虚假公钥 H 加密反馈数据，中间人同样用 H' 解密窃取，再用真实公钥 C 加密后转发给客户端。

        - 双方均无法察觉公钥被篡改，最终导致双向通信的数据被窃听、甚至被篡改，安全机制形同虚设。

4.4.方案 4 - 非对称加密 + 对称加密

先解决效率问题

服务端具有非对称公钥 S 和私钥 S'

- 客户端发起 https 请求，获取服务端公钥 S

- 客户端在本地生成对称密钥 C，通过公钥 S 加密，发送给服务器。

- 由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥（真的吗？）。

- 服务器通过私钥 S' 解密，还原出客户端发送的对称密钥 C。并且使用这个对称密钥加密给客户端返回的响应数据。

- 后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道， 其他主机/设备不知道密钥即使截获数据也没有意义。

由于对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密， 后续的传输仍然使用对称加密。

虽然上面已经比较接近答案了，但是依旧有安全问题。方案 2，方案 3，方案 4 都存在一个问题，如果最开始，中间人就已经攻击了呢？

5. 中间人攻击

Man-in-the-MiddleAttack，简称“MITM 攻击”

在方案 2、3、4 中，客户端获取到公钥 S 之后，对客户端形成的对称秘钥 X 用服务端给客户端的公钥 S 进行加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥 X，因为只有服务器有私钥 S' ，但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了。

假设 hacker 已经成功成为中间人

（1）服务器具有非对称加密算法的公钥 S，私钥 S'。

（2）中间人具有非对称加密算法的公钥 M，私钥 M'。

（3）客户端向服务器发起请求，服务器明文传送公钥 S 给客户端；

（4）中间人劫持数据报文，提取公钥 S 并保存好，然后将被劫持报文中的公钥 S 替换成为自己的公钥 M，并将伪造报文发给客户端。

（5）客户端收到报文，提取公钥 M（客户端当然不知道公钥被更换过了），自己形成对称秘钥X，用公钥 M 加密 X，形成报文发送给服务器。

（6）中间人劫持后，直接用自己的私钥 M' 进行解密，得到通信秘钥 X，再用曾经保存的服务端公钥 S 加密后，将报文推送给服务器。

（7）服务器拿到报文，用自己的私钥 S'解密，得到通信秘钥 X。

（9）双方开始采用 X 进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的。

上面的攻击方案，同样适用于方案 2，方案 3。

问题本质出在哪里了呢？出在客户端无法确定收到的含有公钥的数据报文，是否是目标服务器发送过来的！！！

6.证书

CA 认证

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

基本说明：

三重数据加密算法_百度百科

这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息:

证书发布机构
证书有效期
公钥
证书所有者
签名
......

需要注意的是：申请证书的时候，需要在特定平台完成生成操作，同时会生成一对密钥对，即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。

其中公钥会随着 CSR 文件，一起发给 CA 进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）。

证书的本质就是一份携带了签名的明文数据。

7.数字签名

签名的形成是基于非对称加密算法的，注意，目前暂时和 https 没有关系，不要和 https 中的公钥私钥搞混。

服务器首先发起申请：服务器生成自己的公钥 - 私钥对，然后向 CA 提交证书申请（包含服务器公钥、域名、机构信息等明文数据）。

左边 “签名” 流程（签名方，如服务器、CA 机构等）

（1）对原始数据（可以是文件、证书明文等）用散列函数计算出固定长度的散列值（摘要）。

（2）用签名者的私钥（如服务器私钥、CA 私钥）对散列值加密，生成数字签名。

（3）将数字签名附加到原始数据上，形成数字签名的数据。

右边 “验证” 流程（验证方，如客户端、浏览器等）

（1）从数字签名的数据中分离出原始数据和数字签名。

（2）对原始数据重新用相同的散列函数计算散列值。

（3）用签名者的公钥（如服务器公钥、CA 公钥）解密数字签名，得到签名时的散列值。

（4）对比两个散列值，若一致则签名有效（数据未被篡改、签名者身份可信）。

服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书就可以颁发给服务端了。有了证书，我们就得到了更加安全的方案五。

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

在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个证书，证书包含了服务端的公钥，也包含了网站的身份信息。

客户端进行认证

当客户端获取到这个证书之后，会对证书进行校验（防止证书是伪造的）：

判定证书的有效期是否过期

判定证书的发布机构是否受信任（操作系统中已内置的受信任的证书发布机构）

验证证书是否被篡改：将签名和明文数据分开，从系统中拿到该证书发布机构的公钥，对签名解密，得到一个 hash 值（称为数据摘要），设为 hash1。然后计算数据的 hash 值，设为 hash2。对比 hash1 和 hash2 是否相等，如果相等，则说明证书是没有被篡改过的。

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

中间人篡改了证书的明文

由于他没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名。

如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

中间人整个掉包证书？

因为中间人没有 CA 私钥，所以无法制作假的证书；

所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包；

这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端；

认证信息，如果整体掉包，客户端依旧能够识别出来。

永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的

总结

HTTPS 工作过程中涉及到的密钥有三组。

第一组（CA 机构的非对称密钥对）
用途：校验服务器证书的合法性（防篡改、防伪造）；
密钥归属：CA 私钥（CA 持有）、CA 公钥（客户端预置）；
流程：服务器返回带 CA 签名的证书 → 客户端用 CA 公钥解密签名 → 验证证书未被篡改，确认证书中 “服务器公钥” 可信。

第二组（服务器的非对称密钥对）
用途：安全传输后续通信的对称密钥；
密钥归属：服务器私钥（服务器持有）、服务器公钥（嵌入 CA 证书中）；
流程：客户端用可信的 “服务器公钥” 加密对称密钥 → 服务器用自身私钥解密 → 双方拿到相同的对称密钥。

第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。一切的关键都是围绕这个对称加密的密钥，其它的机制都是辅助这个密钥工作的。

第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。

第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。