JavaEE & HTTPS加密原理
1. 为什么要加密
例子：（运营商劫持）
你可能经常遇到一个现象，就是在下载一些软件的时候，明明是软件A，弹出的下载连接确实软件B：
未劫持的版本：
劫持后的版本：
变成QQ浏览器了 >、 v <、
因为数据报在网络上是通过许多交换机和路由器的转发进行传输的，所以经过运营商设备很正常！
因此被劫持了
不仅仅运营商可以劫持，黑客当然也可以~
只要网络上的数据是明文传输的，都是存在被劫持被更改的风险！
而我们让网络数据传输变得相对安全的方法就是，让破解的成本高于数据的价值！
因为再厉害的方法，都不是万能的~
HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：
一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。
https即在http的基础上通过加密，提高破解成本！
此处的加密，我们就只作为一个“行为”，如何加密的不讲~
认为加密后就是乱码~
解密也是，看成一个“行为”就是了
2. HTTPS加密原理
2.1 初始想法
我们的想法是：将明文转化为密文传过去
明文 => 密文， 【加密】
密文 => 明文， 【解密】
而加密的过程我们抽象成一个对象“秘钥”，通过这个秘钥，可以让我们的明文通过一定的逻辑去计算后转化为密文
加密一般针对的是HTTP的各种header 和 body
一般黑客篡改响应，而不是篡改请求让服务器返回不同的响应，因为知道正文没这个必要去篡改请求，反而有风险~
因为看得到请求才能篡改响应和篡改请求，至于不让请求发出去或者发不一样的请求（响应是发回黑客，不是客户端），客户端如果收不到（超时重传），起不到效果~
所以，只有黑客解密成功，并加密成功，客户端才认这个数据
而这就是最原始的：对称秘钥
即，加密和解密用的是同一把钥匙
那我们来看一下数据报在网络上的传输~
这样，数据报在网络上以密文的形式传输，黑客自然就无法篡改
聪明的你可能想到了：
如果这个密钥每个客户端都是一样的，那么黑客也可以是客户端，这样密钥就拿到手了，所以每个客户端都是不一样的密钥~
如果这个密钥由每个客户端自己生成的，那么则需要连同密文一起传给服务器才行，而黑客因此也可以拿到密钥了！这样子，对称密钥的安全性几乎为0~
2.2 引入非对称加密
由于对此加密的不安全性，则需要引入非对称加密，提高数据传输安全性~
非对称加密的加密规则如下：
相比于对称加密，它多了一把密钥
就是说，通过pub加密的密文，不能由pub解密，得由与之对应的pri解密；而通过pri加密的密文，不能由pri解密，得由与之对应的pub解密！
同理，通过pub解密的明文，也只能由pri加密；pri解密的明文，也只能由pub加密！
那我们来看一下数据报在网络上的传输~
第一步：
目前所有人都拥有公钥pub，只有服务器拥有私钥pri
第二步：
客户端本来就有key，响应的时候没必要传key
千万不能用pri加密key，因为pub可以进行解密！
并且私钥就是私用的，并不是人人皆知~
为什么不用pub直接加密req？
原因是，服务区虽然可以pri解密计算响应，但是这么返回响应呢？
pri加密响应，pub可以解密
pub加密响应，客户端看不懂
这样，数据报在网络上以密文的形式传输，黑客自然就无法篡改
2.3 中间人攻击
相信聪明的你又能想到黑客可以怎么做：
之后客户端就是小丑了
黑客又赢了~
这就是中间人攻击~
2.4 引入证书
说到底，这里的问题就是，客户端直接相信了黑客传过来的pub，那么我们只需要判断这个pub的权威性，就行了~
这里的证书，不是“纸质”的证书，而是一个抽象的“对象”，里面又很多属性
即，电子数字证
有一个权威的机构，负责颁发证书
而我们的服务器要加密传输的https，那么我们就需要去这个机构里，申请证书！
申请的时候，要提交一些资料（甚至要交钱），机构审核通过了，就会颁发证书
而我们在提交资料的时候，就提交上公钥pub，就行了~
而第一步的索要pub就变为索要证书：
现在，每个人都拥有这个证书
与之前的方法不同的是，黑客不能轻易的篡改证书，是由于现实原因和客户端证书的验证机制：
一、黑客不可以自己去申请证书？
成本高
只有pri才能解密得到key，而这个pri还在服务器那~
证书的属性里面有“服务器的域名”等等…，所以黑客如果改域名为服务器的以免穿帮，校验和也会因此变化~
二、黑客自己就是权威机构？
不现实，成本极其高，因为权威机构规模得很大
不安全，权威机构人人都是实名的，所以黑客不会这么做，客户端有损失，就会查到
客户端验证证书的机制，靠的就是证书的这一个属性：签名（即校验和）
这个校验和的计算，跟之前学的校验和一样，是由一个“一一对应”的函数计算得来的
假如**校验和 = f(x1, x2, x3, x4 …)** ，那么这个函数的每一对参数序列，都对应不一样的值！
也就是说，只有证书的所有属性都不变，校验和才不变
而这个签名，由证书的私钥pri进行加密了，而我们怎么解密的？
这个是一个权威的机构，几乎每一台机器上，都保存了他们的pri所对应的pub
而黑客跟客户端一样，拥有公钥去获取签名
第二步（校验）：
问题：
那这样黑客不就知道客户端的信息了吗？
并不是，这里黑客只知道“我要证书”的请求（截断它的请求，会超时重传，所以没必要）
黑客也只知道证书这个对象，而这个对象本来就是公布的
而真正值钱的信息则是客户端信任后发布的请求！
黑客就不能修改属性后，调整到与校验和一致？
不行，因为计算校验和的函数是“一一对应”的函数
其次，调整后不符合侵略目的
黑客就不能修改属性后，修改校验和？
不行，因为黑客得到校验和，将其修改，那么还要将其加密，加密成能由pub解密的密文，而这个加密过程的难度等同于去“解密对称密钥key”，因为黑客没有证书pri
能不能将校验和正文传过去
不行，因为客户端会将这个正文当成密文，用pub解密，解密后就会发现对不上~
那得找到解密后为正确的校验和的那个密文，那就是加密啊，回归到问题3的逻辑了~
这样黑客破解起来的成本就很高了
但不代表这种方式百分百安全，因为安全是相对的，没有绝对的安全~
