HTTP（三）：HTTPS 安全原理｜对称加密、非对称加密、中间人攻击与数字证书

前言

hello hello💕，这里是洋不写bug~😄，欢迎大家点赞👍👍，关注😍😍，收藏🌹🌹
这篇博客是JavaEE学习专栏HTTP博客的最后一篇，前面博客提到，在使用HTTP时，运营商在中间注入 JS 广告、篡改下载链接、修改搜索跳转、伪造推广 Referer 薅佣金，损害了那些互联网大厂的利益，这也是国内网站大规模推进 HTTPS 的重要原因

这篇博客就会详细解析HTTPS协议如何对数据进行加密，并采取了哪些方法来反制黑客对数据进行破解，会画图来进行解析，这部分内容还是比较有趣的🐵
🎆个人主页：洋不写bug的博客
🎆所属专栏：JavaEE学习
🎆铁汁们对于JavaEE的各种常用核心语法，都可以在上面的JavaEE专栏学习，专栏正在持续更新中🏀，有问题可以写在评论区或者私信我哦~

1，加密简介

HTTPS就是对HTTP进行了加密处理，运营商中间设备只能看到域名，看不到网页内容、请求头，也不能篡改任何响应报文（HTTPS在其他方面的安全程度也更高，例如防止密码泄露）
对于加密，有一个学科叫密码学，也就是通过各种算法对数据进行加密，还是比较复杂的

传输的数据分为明文和密文

• 明文：待传输 / 待处理的原始数据，没有加密，任何人拿到二进制流都能直接看懂内容
• 密文：经过加密算法 + 密钥运算之后，输出的一堆看起来乱码的数据。 没有对应的正确密钥，拿到这串二进制，只能看到一堆无意义字节，无法还原成明文，也不能随意篡改（篡改之后解密校验失败）

明文转化为密文的过程就是加密，密文转化为明文的过程就是解密，拿到正确密钥，才能技进行解密

对于数据加密，在古代打仗时传递数据就已经开始使用了（例如戚继光在抗倭时发明的反切码，传令士兵只传递数字序列；敌方拿到数字，没有密码本，不知道对应读音、含义）

在二战时，传递情报主要靠的是无线电，但是无线电是往四周扩散的电磁波，队友能获取到，敌人也能获取到，加密己方的无线电和解密敌方的无线电就是二战中军方研究的一个重点

德国的闪电战是一种大规模快速协同作战，各装甲部队之间，它们和步兵、炮兵之间需要快速而保密地进行联系。而且地面部队的进攻还必须由斯图卡轰炸机群掩护支援，这也需要进行通信

当时德国就通过engima机对无线电信息进行加密，通过engima机（如下图），可以对信息进行很高强度的加密，通过人力是很难解密的

图灵大佬就研究出了一个bombe机（也称为炸弹机，如下图），通过机器来分析密钥，进而破解德军的密文
英国情报部门组装了200多台bombe机，每天可以破译约3000条德军情报，高效的情报破译给盟军作战带来了很大优势，甚至可以说帮助盟军提前结束了战争

2，对称加密

黑客的设备就相当于在客户端和服务器之间当一个中转站，客户端给服务器发送数据时，会先经过黑客的设备，再发送给服务器；服务器给客户端发送数据时，也会先经过黑客的设备，再发送给服务器
如果数据是明文传输的话，那交互和响应的数据黑客都是知道的，也可以篡改

为了保证数据安全，就引入了对称加密，简单来说就是生成一个密钥，明文通过密钥加密成密文，密文通过密钥解密成明文
比如要传输一个int类型的数字num，就随便拿一个数字k，a ^ k = b，发送方发送就发送这个b，接收方收到b之后，再用b ^ k，就得到了a，这就属于是一个非常简单的对称加密，实际使用的对称加密算法是比较复杂的

使用对称加密算法时，客户端给服务器发送的数据是经过密钥加密的，黑客就算获取到数据，不知道密钥，也不知道传输的内容是什么

通常一个服务器需要同时跟多个客户端进行通信，那跟不同客户端进行通信时，使用的密钥是同一个，还是不同的？
跟多个客户端进行通信时的密钥，是各不相同的，如果各个客户端都使用相同的密钥，那黑客自己访问服务器通信几次，就能分析出密钥，那后续其他客户端和服务器之间的加密通信都是无效的

既然每个客户端的密钥都是不同的，那就需要客户端或者服务器生成一个“随机密钥”，无论是谁生成的，都需要去通知对方
例如客户端负责生成密钥，密钥是888888（密钥是很长的字符串，这里只是演示一下），那客户端就需要给服务器发送密钥，但是发送是会经过黑客的设备的，也就是黑客跟服务器都知道了密钥是888888，后续加密也就无效了

有的铁汁可能会想：密钥key(888888)是明文传输的，那能不能再搞个密钥key2对key进行加密传输，但是这样还需要通知服务器key2是什么，否则服务器是解密不出来密钥是888888的，通知服务器key2的时候，还是会经过黑客的设备，黑客就能知道key2，进而解密出key

这里就相当于是一个套娃，不管加密几层，黑客只要得知加密最后一层的密钥，就能一路往前推，推出key😅，因此，单靠对称加密来保证网络通信的安全是不靠谱的，还需要引入非对称加密

3，非对称加密

在非对称加密中，有两个密钥，一个是公开的，都可以获得，就是公钥；另一个是不公开，自己持有的，就是私钥
对称加密就是只有一个密钥，同时使用这个密钥加密和解密，在非对称加密中，对数据进行加密和解密使用的不是同一个密钥，使用公钥进行加密，就用私钥进行解密，使用私钥进行加密，就用公钥进行解密（公钥/私钥是通过一系列的算法来生成的，还是比较复杂的，这个是密码学中的内容，对于开发来说，并不需要深究）

非对称加密的成本是比较高的，而对称加密不安全就卡在了密钥传输这里，因此通常在传输密钥这里用非对称加密，后续客户端和服务器的通信还是是用对称加密

非对称加密流程如下图：

1. 服务器会生成一套私钥和公钥，公钥公开，私钥服务器自己持有，假设客户端生成的密钥是888888（后续进行对称加密传输的密钥）
2. 客户端会先用公钥对888888进行加密，到达服务器后，服务器通过私钥对数据进行解密，就知道了后续进行对称加密通信的密钥就是888888，接着服务器和客户端就切换为对称加密通信（也就是数据用888888加密，用888888解密）
3. 黑客这里是无法破解出888888这个密钥的，因为私钥只有服务器采用，黑客是没办法解密的，后续的对称加密也就是安全的
   

有的铁汁可能会说：那黑客如果入侵服务器，拿到私钥，进而就可以成功监听了
确实是这样，但是黑客既然已经成功入侵服务器了，用户的数据都在服务器的数据库上存储着，那黑客就不需要监听数据，直接就把数据库拖跑了😂，服务器被拖库，这种情况在国内外都有，黑客会从数据库中拿到大量的用户数据，拿到后标记出售或者直接勒索企业（当然，知名网站的服务器的入侵门槛是很高的）

总结下，就是采用对称加密和非对称加密相结合的方式，只要在传输密钥的时候使用非对称加密，让黑客破解不出来密钥，后续通信就直接使用对称加密，这种做法看似很安全，因为服务器是很难入侵的，但是还是有安全漏洞，黑客还是能轻而易举的破解出通信数据，这就是接下来要提到的中间人攻击

4，中间人攻击

前面的对称加密 + 非对称加密看似安全性很高，让黑客无法拿到拿到密钥来解密数据，但是黑客还可以通过其他方法来破解数据

假设服务器生成的公钥是pub1，私钥是pri1，客户端在跟服务器通信前需要问服务器的公钥是什么，服务器返回pub1，接着客户端向服务器发送用pub1加密过的密钥，只有用pri1才能进行解密
流程如下图，按照这个流程，黑客是解密不出来密钥是888888的，因为黑客没有pri1

但是黑客是可以在中间动手脚的，密钥对是调用相关的库生成的，黑客就也能调用库生成个密钥对pub2/pri2，具体流程如下：

1. 服务器向客户端返回公钥是pub1，中间会经过黑客的设备，黑客改一下，通知客户端公钥是pub2，也就是黑客自己生成的公钥
2. 客户端收到pub2这个公钥后，就会用pub2来加密888888，发送给服务器，中间还是先到达黑客的设备，这时黑客就可以直接用pri2来解密数据，得到密钥是88888888
3. 为了不让服务器发现异常，黑客还需要对888888用pub1进行加密（服务器发送pub1时经过了黑客的设备，黑客是知道pub1的），再发送给服务器，服务器用pri1解密后就知道密钥是888888
4. 接着客户端和服务器的通信就使用对称加密，密钥是888888，黑客就可以获取到交互数据

中间人攻击的巧妙之处就在于：黑客的做法相当于是“欺上瞒下”，客户端和服务器都发现不了任何异常：

• 站在客户端的角度，服务器给我发送的密钥就是pub2，用pub2对888888进行加密后，服务器也能正常解密，后续可以正常通信
• 站在服务器的角度，告诉客户端公钥是pub1，后续客户端也确实是把888888按照pub1来加密并发送过来的

要应对中间人攻击，就要引入证书

5，证书

出现中间人攻击的核心原因就在于客户端无法分辨当前返回的公钥有没有被黑客篡改过（把pub1改成了pub2），通过引入证书，就能让客户端搞清楚当前的公钥是服务器创建的，还是黑客伪造的
服务器的开发者需要向电子认证服务机构（CA）来申请电子证书，当然，服务器申请时需要提交一些资料（比如企业资质）

这个电子证书就是由结构化数据构成的字符串，主要包含以下属性：

1. 证书的发布机构
2. 证书有效期
3. 证书所有者
4. 证书对应的服务器的地址/域名
5. 公钥（服务器生成的pub1）
6. 数字签名

电子认证机构自己也会生成一套密钥（pub3/pri3），在证书生成完成后计算校验和，用私钥（pri3）对校验和进行加密，就得到了数字签名

如下图，服务器就通过传递证书来给客户端传递公钥，客户端拿到证书后，会对证书进行校验，校验无误后，才会用证书中的公钥去加密888888并发送给服务器

证书校验方法：客户端对证书的字段计算校验和，得到checksum1；再使用pub3对解密数字签名，得到checksum2，如果checksum1等于checksum2，就说明证书没有被篡改过，如果不相等，就说明证书已经被黑客篡改过了，这时候客户端/浏览器就会弹出提示框，提示该网站存在风险，是否继续访问？

访问一些不正经网站时，浏览器也可能会弹出该网站存在风险，这是因为这个网站根本就没有拿到正规可信 CA 签发的证书😅

引入证书后，针对黑客的各种做法都有反制措施：

1. 黑客如果篡改公钥pub1，checksum就对不上，客户端就能识别出来
2. 黑客如果想把整个证书都替换掉，也是不行的；因为证书中包含了服务器的地址/域名（需要到认证机构申请的），如果黑客替换了整个证书，那域名就不同了，返回的证书跟网站的域名不一样，浏览器是很容易能识别出来的
3. 那黑客如果想篡改公钥pub1后，再重新计算下校验和，把数字签名也篡改了，这样也是行不通的；因为数字签名是校验和用认证机构的私钥pri3加密出来的，黑客不知道pri3，是无法对重新计算的校验和进行正确的加密的，后续客户端用pub3解密校验和时，黑客就露馅了
4. 有的铁汁可能会想：黑客能不能在客户端拿认证机构公钥pub3的过程这里做一下手脚，让客户端拿到黑客生成的公钥pub4，这样黑客更改校验和时用pri4进行加密，这样客户端用pub4可以正常解密数字签名，就不会发现有问题
   这个也是行不通的，因为认证机构的公钥不是通过网络获取的，而是内置在操作系统中的（前些年一些人图方便，装系统时不安装原版本Windows系统，而是安装其他的一些镜像系统（安装快，自带全套驱动和常用软件），镜像系统的制作者可以在镜像内预先植入伪造的 CA 公钥，带来 HTTPS 中间人攻击的安全隐患）

结语💕💕

• HTTPS属于是面试的一个重点内容，建议铁汁们梳理下过程，从头到尾分析对称加密、非对称加密、证书的作用，以及怎样在哪些方面来反制黑客破解数据
• 下篇博客会进入到JVM的解析，JVM也是JavaEE学习专栏中的最后一档内容，后续还会有JavaEE进阶专栏，解析JavaEE进阶知识（博主也会尽力的加快速度来更新）

以上就是今天的所有内容啦～完结撒花～🥳🎉🎉