https浅析

https浅析

 http协议本身有着很大的缺陷

 1. 通信使用明文，若被抓包，则直接被窃取信息




 2. 不验证与自身通信者的身份，有可能遭到伪装

 - 在数据传输的过程中，经过了某一计算机，该计算机直接响应你的请求，然后你无法判断这个请求是否为目标服务器返回的请求




 3. 无法证明报文是否被篡改


 - 在数据的请求响应过程中，经过某一计算机，该计算机将报文内容进行修改，而后让报文继续正常传输，然而我们无法判断报文在传输的过程中是否被篡改

 http的tcp连接的建立过程与https的tcp连接建立过程是不同的。后者还多了ssl连接，在这个过程中进行证书验证与加密模式的协商与传递。

 在讲https通信之前，我们先捋清楚对称加密与非对称加密，因为这两者是https通信加密的基理。

## 对称加密

 对称加密会在建立tcp连接之后，共享秘钥，往后双方使用该秘钥加密报文，使得http报√文不再是明文。

 不过这存在一个问题，虽然报文被抓包时无法直接看到明文了，但如果同时抓包了秘钥，就可以被解密出来，那和明文就没有什么差别了。

## 非对称加密

 在对称加密中，双方通过一个秘钥加密和解密。那么如果我们把加密和解密分别用两个不同的秘钥来操作呢？

 这两个秘钥就是公钥及私钥。我们使用公钥加密报文，用私钥解密报文，是一对的。要想双向通信，则不管是服务器还是浏览器都需要创建出自己的一对秘钥（注意，客户端也能创建公钥私钥）。

 现在，我们以浏览器发送信息，服务器接受信息为例。即浏览器加密报文，服务器解密报文，也就是说，使用的是服务器的公钥与私钥。

 在建立tcp连接之后，服务器将公钥发送给客户端，往后客户端每次发送数据之前都是用该公钥加密，当服务器接受到加密后的报文后，使用与客户端加密数据的公钥相对应的私钥来进行解密。通信成功。

 他的安全之处在于：

 在报文的传输过程中，报文不是明文的。再进一步讲，就算报文被抓包了，且公钥也被抓包了，但因为能解密该公钥加密的报文的私钥只在对应的服务器里有，这个私钥是不会在网络中传输的，也就无法被抓包，那么劫持者也就无法解密该报文。也就无法获取到有效信息。

 大家可能会想：既然已经这么安全了，那么https协议就通过非对称加密来进行通信不就好了？

 之所以不这样做的原因是代价太大了，因为需要每次通信都用公钥进行一次加密，发送到对方，对方得先找到该公钥对应的私钥，然后再用该私钥解密。每次解密都是cpu计算的，若有大量的通信请求，则对于cpu负载太大了。

 我们再来说说CA证书，这也是https的关键。

## CA证书

 CA证书是数字证书，是由CA机构颁发的，所有人都信任该机构，在服务器与客户端建立SSL连接时由服务端返回（当然，客户端也可以申请CA证书，在需要确认客户端的可靠性时这样做，例如银行ATM机信息查询及存取钱）。

 CA证书包括以下内容：

• 证书的颁发机构
• 版本证书的使用者
• 证书的公钥（也就是说公钥是在CA证书中的）
• 证书的有效时间
• 证书的数字签名（Hash值）（其实是用证书的私钥进行加密后的值）
• 签名Hash算法

## 解决http的缺陷

 了解了这些后，现在我们可以来一一解决http协议的缺陷了。

### 通信使用明文，若被抓包，则直接被窃取信息

 https协议是使用对称加密和非对称加密的组合加密，使得就算被抓包，也无法获得有效信息。这个我会在接下来梳理清楚。

### 不验证与自身通信者的身份，有可能遭到伪装

 要想解决这个问题，就得借助于CA证书了。

 当浏览器端接受到服务器返回的CA证书时，他会进行一个验证操作——将该证书中的公钥与CA机构预置在操作系统中所有的公钥进行对比，如果没有找到相同的公钥，则证明该证书并非CA机构颁发的，所以有可能是伪装的服务器。

 我的理解是：你访问的网站是拥有CA证书的，所以其证书中的公钥应该能够被在操作系统中找到，而伪装者一般不会购买CA证书，最多只是自己创建了一个自己的证书（不会被CA机构承认），所以如果找不到该证书中的公钥的话，那就是伪装者。

### 无法证明报文是否被篡改

 同样得借助于CA证书。

 我们是通过证书中的公钥，证书的数字签名，签名Hash算法互相配合来做到是否篡改过该报文。

 过程如下：

 在验证了通信者的身份不是伪装的之后，我们用证书的公钥解签证书的数字签名，得到摘要。然后我们用签名Hash算法解析证书的数字签名，又得到一个摘要。将这两个摘要进行对比，若相同，则报文未被篡改。若不同，则说明报文被篡改过，数据不安全。

 在这里我想多提一句：

 可能大家发现了，我说了这么一句话：“我们用证书的公钥解签证书的数字签名”，可是我之前又说了“我们使用公钥加密报文，用私钥解密报文”，这不是矛盾吗？

 当然不矛盾，一个是加密解密，一个是签名解签。

 大家可以这样记忆：

1. 公钥加密，私钥解密。——用于加解密
2. 私钥产生签名，公钥验签。——用于签名

### https建立TCP连接流程

 以下讲的只是ssl连接过程，至于TCP连接3次握手过程忽略不讲。

 1. 客户端访问服务器，会发送客户端中产生的一个随机数A，将该随机数发送给服务器




 2. 服务器接收到信息之后，也生成一个随机数B，并将该随机数B和CA证书一同返回给客户端




 3. 客户端A接受到响应后，首先会验证该证书是否为合法CA证书，若合法，再通过验签操作确认该响应是否被篡改过（这两个过程都在上面讲过了，也就不在赘述）。若没有被篡改，则再产生一个随机数C，用证书的公钥来加密该随机数，并发送给服务器




 4. 服务器接受到数据后，使用私钥解密，得到真正的随机数C，这样不论是客户端还是服务器，都有随机数A，B，C，然后双方利用这三个随机数生成一个秘钥（服务器与客户端生成的秘钥是相同的，因为随机数都相同），而后通过这个生成的秘钥来进行对称加密来传输数据




 5. 之后所有的数据传输都是用该秘钥对称加密，回到了正常的http通信

 这个过程讲完了，我们回到第一个问题：“通信使用明文，若被抓包，则直接被窃取信息”。https不会出现这个情况，一是因为传输的数据不是明文，是对称加密后的数据。再是加密的秘钥并未在网络上传输过，是服务器和客户端根据本地随机数A，B，C生成的。所以可以保证即使被抓包了，攻击者也无法解析出有效信息。

 可能大家又会说，随机数A，B，C不是在网络上传输过了吗，那被抓包了，不就也可以用这三个随机数生成相同的秘钥吗？

 大家有没有注意到，虽然随机数A，B都是明文传输的，但随机数C他是使用的非对称传输，这也就是说，抓包者无法知道这个随机数C的真实值，即使他抓包到了公钥，但因为私钥只在服务器本地里，无法得到，所以也就无法解密出随机数C的真实值了。

（全文完）

参考资料

1. HTTP加密解密过程：http://blog.sina.com.cn/s/blog_185268e880102xvvu.html
2. 非对称加解密，私钥和公钥到底是谁来加密，谁来解密：https://blog.csdn.net/qq_23167527/article/details/80614454
3. 一文读懂Https的安全性原理、数字证书、单项认证、双项认证等：https://www.cnblogs.com/imstudy/p/9001886.html
4. https数字证书交换过程：https://blog.csdn.net/laiyuan999/article/details/80011579
5. 我是这样理解HTTP和HTTPS区别的：https://www.cnblogs.com/jesse131/p/9080925.html