HTTP-HTTPS的升级打怪之路(加密之路)

@TOC

故事背景

人物介绍(HTTP,HTTPS)

HTTP:是互联网上应用最为广泛的一种网络协议，是客户端和服务端请求和应答的标准，用于从www服务器传输超文本到本地浏览器的传输协议，可以使浏览器更加高效，使网络传输减少。常用的端口号为80。
HTTPS：是以安全为目标的HTTP通道，是HTTP的安全版，即在HTTP下加入SSL层。常用端口号为443。

HTTPS诞生的契机

HTTP协议的诞生主要是为了解决信息传递和共享的问题。但是随着互联网的高速发展，对于安全的要求越来越高，但是HTTP并不具备任何数据加密，身份验证等机制，使用HTTP协议传输的数据以明文形式在网络中传输，任意节点的第三方都可以随意劫持流量篡改数据或盗窃信息，无法确保数据的保密性，完整性真实性，已经不适合现代互联网应用的安全需求，HTTPS也就应运而生了。

打怪之路

首先我们先来了解一下明文与密文及一些技能(对称加密非对称加密)
明文：真正要传输的信息
密文：加密之后的信息
对称加密：加密和解密使用的是同一个密钥
非对称加密:加密和解密使用的是不同的密钥。通常把公开出去的密钥称为“公钥”，自己保留的密钥称为"私钥"。

第一回合：使用对称加密的方式针对HTTP传输的数据加密

客户端和服务器约定好密钥是什么，然后进行加密。那么密钥要如何传输呢？通过网络传输是万万不能的，在网络上是明文传输，很容易被黑客截获，一旦黑客获取到，后续加密就失去了意义。我们可以通过网银或手机充值卡进行密钥的传输，去银行办理开通网银的同时就会送一个U盾，需要进行加密时将U盾插入到电脑上就可以，但是这种方式的加密很麻烦。因此我们可以对对称的密钥在传输时进行非对称加密。

第二回合：使用非对称加密来对对称加密的密钥进行加密

一个网站，生成一对公钥和私钥，客户端拿着网站的公钥来对自己的对称密钥进行加密，然后传输密文给服务器，服务器拿着私钥进行解密，这样就进行了对对称密钥的传输，后续就可以直接使用对称加密进行传输了。既然都进行了非对称加密，为什么还要进行对称加密呢？
对称加密，成本比较低，机器资源消耗少，速度也很快。
非对称加密，成本高，机器资源消耗多，速度比较慢。
通过非对称加密对对称加密的密钥进行加密确实可以更安全的传输数据，但是问题又来了，客户端如何获取到公钥呢？如何保证客户端获取到的公钥是真实可靠的？任何人都可以任意生成一对公钥和私钥，黑客也一样可以生成。因此黑客想到了一招狸猫换太子的把戏。道高一尺魔高一丈，因此引入证书进行反制。

第三回合：使用证书来反转黑客伪造公钥

客户端和服务器进行连接的时候，客户端不是简单的索要公钥，而是直接索要一个“证书”，公钥就包含在证书里边。
证书是由第三方机构颁发的，客户端拿到证书后，就可以根据证书中提供的信息，去第三方机构进行认证，来检验证书是否合法，证书合法，就可以信任其中的公钥。服务器开发者在搭建服务器的时候要去第三方机构进行认证，申请证书，这个就类似于营业执照。那么黑客是否可以伪造一个证书呢，这个是完全有可能的，但是伪造证书的成本太高风险较大，因此伪造证书的可能性比较小。

经验总结

HTTPS传输过程

1. 客户端先从服务器获取到证书。证书上包含公钥。
2. 客户端对证书进行校验。
3. 客户端生成一个对称密钥，使用公钥对对称密钥进行加密，发给服务器。
4. 服务器收到请求后，使用私钥解密，得到对称密钥。
5. 客户端后续发送的请求都使用对称密钥进行加密。
6. 服务器收到数据后使用对称密钥进行解密。

HTTP到HTTPS的升级打怪之路也就此结束。