HTTPS 是如何保证安全的

众所周知，HTTP 协议是明文传输的，在网络世界里用 HTTP 协议发送报文相当于裸奔，于是就有了 HTTPS
这个 S 是什么呢，是如何保证我们发送的报文就不被窃取和篡改了呢，让我们慢慢道来

其实这个 S 指的就是 SSL/TLS
我们知道 HTTP 在网络协议中属于应用层，在发送报文时会将报文交给 TCP 进行传输，而 TCP 层面则是明文的，于是 HTTPS 在将报文发给 TCP 之前，通过 TLS 将报文进行加密后再通过 TCP 进行传输

那么 HTTPS 是如何进行加密的呢

说到这里，我们需要先来了解一下加密算法

对称加密

所谓对称加密，就是用来加密和解密的密钥都是同一个， 当我们使用对称加密的时候，就是用密钥将元数据通过加密算法，转变成密文，当另一方需要将密文转成原文的时候，需要用同一个密钥和相对应的解密算法，将密文给还原成原文。
但对称加密的缺陷在于，如何保证密钥的安全性，如何保证只有通信的双方才持有该密钥而不被其他人窃取，而非对称加密就是来解决这个问题的

非对称加密

非对称加密，是因为数学家们研究出了一种算法，这种算法两个不同的密钥，通过密钥 A 对原文进行加密后，只能通过密钥 B 进行解密。和对称加密不同的是，非对称加密只有一个算法，不需要『加密算法』和『解密算法』，也就是说同一个算法，经过密钥 A 加密过的密文只能由密钥 B 解密。

但所谓的『原文』和『密文』只是相对的，我们也可以将所谓的『原文』当做被加密过的数据，而把『密文』当做加密前的数据，所以从下图看，密钥 A 和密钥 B 其实也是可以相互交换的，密钥 B 可以用来当做加密用的密钥，而让密钥 A 当做解密用的密钥。

但一般来说不会这么做，这是因为非对称加密的算法是有很多种的，而密钥 A 和密钥 B 是成对存在的，一般来说是不能相互推导的，即我不能通过密钥 A 计算出密钥 B，也不能通过密钥 B 计算出密钥 A，但也不是绝对的，其实也是可以推导出来的，只不过对于如今的计算运力来说不足以在短时间内推导出来，可能需要上百年上千年，所以我们姑且认为是无法推导出来的。
但也有一些非对称加密算法是例外的，有些非对称加密的算法是可以通过密钥 A 计算出来密钥 B 的。
所以这个时候，我们就不能用密钥 B 进行加密而把密钥 A 公开了。因为这样的话，就相当于所有人都知道了密钥 A 和 密钥 B 是什么，就相当于没有加密了。

而密钥 A ，我们把它称为私钥，密钥 B 称为公钥。
所谓私钥，就是要对信息进行加密的持有者所持有的密钥，这个密钥只能自己持有，不能公开，而公钥是可以在任何地方公开的，只有持有私钥的一方才可以将被公钥加密过的信息解密得到原文。

也就是说，假如我要发送一个消息给对方，我需要先得到对方的公钥，然后用对方的公钥对信息进行加密后再发送给对方，而只有对方(公钥对应的私钥拥有者)才能将信息还原成原文

在消息的发送前，发送方需要获取到接收方的公钥，而在这个过程中，发送方是如何确定这个公钥就真的是接收方的公钥而不是被篡改过的呢。
且听我娓娓道来。
让我们先来看一个知识点(敲黑板)

非对称加密的应用

数字签名

所谓数字签名，就是证明这个东西是我发出的
在网络世界里，所有的数据包都有可能被截获篡改，所以当我们收到某个消息时，如何确定这条消息就是我认为的那个人发出的呢，这就需要用到『非对称加密』的一个应用–『数字签名』了。

通过上图可见，当接收方对比 摘要 和 摘要’ 相同时，就可以认为这条消息是没有被篡改过的，是来自于这个公钥所对应的私钥的拥有者发出的。

但在我们的消息发送的过程中还有个问题，接收方怎么就知道这个公钥就是我认为的消息的发送者的呢。万一中间有人把所有的信息(公钥修改了，同时用新的公钥计算出密文和 hash)都修改了，那接收方通过这种方式验证出来的结果都是正确的，那怎么办。

于是问题的痛点就落在了我们需要保证公钥的正确性上

这就需要证书了

数字证书

为了解决无法证明公钥的正确性的问题，有了数字证书。
数字证书是由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

要得到一份数字证书，需要由服务器端的(或者说是信息的发送方)到数字证书认证机构去申请，而 CA 确认该身份后通过申请，则会给该申请者一个包含经过 CA 签名的公钥的数字证书。

数字证书中包括了「签名」+「csr 文件」

其中，csr 文件包括信息发送方的「公钥」、「申请者信息」、「域名」等
CA 机构通过对这些信息通过摘要算法计算出摘要(记为摘要 A)，并用私钥进行加密，得到「签名 A」，并把「签名 A」 和 csr 文件内容打包成证书

在网络传输中，接收者就会拿到这个证书，进行验证

首先接收者的系统/浏览器中内置了 CA 机构的公钥，拿到公钥后对接收到的证书中的「签名 A」进行解密，得到「摘要 A」，再使用相同的摘要算法对 csr 文件进行计算，得到「摘要 B」，比对「摘要 A」和「摘要 B」，如果无法计算出「摘要 A」或者「摘要 A」和「摘要 B」不相同，则认为这个证书不可信，否则则认为这个证书可信，则可以获取到 csr 文件中信息发送者的公钥

至此就完成了信息发送者的公钥的安全传输过程(防止被篡改和替换)

图片来源于 数字证书、签名到底是什么？这篇文章讲得太好了

TLS 四次握手

Client Hello

客户端向服务端发送

• TLS 支持的版本
• 支持的加密算法以及版本
• 支持的压缩算法
• Client Random A

Server Hello、Certificate、Server Hello Done

服务器向客户端进行响应

• 选择的 TLS 版本
• 选择的加密算法
• Client Random B

Certificate

• 发送服务器的证书
  Client 在收到 Server 发送过来的证书后会对证书进行校验

Server Hello Done

Client Key Exchange,Change Clpher Spec,Finish

Client Key Exchange

• 证书校验通过后，Client 会使用 Random A 和 Random B 生成一个 pre-master 的值，
  通过 Server 的 Public Key 对 pre-master 进行加密后发送给 Server

Change Clpher Spec:

• 并告知服务端后续使用算法计算出来的 key 对通信内容进行加密

  此时 Client 已经拥有了 Random A 、 Random B 和 pre-master，用这三个值可以计算出 session-key，用于作为对称加密的密钥

Finish:

• 对上述所有握手过程中的数据使用商量好的 Hash 算法计算 HashCode，并使用 session-key 进行加密

New Session Ticket,Change Cliper Spec,Finish

Server 使用自己的私钥对上一步中发来加密过的 pre-master 进行解密，得到明文的 pre-master
此时 Server 也拥有了 Random A 、 Random B 和 pre-master ，使用商量好的算法计算出 session-key
并使用 session-key 对上一步中 Client 中发来的数据和 HashCode 进行校验，
以用来证明 Client 计算的 session-key 是正确的

New Session Ticket

Server 发送给 Client 的 Session，用于下一次会话使用，Client 的下一次请求在 Client Hello 中带上 Session Ticket，Server 判断该 Session Ticket 有效且正确则可以跳过握手中的部分过程

Change Cliper Spec:

• 告知 Client 后续的信息都通过 session-key 进行加密

Finish:

• 对上述所有握手过程中的数据使用商量好的 Hash 算法计算 HashCode，并使用 session-key 进行加密

Application Data

这一步不算是 TLS 的范畴了而是 HTTP 协议的范畴
Client 使用商量出来的 session-key 对数据进行对称加密发送给 Server ，Server 接收到数据后使用 session-key 进行解密得到明文数据，再将结果进行加密后返回给 Client

总结

TLS 的握手示意过程如下

|----------Client----------|----------Server----------|
|      Client Hello       -->                         |
|-----------------------------------------------------|
|                          |     Server Hello         |
|                          |     Certificate          |
|                         <--  Server Hello Done      |
|-----------------------------------------------------|
|   Client Key Exchange    |                          |
|   Change Cipher Spec     |                          |
|          Finish         -->                         |
|-----------------------------------------------------|
|                          |    New Session Ticket    |
|                          |    Change Cipher Spec    |
|                         <--         Finish          |
|-----------------------------------------------------|
|     Application Data    <->      Application Data   |
|-----------------------------------------------------|

Wireshark 抓包的握手过程

参考

数字证书、签名到底是什么？这篇文章讲得太好了