前言

前面我们学习了应用层中使用比较常见的 HTTP 协议，但是呢？在实际的使用中，浏览器和服务器之间的通信其实很少使用到 HTTP，为什么 HTTP 的使用很少呢？这是因为使用 HTTP 在和服务器进行通信的时候，是明文传输的，只要黑客抓取到这个 HTTP 数据包之后，很容易就可以得到其中的数据，所以就需要对这个数据包进行加密，所以就出现了 HTTP 的进化版——HTTPS。

为什么会出现 HTTPS

HTTPS 协议的出现主要是为了解决 HTTP 协议在安全性上的不足。HTTP 协议被广泛使用，但存在以下安全性问题：

1. 明文通信，内容可能被窃听。
2. 不验证通信方身份，通信方可能是伪装的。
3. 不验证报文的完整性，报文可能被修改。

为了解决这些问题，HTTPS 在 HTTP 的基础上进行了升级：

1. 对传输过程中内容进行加密保护，防止内容被窃听。
2. 利用证书确定对方的身份，防止通信方伪装。
3. 给出完整性保护的措施，确保报文不会被篡改。

通过这个 HTTPS 对数据进行加密，就可以很好的解决我们前面提到的运营商劫持的问题。

HTTPS 是如何进行加密的

1. 对称加密

大家之前多多少少也是看过抗日剧的吧，那么在进行打仗的时候，前线和指挥部是如何进行通信的呢？很早之前，前线和指挥部的通信是由一个专门的组织——通信兵完成的，但是通信兵因为需要通过走路或者马等交通工具进行通信，而战场的局势又是实时变化的，所以当通信兵将信息交给指挥部或者前线的时候，这个战略可能又不适合了，并且通信兵在两者之间传输数据的时候，有可能还会遭到地方的追击，这样就会导致信息在两者之间的传递是很慢且安全性比较低的。

所以为了解决数据在指挥部和前线之间传递的速度和安全性，人们便发明了电报，与此同时还出现了与之对应的密码本，通过发来的报文，然后对照着这个密码本，就可以得到这个原始的数据，就算这个电报发送的报文被地方截取到了，只要地方没有这个密码本，那么地方拿到了这个报文也是没用的。这个时候的密码本通常双方使用的是一样的密码本。

在 HTTPS 中这个“密码本”被称为“密钥”，这个“钥”有很多种读法——密钥（yue）、密钥（yao）。通过这个密钥，发送发可以根据这个密钥，将原文加密成密文，然后当接收方得到这个数据的时候，就可以通过这个密钥对这个数据进行解密，得到原文。原文+密钥 =》密文；密文+密钥=》原文。而这个双方具有的密钥是一样的叫做——对称加密

当黑客接获到通信的数据，因为没有密钥，是无法解析这个数据的，也不是说无法解析，只是解析的成本可能大于这个数据本身的价值。

但是有一个问题，既然服务器和客户端拥有的密钥是相同的，那么有这么多的客户端会和服务器进行通信，如果各个客户端也还是使用相同的密钥的话，那么这个加密就并没有意义了，所以当客户端在和服务器端建立连接的时候，首先就会协商使用哪个密钥。而在这个建立连接的过程中，也是可能被黑客截获的，如果黑客截获到这个密钥的话，客户端和服务器端之间的通信对于黑客来说就是一览无余的。

那么有人就会问了：如何解决在协商的时候，密钥被黑客截取的问题呢？我再使用一个对称密钥对这个密钥进行加密可以吗？肯定是不行的，既然这个对称密钥可以被黑客截获，就不敢保证另一个对称密钥不会被黑客截获。

所以，为了解决对称密钥被黑客劫持的问题，就出现了非对称密钥

非对称加密

在客户端和服务器建立连接之前，服务器那边就会生成一对公钥-私钥，当客户端和服务器建立连接的时候，客户端会向服务器发送请求询问公钥是多少，服务器会将这个公钥明文发送给客户端，如果在这个过程中公钥被黑客截获到了也无所谓，因为服务器生成的公钥是公开的，谁都可以获得到，但是客户端通过公钥加密的数据只有通过服务器对应的私钥才能对其进行解密，而服务器的这个私钥只存在于该服务器，不会外传。所以黑客是不能获得到私钥的，也就不能解密出公钥加密的数据。

但是是否就会出现一种情况：就是客户端生成的对称密钥，这个服务器已经和另一个客户端协商好使用了，那么这时候是应该服务器生成一个对称密钥，然后通过密钥进行加密发送给客户端呢？这样是不行的，因为如果使用私钥对这个对称密钥加密的话，因为公钥是公开的，所以当黑客拿到这个含有对称密钥的数据包的时候就可以使用公钥对这个数据包进行解密，最终得到这个对称密钥，那么这样的话，客户端和服务器之间的通信就又被人监视了。所以当客户端生成的对称密钥已经被其他的客户端和这个服务器使用的话，服务器不会生成对称密钥，而是只相当于返回一个“你这个对称密钥我已经和别的客户端使用了，你再生成一个吧”类似这样的数据包返回给客户端，当客户端收到这个数据包的时候就用公钥对齐进行解密，然后再在本地生成另一个对称密钥，重复上述过程直至对称密钥是唯一的。

客户端会在本地生成一个对称密钥，然后公钥加密，发送给服务器，在这个过程中，如果数据被黑客截获到了，因为这个数据通过了客户端的公钥加密，而黑客不知道这个公钥的私钥，所以黑客就无法获得这个对称密钥；当服务器得到这个数据的时候，服务器就可以通过配对的私钥对这个数据进行解密，然后得到这个对称密钥，服务器就会将协商好的对称密钥通过配对的密钥进行加密，返回给客户端，当客户端得到这个数据的时候就会通过公钥解密这个数据，得到最终协商的对称密钥。当下次进行通信的时候，就可以使用这个对称密钥对数据进行加密了。

既然非对称加密，可以防止密匙被黑客截获的问题，那么为什么还要引入对称加密呢？这其实和 TCP 协议传输数据类似，在保证 TCP 传输数据的时候的安全性的时候，速度却没有 UDP 传输数据快，那么非对称加密也是如此，进行非对称加密的计算成本是比较高的，并且运算速度也是比较慢的，而对称加密成本比较低且运算速度也快，所以就出现了 非对称加密+对称加密 这样的机密方式，非对称加密只是用于协商对称加密的时候的加密，当保证对称加密安全协商好之后，后面客户端和服务器之间的通信就是用对称加密了，也就是说：对称加密是一次性的。

但是引入 对称加密 + 非对称加密 这种加密方式就能解决所有的黑客攻击吗？答案是不可以的，当出现 中间人攻击 的时候，就可能会出现问题。

中间人攻击

HTTPS 是通过使用 SSL/TLS 协议对 HTTP 进行加密，以保护网络通信中的数据传输安全。然而，就像任何其他网络协议一样，HTTPS 也可能受到中间人攻击（Man-in-the-Middle Attack）。

中间人攻击是一种网络攻击，攻击者通过拦截和读取网络中的数据包，获取或篡改这些数据包，并将它们发送到原始的发送方或接收方。在 HTTPS 中，中间人攻击可能发生在 SSL/TLS 握手期间，攻击者可能会冒充原始的客户端或服务器，与另一方建立不安全的连接。

假如客户端向服务器发送请求，询问服务器：你的公钥 public key1 是什么啊？如果在这个过程中，黑客截获到了这个客户端发来的请求的话，那么黑客会自己生成一对公钥 public key2 和密钥 private key2，并且将这个自己生成的公钥 public key1 返回给客户端；与此同时，黑客也会根据客户端发送的请求中的服务器的地址，再向这个服务器发送请求：你的公钥 public kyey1 是什么啊？这时候，服务器收到这个请求的话就会将生成的公钥 public key1 返回给黑客，当黑客完成这个操作的时候，那么截获到的客户端和服务器发送的数据，黑客都能知道里面的具体内容。当客户端使用公钥 public key1 对生成的对称密钥 8888 进行加密之后，就会将这个加密数据包发送给服务器，那么黑客就会截获到这个数据包，然后黑客会使用私钥 private key2 对响应密文进行加密，并将这个数据包返回给客户端，同时使用公钥 public key1 对生成的对称密钥 8888 的数据包进行加密，服务器收到这个数据包就会用私钥 private key1 对这个数据包进行解密，得到这个对称密钥，并且返回响应密文。由此操作，黑客就可以充当客户端和服务器之间的中间人，既能知道客户端和服务器通信的具体内容，也不会被他人发现。

当黑客进行了以上操作的时候，客户端和服务器端之间通信的对称密钥黑客就知道了，这时客户端和服务端之间的通信的数据包经过黑客的时候，因为黑客知道这个对称密钥，所以就可以得到这里面的数据，而客户端和服务器也不会发现它们之间的数据已经被黑客截获到了。

要想解决中间人攻击的问题，客户端不知道这个对称密钥是否是由黑客伪造的，这里的“分辨”不能靠“自证”，谁说自己都是对的，所以这里就会需要第三方作为“公证机构”来证明你这对称密钥是否是由黑客伪造的，这个证明是否是由黑客伪造的就叫做——证书

3. 引入证书

HTTPS 中的证书是由受信任的第三方认证机构（CA）颁发的数字证书，用于验证服务器身份和安全性。当服务器在建立的时候需要向这个“公证机构”进行证书的申请，向“公证机构”提交一些：域名、公钥、厂商、有效期等材料，然后“公证机构”就会对这些提交的材料进行审核，审核完成之后会为这个服务器颁发一个“证书”。这个证书不是纸质的证书，而是一段结构化的数据，这里面会包括服务器的域名、服务器的公钥、证书的过期时间、数字签名……等等。

当客户端向服务端建立连接时候，客户端不会向服务端索要公钥，而是会向服务端索要证书，并且这证书是“公证机构”也是经过了非对称加密的，“公证机构”会拥有私钥，然后通过这个私钥对这个证书进行加密，当客户端通过配对的公钥获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

1. 判定证书的有效期是否过期
2. 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
3. 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.如果相等, 则说明证书是没有被篡改过的.

而这个判断数据是否被篡改过就需要依靠证书中的 校验和 ，当“公证机构”办法证书的时候，会计算出一个校验和，并且会对这个校验和通过私钥进行加密，这个加密之后的校验和就生成了数字签名。当客户端得到这个证书之后，会重新计算这里面的校验和，如果计算出来的校验和和证书中用公钥解密数字签名得出来的校验和不同，那么就会认为这个证书被人修改过，这时客户端就会提出类似警告，告诉你当前存在风险。

那么在这个过程中，黑客能否替换掉这个数字签名然后自己计算出来一个数字前面呢？答案是不行的，因为黑客不知道公证机构的私钥，那么计算出来的数字签名很大概率是和之前不一样的，但是客户端的公钥是和公证机构的私钥是配对的，那么计算黑客传来的证书的时候，计算出来的校验和很大概率是不一样的。

那么黑客是否可以直接自己生成一个证书，然后替换掉服务器的证书呢？也就是说我客户端想要的是服务端的证书，但是由于被黑客劫持了，所以黑客返回的就是自己生成的证书呢？答案肯定是不行的，因为证书中包含了网站的域名，你黑客的域名跟服务器的域名是不一样的，那么当客户端使用和服务器证书配对的公钥进行校验的时候，计算出来的结果肯定是不一样的，所以这个方法是行不通的。

所以通过上面的一系列做法，就能保证客户端和服务器中间通信的安全性。