HTTPS原理和通信流程_随机数是否可以明文传输-CSDN博客

原理转载地址

首先 Session Key 是如何得到的，并且在 Session Key 之前的传输都是明文的。Session Key 通过网络传输肯定不安全，所以它一定各自加密生成的。因此在这之前，双方还要互通，确认加密的算法，并且各自添加随机数，提高安全性。如图：
图片描述

这样双方确认了使用的 SSL/TLS 版本，以及生成 Session Key 的加密算法。并且双方拥有了2个随机数（客户端、服务端各自生成一个）。可是如果按照目前的随机参数，加上加密算法生成 Session Key 呢，还是存在风险，加密算法是有限固定的，而且随机数都是明文传输的，有被截获的可能。

让加密算法变得不可预测，可能性不大。那么能否再传输一个加密的随机数，这个随机数就算被截获，也无法破译。这就用到了非对称加密算法，我们在步骤二中，把公钥传输给客户端。这样客户端的第三个随机数用公钥加密，只有拥有私钥的服务端才能破译第三个参数，这样生成的 Session 就是安全的了。如图：

图片描述

不容易啊，看似完成了。现在生成的 Session Key 是不可预测的（就算被截获也无所谓），我们可以放心的进行私密通信了。真的是这样吗？我们似乎对服务端给的公钥十分信任，如果你目前通信的本身就不可信，或者被中间人劫持，由它发送伪造的公钥给你，那后果可想而知，这就是传说中的“中间人攻击”。

所以，我们得包装一下公钥，让它变得安全。这就引出了数字证书的概念，数字证书由受信任的证书机构颁发，证书包含证书文件与证书私钥文件。私钥文件由服务端自己保存，证书文件发送给请求的客户端，文件包含了域名信息、公钥以及相应的校验码。客户可以根据得到的证书文件，校验证书是否可信。如图：

这下算简单讲完了整个的通信过程，首先在 TCP 三次握手后，进行非对称算法的加密（校验证书），将得到的参数进行加密生成会话所需的 Session Key，在之后的数据传输中，通过 Session Key 进行对称密码传输，会话信息在私密的通道下完成。