目录
HTTP 基本工作流程
利用对称密钥进行加密
利用非对称密钥进行加密
引入了第三方权威机构加密
之前在http 协议中说到：我们现在很少有网站直接使用HTTP 协议的，而是使用HTTPS ，至于什么原因，本篇会介绍清楚。
HTTPS 其实就是在http 的基础上做一层加密。这就不得不提到密码学了；提到密码学就得聊到图灵大佬。
图灵 (Alan Turing) - 知乎 (zhihu.com)
具体的故事，不是咱这里的重点，我们直接pass 了。重要的就是图灵大佬为计算机科学做了很大的贡献。
为什么我们有了http 还要做https 协议？
这就不得不提到曾经的故事了（运营商劫持事件）：
我们的搜索引擎是怎么挣钱的？具体的其实我并不了解，但是就拿广告这个来说还是非常挣钱的。
举一个点击计费的广告而言：只需要你点击一下后台就有记录，如果是个医院或者啥大公司这么一下就是几十 ~ 几百之间。
那么就会出现刷单的可能（一般来说大公司都不会这么干，其实没必要），广告商和搜索引擎公司各有一个记录，每隔一段时间进行核对就没啥问题。并且一个广告商不止在一家公司投放广告。
但是在2014 年前后，就发生了运营商劫持事件，就是移动、联通等运营商通过修改点击的网站获取利益。我们之前在http 协议中不是说过：Referer 属性可以表示请求来自哪里，通过修改这个属性广告商的记录就记录到别的网站去了，此时就可以获利。
其实也很好查，只需要后台核对一下，就发现差别太大了。
那么这样去告官司吗？告是肯定要告的，但是这不是一年半载就可以结束的，一个搜索引擎的利润可比广告高得多，既然是运营商劫持，那么不让运营商劫持不就好了吗？
于是就给http 协议加一层密。
我们对于密码学没有过于深入的里了解，这里只讨论宏观的流程，而不讨论加密解密的细节算法。
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 已经被获取了。
我们将此上的过程称之为 " 中间人攻击 " 。
上述的中间人攻击是客户端对这个公钥无限得信任，不管你发了啥，我直接利用它进行加密了。
那么怎么样才可以让客户端对这个公钥进行判断呢？判断其是否可信！
这样我们就引入了第三方权威机构
引入了第三方权威机构加密
我们每个服务器都向第三方权威机构申请一个证书。
这个证书是个啥呢?
这个证书其中包括了：
服务器的 url ；
证书的过期时间；
颁布的机构是啥；
服务器自己的公钥；
........
其中最重要的是 " 加密过后的签名 "。
这个签名就是针对这个证书所有属性进行计算过后的校验和。这个校验和就是签名。
再有证书颁布机构，使用自己的私钥对这个签名进行加密。
我们上面说了，权威机构是用自己的私钥对这个签名进行加密的，私钥加密的可以用公钥解。这个权威机构的公钥在哪呢？
其实是在电脑操作系统中内置了，这些权威机构一共就那么几家，对操作系统而言，并不是什么很大的负担。
这样我们客户端就可以拿到这个证书了。既然是操作系统中内置了的，那么黑客也可以解开这个证书啊。没错，黑客雀氏可以解开，黑客通过修改这个签名，但是没有权威机构的私钥，无法进行加密（就无法发送给客户端，发送过去也没有用），就算黑客真的获取到了这个权威机构的私钥，将修改后签名发送给了客户端，但是，我前面说了这个签名其实就是个校验和，一旦修改过后，这个校验和就不对了，客户端就发现异常了。
客户端拿到这个证书以后，就是通过自己操作系统内置的公钥进行验证，只有当验证通过以后
才可以，利用签名中的服务器的公钥对自己的key进行加密
这个是个重点！！！！！
上述介绍的这一套流程，对称加密 + 非对称加密 + 证书 这一套流程（SSL / TLS 协议），不仅仅是 HTTPS 会涉及到，其他场景也会用到SSL（SSH协议），例如JDBC。
HTTPS = HTTP + SSL
总的来说，其实没有绝对的安全，我们上述整个过程其实就是将黑客的破解成本提高了，黑客要是不计成本来攻击，其实也能攻的下来，但是消耗的时间和其他成本就不得而知了！！！！
ok，讲到这里其实 HTTPS 也就讲完了。
