HTTPS加密原理✿✿ヽ(°▽°)ノ✿

文章目录

• JavaEE & HTTPS加密原理
• • 1. 为什么要加密
  • 2. HTTPS加密原理
  • • 2.1 初始想法
    • 2.2 引入非对称加密
    • 2.3 中间人攻击
    • 2.4 引入证书

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
  • 一般黑客篡改响应，而不是篡改请求让服务器返回不同的响应，因为知道正文没这个必要去篡改请求，反而有风险~
  • 因为看得到请求才能篡改响应和篡改请求，至于不让请求发出去或者发不一样的请求（响应是发回黑客，不是客户端），客户端如果收不到（超时重传），起不到效果~
  • 所以，只有黑客解密成功，并加密成功，客户端才认这个数据
    

而这就是最原始的：对称秘钥

• 即，加密和解密用的是同一把钥匙

那我们来看一下数据报在网络上的传输~

• 这样，数据报在网络上以密文的形式传输，黑客自然就无法篡改

聪明的你可能想到了：

1. 如果这个密钥每个客户端都是一样的，那么黑客也可以是客户端，这样密钥就拿到手了，所以每个客户端都是不一样的密钥~
2. 如果这个密钥由每个客户端自己生成的，那么则需要连同密文一起传给服务器才行，而黑客因此也可以拿到密钥了！这样子，对称密钥的安全性几乎为0~

2.2 引入非对称加密

由于对此加密的不安全性，则需要引入非对称加密，提高数据传输安全性~

非对称加密的加密规则如下：

• 相比于对称加密，它多了一把密钥

就是说，通过pub加密的密文，不能由pub解密，得由与之对应的pri解密；而通过pri加密的密文，不能由pri解密，得由与之对应的pub解密！

• 同理，通过pub解密的明文，也只能由pri加密；pri解密的明文，也只能由pub加密！

那我们来看一下数据报在网络上的传输~

第一步：

• 目前所有人都拥有公钥pub，只有服务器拥有私钥pri

第二步：

• 客户端本来就有key，响应的时候没必要传key
  • 千万不能用pri加密key，因为pub可以进行解密！
  • 并且私钥就是私用的，并不是人人皆知~

为什么不用pub直接加密req？

原因是，服务区虽然可以pri解密计算响应，但是这么返回响应呢？

1. pri加密响应，pub可以解密
2. pub加密响应，客户端看不懂

• 这样，数据报在网络上以密文的形式传输，黑客自然就无法篡改

2.3 中间人攻击

相信聪明的你又能想到黑客可以怎么做：

• 之后客户端就是小丑了

• 黑客又赢了~

这就是中间人攻击~

2.4 引入证书

说到底，这里的问题就是，客户端直接相信了黑客传过来的pub，那么我们只需要判断这个pub的权威性，就行了~

这里的证书，不是“纸质”的证书，而是一个抽象的“对象”，里面又很多属性

• 即，电子数字证

有一个权威的机构，负责颁发证书

• 而我们的服务器要加密传输的https，那么我们就需要去这个机构里，申请证书！

• 申请的时候，要提交一些资料（甚至要交钱），机构审核通过了，就会颁发证书

  • 而我们在提交资料的时候，就提交上公钥pub，就行了~

而第一步的索要pub就变为索要证书：

• 现在，每个人都拥有这个证书

与之前的方法不同的是，黑客不能轻易的篡改证书，是由于现实原因和客户端证书的验证机制：

一、黑客不可以自己去申请证书？

1. 成本高
2. 只有pri才能解密得到key，而这个pri还在服务器那~
3. 证书的属性里面有“服务器的域名”等等…，所以黑客如果改域名为服务器的以免穿帮，校验和也会因此变化~

二、黑客自己就是权威机构？

1. 不现实，成本极其高，因为权威机构规模得很大
2. 不安全，权威机构人人都是实名的，所以黑客不会这么做，客户端有损失，就会查到

客户端验证证书的机制，靠的就是证书的这一个属性：签名（即校验和）

• 这个校验和的计算，跟之前学的校验和一样，是由一个“一一对应”的函数计算得来的
  • 假如**校验和 = f(x₁, x₂, x₃, x₄ …)** ，那么这个函数的每一对参数序列，都对应不一样的值！
  • 也就是说，只有证书的所有属性都不变，校验和才不变

而这个签名，由证书的私钥pri进行加密了，而我们怎么解密的？

• 这个是一个权威的机构，几乎每一台机器上，都保存了他们的pri所对应的pub
• 而黑客跟客户端一样，拥有公钥去获取签名

第二步（校验）：

问题：

1. 那这样黑客不就知道客户端的信息了吗？
   • 并不是，这里黑客只知道“我要证书”的请求（截断它的请求，会超时重传，所以没必要）
   • 黑客也只知道证书这个对象，而这个对象本来就是公布的
   • 而真正值钱的信息则是客户端信任后发布的请求！
2. 黑客就不能修改属性后，调整到与校验和一致？
   • 不行，因为计算校验和的函数是“一一对应”的函数
   • 其次，调整后不符合侵略目的
3. 黑客就不能修改属性后，修改校验和？
   • 不行，因为黑客得到校验和，将其修改，那么还要将其加密，加密成能由pub解密的密文，而这个加密过程的难度等同于去“解密对称密钥key”，因为黑客没有证书pri
4. 能不能将校验和正文传过去
   • 不行，因为客户端会将这个正文当成密文，用pub解密，解密后就会发现对不上~
   • 那得找到解密后为正确的校验和的那个密文，那就是加密啊，回归到问题3的逻辑了~

这样黑客破解起来的成本就很高了

• 但不代表这种方式百分百安全，因为安全是相对的，没有绝对的安全~

---

文章到此结束！谢谢观看
可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭🦆！

✿✿ヽ(°▽°)ノ✿

---