HTTPS加密

https://www.wosign.com/News/httpsjiami_20180817.htm

前言

本周进行了网络爬虫的学习，最终代码实现后，但是仍然不能爬取网络上的数据。因为通过gethostbyname()函数返回的IP地址与实际的IP地址不同。是因为HTTP与HTTPS的区别。

HTTP是什么样的？

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

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

加个密

因为上图数据是明文传输的，我们能想到最简单的提高安全性的方法就是在传输前对数据加密：

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

多个客户端

在成千上万个客户端的情况下，上述方案明显不能符合要求。

为所有的客户端应用同一个秘钥A，这种方式明显是不合理的，若破解一个用户，则所有用户的信息都会被盗用。

对称加密秘钥如何传输的？

我们对每个客户端应该不同的对称加密密钥，那么这个密钥客户端或者服务端如何知道的？只能是在一端生成一个秘钥，然后通过HTTP传输给另一端：

那么这个传输秘钥的过程，又如何保证加密的？如果被中间人拦截，秘钥也会被获取。

非对称加密

还有一种加密方式叫非对称加密，比如RSA。
非对称加密会有一对秘钥：公钥和私钥
公钥加密的内容，只有私钥可以解开，私钥加密的内容，所有的公钥都可以解开。

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

第三方认证

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

这里假设加密方式是MD5，将网站的信息加密后通过第三方机构的私钥再次进行加密，生成数字签名。
数字证书 = 网站信息 +数字签名
假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题。

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

为什么要签名？

第三方认证机构是一个开放的平台，我们可以去申请，中间人也可以申请。

如果没有没有签名，只对网站信息进行第三方机构私钥加密的话，会存在下面的问题：

因为没有认证，所以中间人也向第三方认证机构进行申请，然后拦截后把所有的信息都替换成自己的，客户端仍然可以解密，并且无法判断这是服务器的还是中间人的，最后造成数据泄漏。

对称加密

在安全的拿到服务器的公钥只要，客户端会随机生成一对秘钥，使用服务器公钥加密的，传输给服务端，相关的Application Data 就通过这个随机生成的对称秘钥进行进行加密/解密，服务器也通过对称秘钥进行解密/加密：

整体流程图

HTTPS=HTTP+TLS/SSL

总结

HTTPS就是使用SSL/TLS协议进行加密传输，让客户端拿到服务器的公钥，然后客户端随机生成一个对称加密的秘钥，使用公钥加密传输给服务器，后续的所有信息都通过该对称秘钥进行加密解密，完成整个HTTPS的流程。则网络爬虫后续需要添加https的模块。