JavaEE—— HTTP协议和与Tomcat (末篇)

最新推荐文章于 2024-05-14 00:06:09 发布

Mo_yang.

最新推荐文章于 2024-05-14 00:06:09 发布

阅读量683

点赞数 21

分类专栏： JavaEE 文章标签： java-ee http tomcat

本文链接：https://blog.csdn.net/qq_62905847/article/details/130838303

版权

JavaEE 专栏收录该内容

28 篇文章 0 订阅

订阅专栏

本篇文章，承接前面两篇文章：

在前面的两篇文章中，简单介绍了什么是 HTTP 协议，介绍了抓包工具，如何构造 HTTP 请求，以及，如何使用第三方工具来简化构造请求的过程。
如果需要了解前面的知识可以通过下面的链接访问前两篇文章。

链接: HTTP协议(初篇)
链接: HTTP协议(中篇)

一、介绍 HTTPS

什么是 HTTPS？

所谓 HTTPS 也是一个应用层协议。是在 HTTP 协议的基础上引入了一个加密层。

1. 解释为什么会有 HTTPS 的出现

对于 HTTP 协议内容都是按照文本的方式进行明文传输的。这样，在传输的过程中，就难免会出现被篡改的情况。

对于上面提到的 “被篡改”，这里就提到曾经 臭名昭著的 “运营商劫持”

解释运营商劫持
在我们还没有使用 HTTPS 的呢个时期，我们要在网上下载一个东西常常会出现这样的情况：
我想要下载一个酷狗音乐，但是在下载完成后，却发现是 360。。。
这就是 “运营商劫持”。
使用画图的方式解释情况大致如下：

在网络中，明文传输是比较危险的事，对此，为了解决上述的问题，就出现了 HTTPS。

2.解释加密

HTTPS 相较于 HTTP 是在其基础上进行了加密用来保护用户信息安全。

加密， 就是将要传输的信息进行一系列的变换，生成密文。
解密， 就是将密文进行一系列的转换还原为明文。
在这两者之间，往往需要一个中间元素 (类似于密码本) 辅助进行加密解密，这类数据称之为秘钥。

对于加密的方式，大致分为两种，分别为：对称加密 和 非对称加密。

对称加密

所谓对称加密，其过程可以形象的表示为下面的形式：
a(明文) + key => b(密文) 加密的过程
b(密文) + key => a(明文) 解密的过程

在这里，同一个秘钥，可以用来加密也可以用来解密。所以称之为 对称密钥。

对称加密的安全性前提是，秘钥不可以被黑客知道
简单图示大致如下：
在这里插入图片描述
但是，在这之中，我们需要思考一个问题，这个秘钥，在一开始是不存在的，呢么需要哪一方来生成，并且如何安全的将秘钥传递出去呢？

解释秘钥由哪一方生成

我们要知道，服务器在同一时刻需要为多个客户端提供服务。而每个客户端的秘钥又是不同的。对此，让服务器维护每一个客户端和秘钥之间的关联，是一件非常麻烦的事。

所以，比较理想的方式是， 在客户端和服务器每次建立连接之时，双方协定本次秘钥为什么。(即由哪一方生成都可以)

解释传递密钥时的安全性问题

不难理解，客户端与服务器之间的秘钥传递，很显然是一段 明文传输的过程。此时，也就是黑客最容易入侵获取秘钥的阶段。
简单图示：
在这里插入图片描述

因此，密钥的传输也是需要进行加密的！

对于以上的问题，就引出了加密的另外一种形式，非对称加密。

非对称加密

非对称加密就是为了安全的将秘钥传递过去。
在这个过程中需要产生一对秘钥分别为，公钥和私钥。

解释什么是公钥 / 私钥

公钥： 顾名思义，就是两台设备之间都会知道的 “秘钥” (一般是由客户端在加密对称秘钥时向服务器索取)
秘钥： 顾名思义，就是只有一方知道的 “秘钥” (一般由服务器自己保存，不会向外传递)

使用公钥进行加密，使用私钥进行解密。(这也可以反过来用)
形象的来讲就是：
明文 + 公钥 => 密文
密文 + 私钥 => 明文

图示如下：
在这里插入图片描述

解释公钥和私钥的工作过程

客户端会在本地先生成对称密钥，通过公钥进行加密，发送给服务器。
中间的网络设备并没有私钥，即使数据被截获也是无法还原出原文的。对此也不会获取到对称密钥。
服务器会对获取到的数据进行私钥解密，然后使用对称密钥向客户端返回响应数据。
后续只使用对称加密即可，因为只有客户端和服务器之间知道这段秘钥。

思考：
既然这个非对称加密安全了这么多，为什么还要使用对称加密？
答案是很显然的，非对称加密的计算速度很慢，在传输中需要尽可能的提高传输速度。

这里虽然解决了 对称密钥传输的问题，但是新的问题又来了：
客户端如何获取到公钥？
客户端如何确定这个公钥不是黑客伪造的？

这里就引出了新的概念证书

证书

在介绍证书之前，这里需要先了解一个名词 中间人攻击。

解释中间人攻击

这里通过一个简单的例子进行说明：
大家了解过历史可能都知道。
在二战时期，纳粹德国会将被迫投降的苏军进行专门的间谍培训，利用他们回去刺探苏军的情报，但是很显然很多都是放虎归山，石沉大海。
但是，也会有特殊情况，也会有一些士兵返回带回情报。
实际上这些情报，很多其实都是苏联反间谍机构虚构的，而德国军官却常常信以为真。

这里我们我们会出场这几个角色，士兵，苏联情报部，德国军官 A 和 B。

士兵被派遣到苏联地界，与苏联情报部进行联系，获取到苏联将会集中攻击某地的情报。之后带回到德国前线向此处驻守的两位军官 A 和 B。通报此次苏军行动。
德国军官深信不疑，立即调动军队部署。
殊不知此时的苏军已经从他们的薄弱部分穿插到他们背后了。等待他们的，只有被消灭。

上面的例子中，很明显，这个士兵所充当的位置就是 中间人。
下面我在通过图示解释在传输中，中间人攻击其中的运转：

在这里插入图片描述

对于客户端：客户端并不知道 pub 2 是否真的是从服务器发送过来的公钥。直接就使用了。
对于中间人：黑客通过自己伪造的一对秘钥，通过 pir2 对前面客户端的信息进行解密，就获取到了对称密钥。
再将对称密钥使用得到的 pub1 进行加密，然后在传递回给服务器。
对于服务器：此时服务器收到的仍然是 pub1 加密的对称密钥，使用 pir1 进行解密。之后的交互传输都会使用这个对称密钥。(但是，此时的对称密钥已经泄露了)。

引用证书和说明证书的作用

在上面的解释中，要解决中间人攻击的关键，主要是让客户端要能够辨别，这里的公钥是否是服务器的正确的公钥。

对此，引入 “证书” 就可也解决这个问题。(本质上，证书也就是一个第三方的公证机构)

在网站的建立之初，就需要去专门的认真机构进行证书的申请。通过之后，就会有一个证书。
此时，服务器生成的公钥，就会被包含在这个证书之中了。

在引入证书之后，客户端和服务器之间的联系建立，大致如下图所示：
在这里插入图片描述

关于证书：证书由三部分组成，分别是：字段，公钥，签名。

解释客户端如何通过签名判断判断证书有效：
首先，根据签名。
客户端使用认证机构提供的公钥解密，会得到一个 hash1 值。
第二，根据字段。
客户端使用同样的 hash 算法，针对其余字段再次计算一次 hash 值，得到 hash2 ，此时，当 hash1 = hash2 时，就表明这个证书是没有被篡改的。

对于客户端：在拿到证书后，就会对证书进行校验，证书上会带有特殊字段，叫做证书签名。
对于黑客：
是否可以替换证书提供的公钥？
答案是不行的，一旦替换了公钥，就意味着客户端计算出来的 hash 值是与签名对应的 hash 值是无法对应的，客户端就会知道无效。
是否可以生成一个假签名？
答案也是不行的，黑客并不知道认证机构的私钥，即使算好了一个篡改后的 hash 值，也是无法加密生成签名的。