您的位置: 首页  >  文章  >  带你彻头彻尾的学习HTTPS原理。图解加文字描述精解版

带你彻头彻尾的学习HTTPS原理。图解加文字描述精解版

分类: 文章 • 2023-11-10 19:01:46

不了解对称加密、非对称加密、网络传输的不可靠性等知识点的读者请自先了解一下啊

目录

流程图详解：

带你彻头彻尾的学习HTTPS原理。图解加文字描述精解版

文字描述详解SSL建立过程

  1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及**长度等）。
    注意：客户端还会附加一个随机数，这里记为A。

  2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
    注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。

  3. 服务器发送Certificate报文，报文中包含公开**证书，即CA机构颁发给服务端的证书

  4. 服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

  5. SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，如果验证成功，解密取出证书中的公钥。
    解密方式为：浏览器通过内置CA证书，根据C.pub进行解密，解密出来Hash和hash算法（参见上图中第四步，Hash和hash算法为server端传给CA的），重新对接收到服务端的证书内容进行hash，看看两个hash是否一致，一致则可获取证书

  6. 接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。

  7. 客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，告知服务器准备使用之前协商好的加密套件加密数据并传输了。

  8. 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。

此时Server和Client均存储了下面三个随机数：随机数A、随机数B、Per-master secret

  1. 服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文。告知客户端准备使用之前协商好的加密套件加密数据并传输了。

  2. 服务器同样发送Finished报文，用来供客户端校验。

  3. 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。之后的请求通过加密套件进行对称加密，加密套件为【随机数A、随机数B、Per-master secret】

  4. 应用层协议通信，即发送HTTP响应。

  5. 最后由客户端断开连接。断开连接时，发送close_notify报文。

重点内容记录

  • 如果黑客拦截了服务器把证书发送给客户端，并对证书进行恶意修改，会出现什么情况？
    • 第一种情况，假如黑客只是单纯的修改数字证书中的内容，那么由于数字签名的存在，客户端会很容易的判断出报文是否被篡改。
    • 第二种情况，黑客不仅修改了数字证书的内容，并且把数字签名替换掉了，由于黑客不可能知道CA的私钥，于是在客户端用CA的公钥进行解密的时候，解密之后得不到正确的信息，也很容易判断出报文是否被修改。
    • 第三种情况，黑客恶意的从相同的第三方CA申请了一个数字证书。由于这个CA是真实存在的，所以客户端是可以用CA的公钥进行解密，得到了黑客提供的数字证书中的公钥。但是，由于数字证书在申请的时候，会绑定一个域名，当客户端比如说浏览器，检测到这个数字证书中的域名和我们现在网页访问的域名不一致，便会发出警告，此时我们也能得知数字证书被替换了。
  • 针对HTTPS的思考：
    • 在进行安全通信时，可以将协商过程中的所有通信报文进行签名Hash算法，用来提供给Client/Server端进行比对判断，从而保证整个传输过程中数据不被篡改
    • 安全通信的协商过程一定会传输域名
    • 因为互联网传输的不可控性，在重要的关键节点，要发送Done报文，同时也可以多次进行失败重试
  • 为什么是三个随机数呢？【随机数A、随机数B、Per-master secret】
    • 不管是客户端还是服务器，都需要随机数，这样生成的**才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的**的随机性。对于RSA**交换算法来说，pre-master secret本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个**导出器最终导出一个对称**。pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-master secret就有可能被猜出来，那么仅适用pre-master secret作为**就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre-master secret三个随机数一同生成的**就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个*度，随机性增加的可不是一。

文章参考自：https://segmentfault.com/a/1190000012196642

▄█▀█●各位同仁，如果我的代码对你有帮助，请给我一个赞吧，为了下次方便找到，也可关注加收藏呀
如果有什么意见或建议，也可留言区讨论

相关推荐