Linux网络原理及编程(3)——第十三节 HTTPS

我们本文主要来介绍https，主要来介绍https的加密原理。

大家应该都知道http和https的区别，区别很简单，主要就是在https是采用了加密协议的，而http完全是在网络上裸奔的。而我们现在几乎所有的连接都用的是https

我们首先需要明白的是，我们现阶段的加密，本质上，是在应用层和传输层之间进行加密的。加密的算法有很多，比如SSL/TLS等。

为了防止报文在传输的过程中被别人劫走而造成信息泄露，我们想出了一系列加密、认证的方式。

我们循序渐进，一级一级来讲解。

对称加密和非对称加密

对称加密：加密和解密用的是同一个密码或者同一套逻辑的加密方式。常见的对称加密算法有DES，AES，3DES等等。.

非对称加密就不是同一个。所以实际上是否对称即加密和解密的密钥是不是同一个。常见的非对称加密算法：RSA，ECC

我们一般称加密或者解密的为密钥。

在对称加密中，加密和解密用的是同一个密钥；

而在非对称加密中，加密和解密用的不是同一个密钥。有公钥（public key）和私钥（private key）之分。一般一个用于加密，另一个 用于解密。

一代目 

一般情况下，由于非对称加密比较复杂，所以自然效率就没有对称加密高。也就是说，我们在https报文传输的时候，采用的都是对称加密。

这样即存在这样一种情形了：

 如果服务器和客户端都有这样一个密钥，那么对于一个报文(不论其是Request还是Response)，我在一端用密钥将此报文加密，在另一端将此密钥解密。

这样的话，我是不是就达到了数据加密的目的了呢？因为这样的话，即便别人拿到了我的报文，也做不了什么事情。因为它是加密的。别人没有我的密钥，就无法解密，得到的只能是加密后的数据。而我的密钥是不会发送到网络上传输的，所以密钥是安全的，一般别人也是得不到的。

这样有没有道理？很有道理。

那这样就行了吗？当然不是。

有没有想过一个问题：这样密钥是从哪里来的？最一开始传输的时候，比如从Cilent发送有一个Request给Server，那服务器怎么知道你的密钥是什么？你的密钥是由哈希算法随机生成的，而且你的密钥在传输的时候是不会放在网络上的（要不然别人拿到了你的密钥，不就相当于没有加密了么）。

那现在就有一个问题了。在第一次传输的时候，对方怎么知道你的密钥是什么？

这就需要结合着非对称加密来进行了。

二代目

于是，就衍生出了非对称加密的方式：公钥和私钥。

通常情况，公钥是用来进行加密的，私钥是用来解密的。

第一次，我们进行非对称加密：

加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。

这样的话，我们先将我们刚刚的C/S模型加密通信的模型再来模拟一下：

1. 服务端计算出一对秘钥public/private。将私钥保密，将公钥公开。(注意这里的公钥是公开的)

2. 客户端请求服务端时，拿到服务端的公钥public。

3. 客户端通过AES或者其他加密算法计算出一个对称加密的秘钥XY（注意，这里的密钥一般来说是随机生成的字符串）。 然后使用公钥将XY进行加密。

---这里即使被黑客劫持也没有用，因为黑客拿不到私钥，无法加密。所以只能拿到被加密后的密钥，拿不到密钥

4. 客户端将加密后的密文发送给服务端。服务端通过私钥解密获得XY。

5. 这个时候，客户端有了这个XY，服务端也有了这个XY，然后两边的通讯内容就通过对称密钥X以对称加密算法来加解密。

图示一下：

 

三代目

现在就万事大吉了吗？解决一切问题了？

nonono

思考这样一种情况：

 

当服务器给客户端发送公钥的时候，被我（黑客）劫持。

然后我将我自己的公钥发送给客户端，这个时候，客户端就会拿着我的这个公钥

来对自己的对称密钥x进行加密。在回来的过程中，再被我劫持。

这个时候，由于客户端是用我的公钥来进行加密的，而我自然也有自己的一份对应公钥的私钥来进行解密。这样，客户端的对称密钥x就被我拿到了，那么他所有发送的数据我也就都拿到了。然后又由于我自己也相当于一台服务器，所以我可以继续给服务器发回用服务器公钥加密密钥x的密钥。这样，我便神不知鬼不觉地获得了客户端发送的信息。

注意到，这里同时还存在一个问题：我作为中间者，我有可能将中间的信息篡改。举个例子：client->server 小花我爱你 ，server->client 小明我也很爱你

我很不爽，从中间截获之后，将server->client改为小明我不爱你，滚吧

那这岂不是凉凉了？

那该怎么办呢？这样的问题有解决的方式吗？

实际上，我们主要解决两个问题就可以了。一个是远端服务器的身份认证问题；还有一个中间信息被篡改的问题。

如何解决身份认证问题？

我们引入CA证书这么一个概念

证书里面包含的内容（至少）：

1. 网站域名
2. 证书持有者
3. 证书有效期
4. 证书颁发机构
5. 服务器公钥（最主要）
6. 接下来要说的签名时用的hash算法

简而言之，证书的作用就是为了证明这个公钥是你想要连的服务器的，不是我黑客的。

所以，这个证书可以理解为就是公钥+一串东西

那证书如何安全的送达给浏览器，如何防止被篡改呢？给证书盖个章（防伪标记）不就好了，这就又引出另外一个概念：数字签名

签名的过程其实也很简单：

1. CA机构拥有非对称加密的公钥
2. CA对证书明文信息进行hash
3. 对hash后的值用CA私钥加密，得到数字签名

所以呢，另一种方式总结一下：CA机构颁发的证书包含证书内容的明文(公钥等)+签名

我们通过这样一个东西，实际上能把上面两个问题一块给解决了。（具体解决的过程讲解如下：）

大家知道，私钥签名，公钥验签。证书里面的签名是CA机构用私钥签名的，所以我只要用CA机构的公钥验证一下签名不就好了，怎么验证呢？

1. 拿到证书里面明文的hash算法并对明文内容进行hash运算，得到A
2. 用CA的公钥解密签名得到B
3. 比较A 和 B，如果相等，说明没有被篡改，否则浏览器提示证书不可信

那么总结一下，整个过程：

1、服务器给客户端发数据的时候先发一个证书。

2、客户端拿到证书里的明文和哈希算法，然后用该哈希算法对明文进行哈希，得到数据a。

3、用自己浏览器中内置的CA公钥对签名进行解密，得到数据b。

4、如果a == b，则证明证书合法有效，公钥是合法未被篡改过的。

5、客户端将自己的密钥c用服务器的公钥加密，发送给服务器。

6、服务器用自己的私钥对其进行解密，拿到密钥c。

7、双方通过密钥c进行对称加密传输。

注意点出来的是，CA私钥自始至终都没有在网络中传输，它是用来加密CA证书的（即得到CA签名），而CA公钥本身就包含在证书中，其是公开的，所以不用担心泄露的问题。如果CA证书被黑客劫持，是没有用的，因为它拿到了证书，实际上也只是拿到了这样一个签名，对于黑客来说，也是只能验证对方的身份，没有用。而证书本身黑客是伪造不了的（因为证书是由正规的政府机构颁发授予的）。

所以这样子的话，就相对来说，整个传输过程就是比较安全的了。

更多的内容，也可以参考参考这两篇内容，写的也挺不错（拓展视野了）：

CA证书扫盲，https讲解。 - handsomeBoys - 博客园 (cnblogs.com)

HTTPS 建立连接的详细过程 - cccc_hi - 博客园 (cnblogs.com)

原创不易，如果觉得写的不错，就点个赞呗~~~笔芯~~~~