JavaEE初阶---网络原理（六）---HTTPS加密（对称，非对称，中间人攻击，公证机构）

1.HTTPS加密的引入

当前我们的这个网络上面的绝大部分内容都是使用的这个HTTPS协议，相较于我们之前学习的这个HTTP协议，这个HTTPS就是在原来的这个基础上面进行了内容的加密；

1.1对于加密的基本认识

就是我们的这个HTTP在网络上面进行传输的时候都是明文，因此这个安全性无法得到保证，所以我们的这个HTTPS就是在原来的这个HTTP基础上面对于这个内容进行加密，这个就是为了提高我们的传输内容的安全性；

我们的明文+密钥=》密文；----加密过程

密文+密钥=》明文；解密过程

1.2对称加密

上面的这个过程（加密和解密）如果我们的这个过程中，加密和解密使用的这个密钥是一样的，这个时候我们的就把这个方式称之为对称加密；

但是我们的这个服务器是不知道是哪一个客户端访问的，因此这个服务器就需要让这个客户端把这个密钥发送过来，但是这个如果被黑客截获了，这个设置就形成虚设了；

image-20241101193518489

反之，如果这个过程使用的密钥不是一样的，就是我们下面会介绍的这个非对称加密；

1.3非对称加密

针对于上面的这个问题，我们引入非对称加密；

非对称加密有一对密钥，即公钥和私钥，我们可以使用这个公钥加密，私钥解密，或者是使用私钥解密，公钥加密，都是可以的；

我们的服务器生成一对公钥和私钥，服务器把这个公钥返回给这个客户端，服务器自身把这个公钥藏好（谁都不给，仅仅自己可见）；我们的这个服务器把这个公钥返回给这个客户端，这个时候我们的客户端有公钥，服务器有私钥，我们的这个客户端通过这个公钥对于发送的数据进行加密操作，返回给我们的服务器端，这个时候即使这个黑客可以从中截获，这个时候也是无能为力的，因为这个加密的内容只有这个私钥可以进行解密，但是我们上面已经说了，这个服务器只把这个公钥给这个客户端，这个私钥只有我们的服务器自己有，其他人都是没有的，因此这个时候的黑客也是无能为力的；

image-20241102105742019

1.4对称非对称的问题

为什么这个非对称这么安全，我们还搞这个对称加密这样的不安全的机制呢？

主要是因为我们的这个非对称加密和解密的这个过程的成本是很高的，速度也是很慢的，而我们的这个对称加密的这个速度很快，而且成本很低；

我们只需要在这个关键环节使用这个非对称加密即可，例如进行密钥的传输，后面对于这个业务上面的数据进行传输的时候，我们使用这个对称加密，这样会更加高效一些；

如果无论是业务数据还是关键数据，都是用这个非对称加密的方式进行传输，这样虽然可靠，但是传输的效率会大打折扣；

2.中间人攻击

上面介绍的这个对称加密和非对称加密只是我们的这个HTTPS加密协议里面的这个基本盘，但是这个过程其实还是有漏洞的，我们的这个黑客如果使用好了这个漏洞，这个时候还是可以获取我们的这个明文数据的；

在下面的这个图片里面，我们的这个服务器自己生成了这个pub1和pri1这个公钥和私钥，我们的这个客户端问这个服务器索要这个公钥，这个时候我们的服务器就会返回这个pub1，但是这个时候我们的中间人（黑客入侵的设备）对于这个公钥进行篡改，返回自己对应响应的公钥pub2，这个时候我们的这个客户端并不知道这个公钥是被修改过的，于是基于这个pub2进行加密，获取到了这个对称密钥，并且告诉这个服务器，我们就是用这个对称密钥进行通信，这个实际上是基于我们的这个黑客入侵的设备进行操作之后的这个pub2加密的，并不是最原始的这个服务器发送的这个公钥，但是我们的这个客户端不知道啊~~

image-20241102110840319

客户端操作之后的对称密钥返回给这个服务器的时候，这个就会被我们的中间人截获，这个中间人使用自己有的这个pub1进行加密，再次把这个进行篡改，这个时候相当于我们的这个客户端不知道自己的这个pub2已经被修改，而这个服务器看看这个内容和自己的这个私钥是对应的，认为这个就是客户端发来的内容，这个过程简直是天衣无缝，服务器客户端都看不出来破绽，但是我们的这个黑客入侵的设备坐收渔翁之利，瞒天过海，早就把这个过程给偷梁换柱了，但是我们的这个客户端服务器就浑然不知；

这样导致的后果就是我们的这个客户端以后发送的数据，我们的这个黑客入侵的设备都是可以进行破解的，而且还可以让这个客户端和服务器都感知不到，让我们的这个服务器以为自己是在和这个客户端进行交互，让我们的这个客户端以为自己是在和服务器交互；

上面的这个过程，就是我们说的破绽，这个就是中间人攻击的过程，那么，我们应该如何解决这个中间人攻击呢，这个时候就需要引入我们的公证机构~~

3.公证机构

上面的这个问题根源在于这个客户端无法进行分辨，就是不知道这个公钥是不是服务器发过来的，还是黑客进行了篡改的；

这个时候，我们需要一个第三方的公证机构，如果这个机构证明这个公钥是正确的，我们就可以使用了；

就是我们的这个服务器使用自己的这个域名，或者是这个公钥厂商之类的生成这个证书（交给这个公证机构，这个公证机构给我们的这个服务器证书，这个证书并不是纸质的证书，而是一段这个结构化的数据）；

image-20241102112041654

颁发证书的时候，这个公证机构会针对于这个证书里面的各个属性，计算校验和，针对于这个校验和进行加密，得到这个数字签名（这个公证机构也会得到这个公钥和私钥，这个和我们的这个服务器自己的这个公钥和私钥是不一样的），其中这个公证机构的公钥就会给这个客户端一份；

这个过程中提及的这个数字签名，就是我们的这个加密之后的数据的校验和，就是拿着数据，代入公式进行计算，得到的数学的结果就是校验和，把这个数据的校验和发送给我们的对方，对方再计算一遍，对方算完之后的这个校验和与我们的这个收到的校验和是一致的，这个就说明我们的这个数据在传输过程中没有进行修改过；

我们的这个证书里面是有这个公钥的，因此我们的这个客户端得到的就是这个公钥和证书，公钥在这个证书里面，我们的这个服务器进行发送的时候，是把这个数据和校验和一起发送给这个客户端的；

我们的这个黑客如果修改这个公钥，这个时候我们的客户端计算的这个校验和就会和收到的这个不一致（我们收到的数据是服务器发来的，我们的这个校验和是使用这个公钥计算的，如果这个黑客修改公钥，使用这个修改之后的公钥是无法计算出来这个准确的校验和的）；

到的数据是服务器发来的，我们的这个校验和是使用这个公钥计算的，如果这个黑客修改公钥，使用这个修改之后的公钥是无法计算出来这个准确的校验和的）；

那么这个黑客能不能自己搞出来数字签名呢？就是我们的这个黑客把这个校验和的计算的这个机制改掉，这个也是不可以的，主要是因为我们的这个校验和需要进行加密，这个加密需要使用这个公证机构的私钥，如果黑客使用自己的这个进行校验和的加密，这个时候我们的客户端无法使用这个得到的公钥进行解密和计算