HTTPS安全防窃听、防冒充、防篡改三大机制原理

前言

        本文内容主要对以下两篇文章内容整理过滤，用最直观的角度了解到HTTPS的保护机制，当然啦，如果想要深入了解HTTPS，本文是远远不够的，可以针对以下第一个链接中的文章拓展板块进行学习，希望大家通过本文能够对HTTPS有一个初步的认识，

你真的了解HTTPS吗？（一） - HTTPS和加密 - 知乎 (zhihu.com)

1.5 万字 + 40 张图解 HTTP 常见面试题 - 知乎 (zhihu.com)

HTTPS

HTTPS公认的三大优势有：

1. 数据加密，防窃听：HTTPS中的对称加密和非对称加密
2. 身份验证，防冒充：HTTPS的CA和证书
3. 完整性校验，防篡改：HTTPS的哈希

HTTPS混合加密——防窃听

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥SK」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥SK」的方式加密明文数据。

HTTPS为什么同时要有对称加密和非对称加密两种加密方式？

• 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
• 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

        解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通，这种设计同时兼顾了安全和效率

HTTPS对称加密的密钥SK如何产生和传输？

HTTPS分为2个过程

1. 协商对称加密密钥SK的非对称加密阶段，称为TLS握手阶段。
2. 使用SK对数据（对话内容）进行对称加密的阶段，称为数据通信阶段。

TLS握手阶段

产生对称密钥SK，主要基于三种常见的办法：

• 基于非对称加密算法

• 基于专用密钥交换算法，常见有DH、ECDH等

• 基于共享的secret，常见有PSK，SRP等

数据通信阶段

        发送端首先用密钥SK对通信内容 + 通过摘要算法算出明文的「指纹」一同进行对称加密，接着通过网络传输出去；服务端收到数据后，用SK先将数据解密出明文，通过摘要算法算出明文的「指纹」，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

HTTPS的有几套非对称加密？目的是什么？是否可以省略？

直接给出答案：2套非对称加密。

        第一套用于协商对称加密密钥SK；第二套用于数字证书签名加密。这两者的区别是：前者是服务器端（如果是双向验证的话，客户端也会有一套非对称加密公私钥）产生的。私钥在服务端上；后者是CA机构产生的，私钥在CA机构那边。并且，这2套都不可以省略。（这个说法略不严谨，但是在实际操作中，确实都不建议省略。）

HTTPS数字证书——防冒充

        在 HTTPS/TLS 协议中，客户端和服务器都有一份公钥和私钥。客户端会首先发起连接请求，服务器会将自己的公钥发送给客户端。客户端接收到公钥之后，会使用该公钥对信息进行加密，并将密文发送给服务器。在接受到加密信息的服务器端，会使用该服务器私钥（不是客户端私钥）对密文进行解密，得到原始信息。这就存在些问题，如何保证公钥不被篡改和信任度？

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。主要依赖于一个“防伪标识” — 数字签名

        数字签名生成过程是首先对原文作哈希，把一段不定长的文本映射成固定长度的字符空间，接着再用CA机构的私钥对这段定长字符做加密。大大提高了整体的运算效率。

申请证书

        用户向CA机构提交自己的信息（如域名）和公钥（用于TLS握手阶段），CA机构利用的自己的私钥对其加密生成数字证书，通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

验证证书

        接受证书的一端先对除数字签名外的其他部分做一次相同的哈希算法（证书中指明了哈希算法），得到这段文本的哈希映射，记作H1；获取CA机构的公钥对数字签名属性做解码，得到了CA机构计算出的哈希映射，记作H2。对比H1和H2两个字符串是否严格相等，若是，代表该证书的信息未被篡改，证书有效；否则，证书内容被篡改，证书无效。 若证书有效，接受端会再进行对端的身份校验（验证域名） ，若身份验证通过，接收端会拿证书上的公钥加密接下来整个TLS握手阶段的会话密钥SK之后，发送给服务端。然后在服务端用私钥进行解密出SK

CA的公钥已事先置入到了浏览器或操作系统里

HTTPS的哈希——防篡改

        在数据通信阶段，SSL/TLS会对原始消息（message）做一次哈希，得到该消息message的摘要，称为消息摘要（Message Digest） 。对端接受到消息后，使用协商出来的对称加密密钥解密数据包，得到原始消息message；接着也做一次相同的哈希算法得到摘要，对比发送过来的消息摘要和计算出的消息摘要是否一致，可以判断通信数据是否被篡改。

总结：HTTPS通信流程

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

SSL/TLS 的「握手阶段」涉及四次通信

1. 客户端向服务器发起加密通信请求，也就是 ClientHello 请求。该请求中主要内容有客户端支持的SSL/TLS版本 + 一个随机数
2. 服务器确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。反之向客户端发出响应，也就是 SeverHello。该请求中主要内容有CA数字证书 + 一个随机数

1. 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

   （1）一个随机数

   （2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

   （3）之前所有内容的发生的数据做一次哈希，得到消息摘要

   客户端通过这三个随机数用双方协商的加密算法，各自生成本次通信的「对称会话秘钥」

1. 校验消息摘要，通过后服务器也基于这三个随机数生成本次通信的「对称会话秘钥」，再返回去一个响应给客户端

   （1）表示随后的信息都将用「会话秘钥」加密通信。

   （2）之前所有内容的发生的数据做一次哈希，得到消息摘要，给客户端进行校验

        至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。