https详解

http存在的隐患

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

image.png

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

对称加密

对于这种情况，我们想到的最直接的办法就是对数据加密

数据加密.png

这种加密方式叫做：对称加密。加密和解密用同一个秘钥的加密方式叫做对称加密。但是对称加密却解决不了任何问题，比如
多个客户端怎么办？

多个客户端.png

为所有的客户端都应用同一个秘钥A，这种方式很显然是不合理的，破解了一个用户，所有的用户信息都会被盗取。
但是如果每个客户端都准备一个密钥也不是很现实，服务端需要维护的太多。

另外对称加密还存在一个问题就是对称加密的秘钥也需要传输，如果在传输秘钥的过程中被拦截，秘钥也会被获取，也是非常不安全的

非对称加密

在对称加密的路上走不通了，我们换个思路，还有一种加密方式叫非对称加密，比如RSA。非对称加密会有一对秘钥：公钥和私钥。公钥加密的内容，只有私钥可以解开，私钥加密的内容，所有的公钥都可以解开（当然是指和秘钥是一对的公钥）。

非对称加密.png

私钥只保存在服务器端，公钥可以发送给所有的客户端。

在传输公钥的过程中，肯定也会有被中间人获取的风险，但在目前的情况下，至少可以保证客户端通过公钥加密的内容，中间人是无法破解的，因为私钥只保存在服务器端，只有私钥可以破解公钥加密的内容。

现在我们还存在一个问题，如果公钥被中间人拿到篡改呢：

MITM：Man-in-the-MiddleAttack

image.png

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

第三方认证

公钥被掉包，是因为客户端无法分辨传回公钥的到底是中间人，还是服务器，这也是密码学中的身份验证问题。
在HTTPS中，使用证书 + 数字签名来解决这个问题。

image.png

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

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

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

image.png

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