目录

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 也就讲完了。