Https通信原理解析

超、凢脫俗 2022-10-23 05:58 168阅读 0赞

### Https简单介绍 ###

众所周知，https就是http的升级版协议，他比http更加安全，但它是如何实现安全机制的呢？其实剖开去看无非就是https在传输过程中把数据加密了，http在传输过程中不进行加密，直接就是以明文转为二进制流的形式在网络上进行传播，但是https则是传输之前将数据进行一次加密，在读取数据的时候进行解密。

### 加密方式介绍 ###

那么上边我们提到了加密解密，我们就要考虑的是如何进行加解密？如果区分常见的加密方式就是对称加密和非对称加密。

> 对称加密：加密和解密的双方使用的密钥都是同一串，常见的对称加密算法：DES，AES等。
> 
> 非对称加密：密钥分为了公钥和私钥，私钥加密公钥解密，公钥加密私钥解密，常用的非对称加密算法：RSA。加解密比较耗时。

### 使用对称加密进行通信加密 ###

![	\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-whovajsx-1615717317729)(C:\\Users\\zhangzhongguo\\AppData\\Roaming\\Typora\\typora-user-images\\image-20210313202032382.png)\]][img-whovajsx-1615717317729_C_Users_zhangzhongguo_AppData_Roaming_Typora_typora-user-images_image-20210313202032382.png]

**步骤：**

1.密钥只有一个，并且客户端和服务器同时持有。

2.客户端使用密钥进行数据加密，然后通过网络传输到达服务端。

3.服务端接收到消息，使用密钥进行解密，服务器识别到发送的消息并且将需要返回的数据使用密钥进行加密，通过网络返回给客户端。

4.客户端收到消息，进行解密。

**优点：**

加解密比较简单，快速。

**缺点：**

我们的密钥下发是非常困难的，首先密钥不能由服务器生成给客户端或者由客户端生成发送给服务器，因为一旦在网络传输的时候被人劫持，就会出现密钥泄露。那么密钥只能预先放置在两边，但是浏览器可能要访问很多个服务器，那么对应的要有很多个密钥，如果是这样客户端可能要有成千上万个密钥，这种密钥管理显然不现实。

### 使用非对称方式进行通信加密 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center]

**步骤：**

1.先由客户端发起请求。

2.服务器端给客户端下发公钥。

3.客户端使用公钥对数据进行加密，服务器端收到数据使用私钥对数据进行解密。

4.服务器端将需要返回的数据使用私钥进行加密，然后客户端收到数据使用公钥进行解密。

**优点：**

密钥由服务器下发，如果被人劫持公钥，他无法解密客户端发送给服务器的消息。确保了客户端发给服务端消息的安全性。同时避免了需要在客户端放置大量密钥的问题。

**缺点：**

1.无法确保服务端到客户端的信息安全问题，因为一旦密钥被截获那么服务器发向客户端的数据都会被解密。

2.如果全程使用公钥和私钥进行加解密操作会非常费时，因为非对称加密要比对称加密费时。

### 对称加密和非对称加密结合 ###

我们基于上边的推断，既然对称加密比较快，非对称加密比较慢，但非对称加密比对称加密要稍微安全一些，那么我们何不想一种方式让两者结合呢。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 1]

**步骤：**

1.客户端向服务器发起请求

2.服务器下发给客户端公钥。

3.客户端生成一个密钥，并且使用公钥进行加密，然后传输给服务器端。

4.服务器端使用私钥数据进行解密获得对称密钥。

5.客户端使用密钥对数据进行加密，然后发送给服务器。

6.服务器端对返回数据使用密钥进行加密返回给客户端。

**优点：**

由于只是在一开始阶段使用公钥进行对称密钥的交换，后期所有的数据交互都使用对称加密的方式，所以耗时会比全部使用非对称加密要短。

**缺点：**

他还是只能够保证客户端发去服务端的数据的安全，如果说中间有人拦截了公钥，并且将自己的公钥发送给浏览器，这样从服务器发送的消息中间人可以解开，同时它也可以用自己的私钥去解开浏览器传过来的消息，以此它可以随意的改动消息，并且浏览器和服务器都感知不到这个中间人的存在，这也就是中间人攻击。

### 数字证书和数字签名 ###

我们想中间人攻击这种情况发生的主要原因是什么？主要的原因就是服务器无法辨别是谁发过来的数据，同时浏览器也无法辨别服务器的身份，导致被中间人给冒充，所以我们需要有一种方式来标志双方的东西，让浏览器和服务器能够辨别出是谁发送的消息，从生活中推演，此时就需要有个像身份证一样的东西来标志双方的可靠性，同时需要有个像政府机构这样的组织来颁发这样的证件，于是就有了证书和CA机构，证书就相当于客户端和浏览器的身份证，CA机构就相当于现实世界中的政府机构。也就是网站需要支持https，它就必须向CA机构申请一个数字证书，这个证书中包含，网站的域名，证书的使用者、颁发者、有效时间以及网站需要下发的公钥以及数字签名，如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 2]

如果我们不考虑数字签名，那么明文证书可能会被篡改，所以必须带有数字签名的证书才能够较为安全，那么什么是数字签名呢？其实数字签名就是明文的证书经过hash函数形成信息摘要然后使用CA机构的私钥加密，从而形成了签名。如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 3]

我们的最终的数字证书是什么样子呢？它就是数字签名加上明文的证书。如图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 4]

我们拿到CA机构颁发的数字证书以后，我们就可以把这个证书往客户端传输，客户端收到证书以后会使用CA机构公钥对数字签名进行解密，然后得到证书明文部分的hash值，同时去对证书中的明文部分进行hash然后得到对应的hash值之后对两个hash值进行比对，如果hash值一致那么证明服务器传过来的数据并未被篡改。同时我们提到了CA的公钥，CA的公钥是内置在操作系统中的，他也是以证书的形式存在的，就像上边的证书截图就是CA机构内置在系统中的证书，他其中就包含了CA机构的公钥。

### 最终形态的https网络通信过程 ###

通过上边的推演我们不难得出https最终的通信形式。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 5]

**步骤：**

1.客户端发起请求。

2.服务端收到请求，返回给客户端CA机构颁发的证书。

3.客户端使用CA的公钥对证书进行校验，解析出服务端的公钥。

4.使用服务端的公钥对生成的对称密钥进行加密。

5.服务端使用私钥解析出对称密钥。

6.客户端和服务端使用对称密钥进行加解密通信。

得到这个通信策略以后我们考虑一个问题，在步骤2整个证书会不会被中间人拦截并且掉包呢？如果说某个网站也申请了CA机构的认证，然后再步骤2截获原来网站的证书以后，替换成自己网站的证书，这样客户端也能正常解析证书。其实这种情况不会发生，因为证书中有你所需要访问网站的域名，客户端会对要请求网站的域名和证书中的域名进行域名的比对，如果域名不对那么也会有问题。

[img-whovajsx-1615717317729_C_Users_zhangzhongguo_AppData_Roaming_Typora_typora-user-images_image-20210313202032382.png]: /images/20221023/c7edc8abe10e4603ad40ae57c4adcc5a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221023/dc3f2f1eead34bc8a4f056f0dae63b2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221023/48d37a37896649db8098087fb8016b1e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221023/3b05e400363a4067a9894358b6711aab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221023/c5af191d96364ef1b77ece1f09dc4d38.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221023/d5da47b9ef744ae588ba34d38418d5cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIyNTYxMw_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221023/786a8e7abf494a7387e1a9db07469071.png