深入理解HTTPS协议-优快云博客

本文介绍了对称加密与非对称加密的区别，强调了HTTPS中使用的加密原理，包括数据内容加密、身份校验和数据完整性，以及如何通过公钥/私钥和数字证书防止中间人攻击。

对称加密和非对称加密

这也是理解https的重要基础之一。这里涉及到很多复杂的算法，我并不精通算法和密码学，所以这里不讲的太细。你们只要知道个大概即可：

对称加密：加密和解密都用一个密钥，有点是速度快。缺点吗，显而易见的是双方要用这个通信的话必须得把密钥告知对方，但是这个密钥一旦被截获了，就可以随便decode出来明文。实际上不够安全。

非对称加密：有一对密钥，即有公钥也有私钥。公钥随便发，私钥不会发出去各自保管。用一个加密的话，解密就只能用另外一个。比如你向银行请求一个公钥，银行把公钥发给你，你用公钥加密一条信息以后再发给银行，然后银行用私钥解密信息。这个过程就算有人拿到公钥，但是因为非对称加密用一个加密只能用另外一个解密，所以拿到这公钥也没用，因为无法使用公钥解密，能解密的私钥还在银行那里，银行当然不会传出去，所以非对称加密很安全。但是这种非对称加密非常消耗资源，速度极慢，所以要有限使用。不能无节制使用。

HASH加密算法：这个就好像MD5这样的加密方式，是不可逆的。

确保安全通信的三个原则

A.数据内容的加密

这个很好理解是吧，敏感信息肯定要加密的，明文传输等于自杀。不过多解释了。

B.通讯双方的身份校验

这个很多人不理解，这是啥意思，按道理说我们用非对称加密应该就完美了啊。但是谨记我们的数据包不是从A直接到B的。中间要经过无数次的路由器转发等等，这个中间一旦有人截获了我们的数据包，换成自己的数据包，就很危险了。所以我们还需要一种机制能校验通讯双方的身份。确保我是在和我老婆说话而不是在我和丈母娘说话。

C.数据内容的完整性

这个也不是很容易理解，按道理说TCP是能保证数据有序完整的到达对方的。但是不要忘记中间我们经过的无数次路由器转发，可能被劫持，被劫持以后可能会对数据包进行篡改，这个时候我们需要一种机制保护我们的数据不被篡改，即使被篡改也能被我们察觉，确保我对我老婆写的信能完整的让我老婆看到，而不是只看到一半。

https的设计思路

根据前面我们阐述的加密算法和安全通信三原则，为了保证我们的通信能够安全进行，可以试想出一种流程来保证通信安全：

服务器为每个客户端生成一个公钥，将公钥发送给客户端
客户端选择一个加密算法，然后用公钥加密以后发送给服务器
服务器收到这个公钥加密后的算法以后拿自己的私钥解密，然后就知道这个加密算法是哪个了。今后就一直用这个算法通信。

目前来看，这个思路是不是很完美。公钥即使被中间人截获以后也没用，因为拿到公钥也解密不出来到底双方是用哪种算法加密的。但有个重大缺陷：

中间人可以将服务器发送的公钥包进行掉包，客户端怎么知道这个公钥是真的服务器发送的还是假的中间人给的非法公钥呢？

可以看这张图，基本上中间人攻击就是这个图所示的意思。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

解决中间人攻击问题

这个问题的解决办法其实也很粗暴：

使用权威的第三方机构也就是CA向安全的服务器颁发证书。来证明这台服务器的合法性。
服务器通过这个证书来把自己的公钥加密以后发给客户端
客户端收到这个加密后的公钥以后，就用第三方机构的公钥把这个服务器返回的加密后的公钥解密从而得到真正的服务器的公钥

带来的问题：

客户端到哪去取第三方公钥?

你的操作系统或者浏览器自身就带有权威机构的第三方公钥
如果中间人得到CA认证怎么办？这种情况基本没办法处理，如果发生，那么这个CA下面所有的证书都被认为非法了。所以 CA审核也很严格啊

CA证书是收费的啊，我不想交钱咋办呢

可以自己制作证书，然后把这个证书的公钥放在客户端（例如app的安装目录下），这样app只要使用自己的证书公钥即可解密了，不需要使用系统的。但是这样带来的问题是，如果有人获取到了你这个公钥证书咋办？数字签名认证算法即可保证此类问题，其实简单来说就是服务器和客户端事先约定好一种加密规则即可，就可以得知是否被篡改。这部分由于不是重点，暂时不讲的太细，只要知道有这么个事即可。实际上你弄懂整个https以后这个地方就自然而然也能想明白了。

有了上述基础，我们终于可以按照科班的方式来理解HTTPS真正的流程

为什么HTTPS的流程要放在最后再讲，因为放在前面讲，根本不会理解为啥要这么做，很快就会忘记。有了前面的基础再来看这个流程，就会恍然大悟。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

先看蓝色的部分，可以看出来，这是tcp链接。所以https的加密层也是在tcp之上的。
客户端首先发起clientHello消息。包含一个客户端随机生成的random1 数字，客户端支持的加密算法，以及SSL信息。
服务器收到客户端的clientHello消息以后，取出客户端法发来的random1数字，并且取出客户端发来的支持的加密算法，然后选出一个加密算法，并生成一个随机数random2，发送给客户端serverhello
让客户端对服务器进行身份校验,服务端通过将自己的公钥通过数字证书的方式发送给客户端
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。并将PreMaster Key发送到服务端,服务端通过私钥将PreMaster Key解密获取到Random3,此时客户端和服务器都持有三个随机数Random1 Random2 Random3,双方在通过这三个随即书生成一个对称加密的密钥.双方根据这三个随即数经过相同的算法生成一个密钥,而以后应用层传输的数据都使用这套密钥进行加密.
Change Cipher Spec:告诉客户端以后的通讯都使用这一套密钥来进行.

最后ApplicationData 全部使用对称加密的原因就是非对称加密太卡，对称加密不影响性能。所以实际上也看的出来 HTTPS的真正目的就是保证对称加密的密钥不被破解，不被替换，不被中间人攻击，如果发生了上述情况，那么HTTPS的加密层也能获知，避免发生事故。