目录
之前在http 协议中说到：我们现在很少有网站直接使用HTTP 协议的，而是使用HTTPS ，至于什么原因，本篇会介绍清楚。
HTTPS 其实就是在http 的基础上做一层加密。这就不得不提到密码学了；提到密码学就得聊到图灵大佬。
图灵 (Alan Turing) - 知乎 (zhihu.com)
具体的故事，不是咱这里的重点，我们直接pass 了。重要的就是图灵大佬为计算机科学做了很大的贡献。
为什么我们有了http 还要做https 协议？
这就不得不提到曾经的故事了（运营商劫持事件）：
我们对于密码学没有过于深入的里了解，这里只讨论宏观的流程，而不讨论加密解密的细节算法。
HTTP 基本工作流程
利用对称密钥进行加密
所谓加密其实就是对 http 协议中的header 和 body 进行加密。
对称加密：利用一个对称密钥：key 来进行加密解密。
密文 + key = 明文
明文 + key = 密文。
如上图，但是问题来了，服务器怎么拿到这个key 呢？
客户端自己生成一个key ，通过网络传输，传输给客户端。
我们假设在传输过程中猫了个黑客：
可是key 需要通过网络传输才能传给服务器，黑客只要在中间结点截获就可以拿到这个key。
这样显然是不安全的，难道要再给key 进行加密？？
这样就陷入死循环了。
这里顺便提一嘴，每个客户端都是不同的key 。如果都是同一个key 那完了，更加不安全了，黑客破解一个key ，一组数据全毁了。
针对这个问题，我们可以引入非对称加密
利用非对称密钥进行加密
客户端是希望安全的将密钥 key 传输给服务器，不被黑客拿到。
而我们这里引入非对称密钥：公钥 pub （public）和 私钥 pri （private）
被pri 加密过的密文 + 公钥 = 明文
被pib 加密过的密文 + 私钥 = 明文
我可以借助这一对非对称密钥将我们的 key 传过去。这样黑客就拿不到 key ，再之后就针对明文 用key 加密，此时就安全传输了/
我们来看看这样的流程:
因为我们的公钥必须要用私钥才可以解密，而这个私钥是在服务器手上，黑客是拿不到这个私钥的，所以目前为止客户端的key 是安全的。
这个过程黑客啥也拿不到。
但是黑客一定要按照这个过程来吗？
他也是可以在这个过程有动作的啊。
我们再来走一次：
此时，当这个被 pub1 加密过的key 传输给黑客之后，黑客就可以用 pri1 拿到这个key， 在对这个key 用服务器的公钥加密，传给服务器。
这整个过程服务器并不知道客户端的 key 已经被黑客拿到了。
这样黑客就偷取到了想要的明文了。并且客户端和服务器并不知道这个key 已经被获取了。
我们将此上的过程称之为 " 中间人攻击 " 。
上述的中间人攻击是客户端对这个公钥无限得信任，不管你发了啥，我直接利用它进行加密了。
那么怎么样才可以让客户端对这个公钥进行判断呢？判断其是否可信！
这样我们就引入了第三方权威机构
引入了第三方权威机构加密
我们每个服务器都向第三方权威机构申请一个证书。
这个证书是个啥呢?
这个证书其中包括了：
再有证书颁布机构，使用自己的私钥对这个签名进行加密。
我们上面说了，权威机构是用自己的私钥对这个签名进行加密的，私钥加密的可以用公钥解。这个权威机构的公钥在哪呢？
其实是在电脑操作系统中内置了，这些权威机构一共就那么几家，对操作系统而言，并不是什么很大的负担。
客户端拿到这个证书以后，就是通过自己操作系统内置的公钥进行验证，只有当验证通过以后
才可以，利用签名中的服务器的公钥对自己的key进行加密
这个是个重点！！！！！
上述介绍的这一套流程，对称加密 + 非对称加密 + 证书 这一套流程（SSL / TLS 协议），不仅仅是 HTTPS 会涉及到，其他场景也会用到SSL（SSH协议），例如JDBC。
HTTPS = HTTP + SSL
总的来说，其实没有绝对的安全，我们上述整个过程其实就是将黑客的破解成本提高了，黑客要是不计成本来攻击，其实也能攻的下来，但是消耗的时间和其他成本就不得而知了！！！！
ok，讲到这里其实 HTTPS 也就讲完了。
