Java EE 网络原理之HTTPS-编程知识

文章目录

1. HTTPS 是什么？
2. "加密" 是什么？
3. HTTPS 的工作过程
- 3.1 引入对称加密
- 3.2 引入非对称加密
- 3.3 中间人攻击
- 3.4 引入证书
4. Tomecat
- 4.1 tomcat 的作用

1. HTTPS 是什么？

HTTPS也是⼀个应用层协议，是在 HTTP 协议的基础上引⼊了⼀个加密层
HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现⼀些被篡改的情况
比如，臭名昭著的 “运营商劫持”
不止运营商可以劫持，其他的黑客也可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容

在互联网上，明文传输是比较危险的事情
HTTPS 就是在 HTTP 的基础上进行了加密，进⼀步的来保证用户的信息安全

2. “加密” 是什么？

加密就是把明文 (要传输的信息)进行一系列变换，生成密文
解密就是把密文再进行一系列变换，还原成明文

加密解密到如今已经发展成⼀个独力的学科: 密码学
而密码学的奠基⼈，也正是计算机科学的祖师爷之⼀，艾伦·⻨席森·图灵

明文 + 密钥 => 密文
密文 + 密钥 => 密文

在密码学中，使用密钥加密，有两种主要的方式

对称加密（加密和解密，使用的密钥是用一个密钥）
设密钥为 key
明文 + key => 密文
密文 + key => 明文
非对称加密（有两个密钥）
这两个密钥，一个称为“公钥”，一个称为“私钥”
（公钥就是可以公开的，私钥相反）
明文 + 公钥 => 密文
密文 + 私钥 => 明文或者
明文 + 私钥 => 密文
密文 + 公钥 => 明文
（用一个要是加密，就用另一个钥匙解密）

3. HTTPS 的工作过程

既然要保证数据安全，就需要进行 “加密”
网络传输中不再直接传输明文了，而是加密之后的 “密文”
加密的方式有很多，但是整体可以分成两⼤类：对称加密和非对称加密

3.1 引入对称加密

在这里插入图片描述
客户端使用密钥进行对称加密
服务器拿着同一个密钥进行解密
由于黑客手里没有密钥，就无法获取到加密之前的内容

这里只是“比较安全”，网络中不存在“绝对安全”

但是服务器不只是和一个客户端通信，而是和很多客户端通信

这些客户端使用的对称密钥是相同的吗？

很明显，必须要求每个客户端的密钥都不相同，彼此之间才不知道对方的密钥是什么
在这里插入图片描述
此时要求每个客户端对于的密钥都不同
现在就需要每个客户端，载荷服务器建立连接的时候，就把密钥给生成出来
（涉及到一些随机数机制在里面，保证给个客户端生成的密钥都不同）
客户端再把自己的密钥通过网络传输给服务器

但是万一密钥被黑客截获了呢？
在这里插入图片描述
此时，黑客就知道了通信的密钥
后续传输的加缪数据，黑客就可以很轻松的进行解密

如何让密钥更安全的到达服务器呢？
这个时候就需要针对密钥进行加密

这里我们就引入非对称加密

3.2 引入非对称加密

为了解决上述安全传输密钥的问题，引入了“非对称加密”

非对称加密中，有一对密钥，公钥、私钥
可以使用公钥加密，私钥解密
或者使用私钥加密，公钥解密

在这里插入图片描述
服务器生成一对公钥和私钥
服务器把公钥返回给客户端
服务器自身把私钥藏好

但是这个时候黑客也能公钥

客户端仍然生成对称密钥
使用服务器的公钥，对对称密钥进行加密
得到了密钥的密文

如果黑客拿到加密后的对称密钥
是无能为了的，公钥加密需要私钥解密
私钥只有服务器采用，黑客手里没有

服务器手里持有着私钥，服务器就很容易的能解密出对称密钥是什么
于是服务器就得到了原始的对称密钥
接下来客户端和服务器就使用这个对称密钥加密传输即可

既然已经引入了非对称加密，为什么还需要引入对称加密呢?
直接使用非对称加密，来完成所有业务数据的加密传输即可

进行非对称加密/解密，运算成本是比较高的，运算速度也是比较低的
对称加密，运算成本低，速度快

使用非对称加密，只是用来进行这种关键环节(传输密)(一次性的工作，体积也不大)，成本就比较可控
后续要传输大量的业务数据，都使用效率更高的对称加密，比较友好的做法

如果业务数据都使用非对称加密，整体的传输效率就会大打折扣了

引入安全性，引入加密，也势必会影响到传输效率，我们也是希望让这样的影响能尽可能降到最低

3.3 中间人攻击

上述对称加密 + 非对称加密，这样的过程中还存在一个严重的漏洞，黑客如果利用好这个漏洞，仍然可以获取到原始的明文数据
这个漏洞就是“中间人攻击”

在这里插入图片描述

客户端经过入侵的设备向服务器询问密钥
然后服务区就提前生成好了一对公钥（pub1）和私钥（pri1）

服务器就返回 pub1
但是黑客自己生产了一对非对称密钥，其中公钥（pub1），私钥（pub2）

这个时候黑客入侵的设备就返回了 pub2（黑客替换了响应的公钥）

客户端不知道 pub2 是黑客的，一位就是服务器的，于是就使用 pub2 针对堆成密钥进行加密了

黑客收到加密的对称密钥之后
因为这个密钥是使用 pub2 加密的，黑客就可以使用 pri2 进行解密
黑客解密之后，拿到对称密钥
并且使用服务器刚才的 pub2 重新对对称密钥进行加密，进一步的发送给服务器
重新使用 pub1 加密，就是为了不让服务器发现其中的端倪

服务器收到数据之后，使用 pri1 解密，这个解密是完全能够成功的，服务器也收到了对称密钥

这个时候服务器就返回

3.4 引入证书

那么如何解决上述的“中间人攻击呢”？

之所以能进行中间人攻击，关键点在于客户端没有“分辨能力”
客户端不知道当前这个密钥是不是黑客伪造的

这里的“分辨”不能靠“自证”
引入第三方的可以被大家都信任的“公证机构”
公证机构说这个歌密钥是正确的，不是被伪造的，我们就是可以信任的

在这里插入图片描述

网站的开发人员搭建这个服务器的时候，就会生成好公钥私钥（每个客户端都不一样）

服务器就会向公正机构提出申请（提交一些材料，域名、公钥、厂商…）

公正机构就会对这些材料进行审核，审核通过就会给服务器颁发一个 “证书”
（这是计算机的证书，也就是一段结构化的数据，这段数据就会包含一些重要的信息，比如数字签名）

这个时候，就会把证书返回给服务器，服务器也会保存好证书

客户端访问服务器就会直接询问证书

服务器就会向客户端返回证书

客户端拿到证书，也就拿到了证书的公钥
客户端就需要验证这个公钥是否是服务器崔楚的公钥
这个过程，就称为“证书的校验”
校验的核心机制，就是“数字签名”，数组全面就是被加密后的校验和
拿着你数据的每个字节，带入公式，就能算出一个结果数字，称为校验和
把这个数据和校验和一起发送给对方
对方再按照同样的方式再算一遍校验和
如果对方自己算的校验和和收到的校验和一致，就认为数据在传输过程中，没有改变过

颁发证书的时候，公证机构，就会针对整数值的各个属性，计算出一个校验和
并且针对这个校验和进行加密，就得到了数字签名
这个加密也是非对称加密
公正机构，自己生成一对公钥和私钥
公正机构就会自己持有私钥
公钥就会发布给各个客户端设备
（往往公钥都还是内置到系统中的，安装了操作系统，就会自带公证机构的公钥）

公正机构，就会使用自己的私钥，对校验和进行加密，得到数字签名

此时，客户端拿到了数字签名，就可以通过系统内置的公正机构的公钥，进行解密了，就得到了最初的校验和

客户端再重新计算一遍这里的校验和，和解密出来的校验和进行对比
如果校验和一直，就可以认为证书没有得篡改过
公钥就是可信的（服务器原始的公钥）

上述情况之下，黑客就无法对证书内容进行篡改，即使篡改了，也很容易被发现

当黑客收到证书之后，如果直接修改里面的公钥，替换成自己的，客户端在进行证书校验的时候，就会发现校验和不一致了
客户端就可以认为是篡改过了（客户端这边往往会弹出一些对话框来警告用户，粗拿在安全风险）

那么黑客替换公钥只是，能否自己替换到数字签名，自己算一个呢？
这个是不能的，校验和好算，针对校验和加密，需要使用公证机构的私钥，才能进行的
黑客没有这个私钥，如果黑客拿自己的私钥加密，客户端也就无法使用公证机构的公钥解密了
公证机构的公钥是客户端系统自带的，黑客也无法替换

结合上述过程，证书就是可信的，通过了校验，就说明公钥就是服务器原始的公钥了

黑客是否能自己也申请一个证书，完全替换掉，服务器的证书呢?
行不通的，申请证书，需要提交资料
其中就有网站的主域名，认证机构自然就会认证这个域名是否是你所有的