前言

总所周知，HTTP 通信是不安全，理由有三：

• 通信内容明文传输，内容可能被窃听
• 无法证明报文完整性，内容可能被篡改
• 不会验证通信方的身份，身份可能被冒充

而 HTTPS 通过 SSL/TLS 协议实现安全传输，SSL/TLS 协议与 HTTPS 相比之下，多了以下优势：

• 内容加密传输，第三方无法窃听
• 内容传输经过完整性校验，一旦被篡改，通信双方会立刻发现
• 具有身份证书，防止身份被冒充

既然如此，现在 SSL/TLS 协议是如何做到的呢？要解释这个过程，需要了解什么是对称加密和非对称加密。

加密方式

对称加密

加解密使用同一个密钥，通信双方都需要知道这个密钥，才能加解密。加解密效率高、速度快。但缺陷在于对密钥的管理和分发上比较困难，不太安全，密钥管理负担很重

非对称加密

加解密使用不同的密钥，一个是公开的公钥，一个是私有的私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。安全性更高，但加解密耗时长、速度慢，只适合对少量数据进行加解密。应用范围非常广泛，SSH, HTTPS, TLS，电子证书，电子签名，电子身份证等等。

SSL/TLS 协议基本思路就是非对称加密法，但是这种加密法有一些问题：

• 公钥是公开的，所以私钥加密的信息，任何拿到公钥的人都能解密
• 公钥不包含服务端信息，无法确保服务端身份的合法性，存在中间人攻击的风险
• 非对称加密性能低，降低了传输效率

所以要让 SSL/TLS 安全可靠，还需要考虑一些问题。

运行过程

非对称加密计算量太大，如何减少耗时？

将对称加密和非对称加密结合起来，实现高效率且安全性高的通信。基本思想就是在交换密钥环节采用非对称加密方式，之后建立通信交换报文阶段则采用对称加密方式。举个例子：

• 客户端向服务端索要并验证公钥
• 客户端用这个公钥加密自己的“对话私钥”，发给服务端
• 服务端通过私钥解密得到“对话私钥”，然后双方采用这个“对话密钥”进行通信

如何保证内容不被篡改？数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？校验数字签名。
数字签名有两个作用：

• 能确定信息是由发送方签名并发出，因为别人无法假冒发送方的签名
• 能确定信息的完整性，证明数据是未被篡改的

生成数字签名的过程：内容 --哈希→ 消息摘要 --私钥加密→ 数字签名
校验数字签名：内容 --哈希→ 消息摘要 === 消息摘要 ←公钥解密-- 数字签名

如何获取公钥？

那么问题就来了，公钥这么重要，如何保证获取公钥，并证明公钥是可信度呢？此时需要引入证书颁发机构（Certificate Authority，简称CA），CA 数量并不多，客户端如浏览器端内置了所有受信任的 CA 的证书。CA 对服务端的公钥和其他信息数字签名后生成证书。将公钥放在数字证书中。只要证书是可信的，公钥就可信。

如何确保数字证书可信？

1. 服务端想第三方机构 CA 提交公钥等信息申请认证
2. CA 通过审核后，会想申请者签发认证证书。证书包含：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号的信息的明文，同时包含一个数字签名。签名产生算法：使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。
3. 客户端向服务端发起 HTTPS 请求（包含支持的协议版本，如 TLS 1.0；随机数 rand1；支持的加密方法，如 RSA；支持的压缩方法）
4. 服务端做出回应（确认加密协议，如 TLS 1.0，如果和浏览器不一致，服务器关闭加密通信；随机数 rand2；确认加密方法，如 RSA；证书文件）
5. 校验是否在有效期内，是否被吊销，证书文件的上一级证书是否有效，这是一个递归的 过程，知道验证到根证书（操作系统或客户端内置的 Root 证书）。
6. 如果证书合法，则会读取证书明文信息，采用相同的散列函数计算得到信息摘要，然后用证书读取出来的 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公钥是可信的。
7. 然后客户端生成随机数 rand3，然后用证书取得的公钥以及前面协商好的加密方法来加密随机数 rand3，发送给服务端。
8. 服务端接收到第三个随机数，客户端和服务端用协商好的加密方法和三个随机数，就能加密得到后续通信用对称密钥。然后采用对称加密的方式来安全通信了。