ToB企服应用市场:ToB评测及商务社交产业平台

标题: HTTPS安全防窃听、防冒充、防篡改三大机制原理 [打印本页]

作者: 风雨同行 时间: 2024-6-20 17:27
标题: HTTPS安全防窃听、防冒充、防篡改三大机制原理
前言

本文内容主要对以下两篇文章内容整理过滤，用最直观的角度了解到HTTPS的保护机制，固然啦，如果想要深入了解HTTPS，本文是远远不敷的，可以针对以下第一个链接中的文章拓展板块进行学习，希望各人通过本文可以大概对HTTPS有一个开端的认识，
你真的了解HTTPS吗？（一） - HTTPS和加密 - 知乎 (zhihu.com)
1.5 万字 + 40 张图解 HTTP 常见面试题 - 知乎 (zhihu.com)
HTTPS

HTTPS公认的三大优势有：

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

HTTPS混淆加密——防窃听

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

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

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

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

办理的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通，这种计划同时兼顾了安全和效率
HTTPS对称加密的密钥SK怎样产生和传输？

HTTPS分为2个过程

协商对称加密密钥SK的非对称加密阶段，称为TLS握手阶段。
使用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 的「握手阶段」涉及四次通讯

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

客户端收到服务器的回应之后，首先通过欣赏器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数
（2）加密通讯算法改变通知，表示随后的信息都将用「会话秘钥」加密通讯。
（3）之前所有内容的发生的数据做一次哈希，得到消息择要
客户端通过这三个随机数用双方协商的加密算法，各自天生本次通讯的「对称会话秘钥」

校验消息择要，通过后服务器也基于这三个随机数天生本次通讯的「对称会话秘钥」，再返回去一个响应给客户端
（1）表示随后的信息都将用「会话秘钥」加密通讯。
（2）之前所有内容的发生的数据做一次哈希，得到消息择要，给客户端进行校验

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)