看图学HTTPS

时间 2019-11-06

标签看图 https 繁體版

原文原文链接

前言

以前说到HTTPS，在个人概念中就是更安全，须要服务器配置证书，可是到底什么是HTTPS，为何会更安全，整套流程又是如何实现的，在脑子里没有具体的概念。因此，我花了几天的时间，经过参考一些文章，学习了HTTPS整套机制的实现，想要经过一篇文章把我学习到的东西总结出来，让更多以前不清楚HTTPS究竟是什么的同窗有一个入门的理解。html

我看过的不少文章都是经过大量的文字和协议图来解释，但每每会让人感受有点枯燥，这篇文章我会经过一幅幅流程图，形象的说明从HTTP到HTTPS的演变过程，让你们能够更容易理解一些。固然，这个只是入门级，若是想要学习更深刻的HTTPS的知识，仍是要深刻到一个个协议里面，看一些大部头，才能够达到彻底理解的效果。浏览器

本文也会同步到个人我的网站。安全

正文

HTTP是什么样的？

HTTP是属于应用层的协议，它是基于TCP/IP的，因此它只是规定一些要传输的内容，以及头部信息，而后经过TCP协议进行传输，依靠IP协议进行寻址，经过一幅最简单的图来描述：服务器

客户端发出请求，服务端进行响应，就是这么简单。在整个过程当中，没有任何加密的东西，因此它是不安全的，中间人能够进行拦截，获取传输和响应的数据，形成数据泄露。微信

加个密呢？

由于上图中数据是明文传输的，咱们能想到最简单的提升安全性的方法就是在传输前对数据进行加密，以下图：学习

这种加密方式叫作：对称加密。
加密和解密用同一个秘钥的加密方式叫作对称加密。网站

好了，咱们对数据进行加密了，问题解决了吗？加密

多个客户端怎么办？

这是一个客户端，可是在WWW上，是成千上万的客户端，状况会怎样呢？spa

为全部的客户端都应用同一个秘钥A，这种方式很显然是不合理的，破解了一个用户，全部的用户信息都会被盗取。3d

想想，是否是还有别的办法呢？

相信你们均可以想到，若是对每个客户端都用不一样的秘钥进行传输是否是就解决这个问题了：

对称加密秘钥如何传输？

咱们对每一个客户端应用不一样的对称加密秘钥，那么这个秘钥客户端或者服务端是如何知道的呢，只能是在一端生成一个秘钥，而后经过HTTP传输给另外一端：

那么这个传输秘钥的过程，又如何保证加密？若是被中间人拦截，秘钥也会被获取。也许你会说，对秘钥再进行加密，那又如何保证对秘钥加密的过程，是加密的呢？

好像咱们走入了 while(1)，出不来了。

非对称加密

在对称加密的路上走不通了，咱们换个思路，还有一种加密方式叫非对称加密，好比RSA。
非对称加密会有一对秘钥：公钥和私钥。
公钥加密的内容，只有私钥能够解开，私钥加密的内容，全部的公钥均可以解开（固然是指和秘钥是一对的公钥）。

私钥只保存在服务器端，公钥能够发送给全部的客户端。

在传输公钥的过程当中，确定也会有被中间人获取的风险，但在目前的状况下，至少能够保证客户端经过公钥加密的内容，中间人是没法破解的，由于私钥只保存在服务器端，只有私钥能够破解公钥加密的内容。

如今咱们还存在一个问题，若是公钥被中间人拿到篡改呢：

MITM：Man-in-the-MiddleAttack

客户端拿到的公钥是假的，如何解决这个问题？

第三方认证

公钥被掉包，是由于客户端没法分辨传回公钥的究竟是中间人，仍是服务器，这也是密码学中的身份验证问题。

在HTTPS中，使用 证书 + 数字签名 来解决这个问题。

这里假设加密方式是MD5，将网站的信息加密后经过第三方机构的私钥再次进行加密，生成数字签名。

数字证书 = 网站信息 + 数字签名

假如中间人拦截后把服务器的公钥替换为本身的公钥，由于数字签名的存在，会致使客户端验证签名不匹配，这样就防止了中间人替换公钥的问题。

浏览器安装后会内置一些权威第三方认证机构的公钥，好比VeriSign、Symantec以及GlobalSign等等，验证签名的时候直接就从本地拿到相应第三方机构的公钥，对私钥加密后的数字签名进行解密获得真正的签名，而后客户端利用签名生成规则进行签名生成，看两个签名是否匹配，若是匹配认证经过，不匹配则获取证书失败。