文章目录

前言
一、认识 HTTPS 协议
- 1, 对称加密
- 2, 非对称加密
二、HTTPS 加密策略
- 1, 只采用对称加密 : 不安全
- 2, 引入非对称加密
- 3, 中间人攻击之偷梁换柱
- 4, 引入证书
- - 4.1 什么是证书
  - 4.2, 证书如何能解决"中间人攻击"
总结

前言

各位读者好, 我是小陈, 这是我的个人主页, 希望我的专栏能够帮助到你:
📕 JavaSE基础: 基础语法, 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
📗 Java数据结构: 顺序表, 链表, 堆, 二叉树, 二叉搜索树, 哈希表等
📘 JavaEE初阶: 多线程, 网络编程, TCP/IP协议, HTTP协议, Tomcat, Servlet, Linux, JVM等(正在持续更新)

上篇文章介绍了如何构造一个 HTTP 请求, 本篇主要介绍关于 HTTPS 加密的的相关知识在这里插入图片描述

提示：是正在努力进步的小菜鸟一只，如有大佬发现文章欠佳之处欢迎批评指点~ 废话不多说，直接上干货！

一、认识 HTTPS 协议

目前绝大部分网站都使用了 HTTPS 协议, HTTPS 可以理解为在 HTTP 协议的基础上, 增加了一个加密层

正由于 HTTP 协议内容都是按照文本的方式明文传输的, 这就导致在传输过程中出现一些被篡改的情况, 比如被黑客盗取传输信息, 运营商劫持等等

HTTPS 就是尽可能确保互联网上的数据传输的安全性, 设计了加密机制

加密已经发展成复杂的, nb 的 “密码学”, 本篇不介绍具体的加密算法, 只介绍策略

加密 : 明文, 通过一些复杂的数学算法(密匙) --> 密文
解密 : 密文, 通过一些复杂的数学算法(密匙) --> 明文

1, 对称加密

简单来说 : 加密的密钥和解密的密钥是同一个, 所以采用对称加密, 密钥既能加密也能解密

我们把对称密钥称为 Key :

加密 : 明文通过 Key --> 密文
解密 : 密文通过 Key --> 明文

2, 非对称加密

简单来说 : 有两把密匙, 一把对外公开的公钥, 一把不对外公开的私钥, 公钥和私钥配对, 公钥用来加密, 私钥来解密

我们把公钥称作 publicKey, 私钥称作 privateKey

加密 : 明文通过 publicKey --> 密文
解密 : 密文通过 privateKey --> 明文

注意 : 公钥和私钥是配对的, 也是相对的!!! 这两把密匙, 都可以用来加密或者解密, 完全可以使用私钥加密, 使用公钥解密, 只是把用来加密的密钥公开, 用来解密的密钥私有, 这才有了公钥私钥之分

非对称加密的好处就是 : 即便别人知道我加密的方式, 也不能解密, 只能干瞪眼!!, 因为解密需要私钥啊, 私钥是我私藏的, 只有我知道

但坏处是 : 由于公钥私钥设计成配对的, 导致加密解密时运算复杂, 比较耗时

二、HTTPS 加密策略

接下来, 我们层层递进的分析 HTTPS 如何尽可能保证数据安全

1, 只采用对称加密 : 不安全

我们把对称密钥称为 Key :

加密 : 明文通过 Key --> 密文
解密 : 密文通过 Key --> 明文

使用对称加密的方式传输密文 :

在这里插入图片描述

这样即便是中间有黑客, 黑客截取到了数据, 如果没有拿到密钥 Key, 也无法解密, 但同理, 服务器如果没有拿到密钥 Key, 服务器也无法解密

所以在此之前, 客户端要先把 Key 传给服务器

对称加密的密钥 Key, 是客户端生成的, 因为一个服务器可能要和无数个客户端通信, 每个客户端的密钥 Key 都不能相同, 这就需要客户端自己生成自己的密钥 Key

在这里插入图片描述
这样确实是把 Key 告知给服务器了, 接着再传输密文, 服务器就可以解密了, 但同理黑客也知道了 Key ! 黑客也能解密 ! ! 因为 Key 是明文传输的 ! !

那咋办呢? 想让客户端知道 Key, 又不想让黑客知道, 难道再生成一个 Key2, 用 Key2 加密 Key 吗? 如果可以, 那 Key2 怎么传输? 显然这是套娃

所以此路不通, 问题是Key 无法安全传输, 这就需要引入非对称加密 ! !

2, 引入非对称加密

我们把公钥称作 publicKey, 私钥称作 privateKey

加密 : 明文通过 publicKey --> 密文
解密 : 密文通过 privateKey --> 明文

对称密钥 Key 是客户端生成的, 非对称密钥是服务器生成的(公钥对外公开, 私钥只有服务器自己知道)

非对称加密可以做到客户端安全的传输 Key , 不被黑客截取 ! !

在这里插入图片描述

首先, 客户端有一个对称密钥 Key, 服务器有一对儿非对称密钥 publicKey 和 privateKey

1, 客户端获取 publicKey

在这里插入图片描述
黑客没拿到有用的信息, 只能转发消息

2, 服务器返回 publicKey

在这里插入图片描述
客户端收到信息, 拿到了 publicKey , 但黑客也拿到了

3, 客户端使用非对称加密传输 Key

在这里插入图片描述
注意 ! ! !
此时 Key 不再是明文传输了, 而是被服务器的 publicKey 加密了, 即便黑客截取了这个被加密的 Key, 也不能解密, 因为解密需要与 publicKey 配对的 privateKey ! ! 所以即便刚刚黑客截取了服务器发给客户端的 publicKey 也无用武之地

黑客没有 privateKey, 客户端也没有, 除了服务器之外的任何一台主机都没有 ! ! 所以只有服务器(使用 privateKey 解密之后)知道客户端的对称密钥 Key 是什么

4, 客户端使用对称加密传输数据

在这里插入图片描述
服务器拿到 Key 之后, 后续客户端通过 Key 加密数据, 服务器自然也可以使用 Key 解密

综上所述,
1, 原本客户端只有 Key, 服务器只有 publicKey 和 privateKey, 但最后客户端拿到了对方的 publicKey, 服务器安全的拿到了对方的 Key
2, 非对称加密传输 Key, 对称加密传输数据报, 因为非对称加密比较费时, 只使用一次就可以后续安全地频繁使用性能更高地加密方式

但是, 这就万事大吉了吗? 黑客也有"骗"的方式

3, 中间人攻击之偷梁换柱

起初还是客户端有一个对称密钥 Key, 服务器有一对儿非对称密钥 publicKey 和 privateKey

1, 客户端获取 publicKey

在这里插入图片描述
黑客没拿到有用的信息, 只能转发消息

2, 服务器返回 publicKey, 黑客偷梁换柱 ! !

在这里插入图片描述
当黑客拿到了服务器打算发给客户端的 publicKey 之后, 黑客做坏事了 : 自己生成了一对 publicKey 和 privateKey, 把自己的 publicKey 发给客户端, 让客户端以为黑客的 publicKey 就是服务器发给他的 publicKey

在这里插入图片描述

此时黑客手上有三把密匙 : 自己的 publicKey , privateKey, 和服务器的 publicKey

3, 客户端使用非对称加密传输 Key

在这里插入图片描述
客户端完全不知道发生了什么, 使用黑客的 publicKey 加密 Key 传输给服务器, 被黑客拦截后, 黑客可以使用自己的 privateKey 解密, 从而盗取 Key

如果原封不动的转发给服务器, 服务器无法解密了(因为不是使用服务器的 publicKey 加密的, 服务器的 privateKey 就用不了)

为了防止服务器发现异常, 黑客就要把 Key 使用服务器的 publicKey 加密, 发给服务器

在这里插入图片描述

此时黑客手上有四把密匙 : 自己的 publicKey , privateKey, 服务器的 publicKey, 和客户端的对称密钥 Key

4, 客户端使用对称加密传输数据

在这里插入图片描述

由于黑客已经有了对称密钥 Key, 等客户端傻呵呵的发来了使用 Key 加密的密文, 黑客也能解开, 从而盗取数据

上述过程, 被称作中间人攻击
1, 黑客骗过了客户端, 让客户端以为自己的 publicKey 就是服务器的 publicKey, 所以黑客才能盗取客户端的 Key, 其实本质就是黑客冒充了服务器的身份
2, 自始至终, 客户端都没能拿到服务器的 publicKey

解决中间人攻击的方式也很简单, 在客户端拿到 publicKey 的时候, 必须要让客户端信任这个 publicKey 是正品, 然后才能把自己的对称密钥 Key 交出去

4, 引入证书

4.1 什么是证书

服务器要想支持 HTTPS 协议, 就要找到证书颁布机构申请一个证书, 证书不是实体的, 可以理解成一个结构化的字符串, 里面包含了以下信息 :

证书发布机构
证书有效期
证书所有者
证书所有者的公钥
加密的签名(除了这个, 其他的字段都是明文的)
…

签名就是一个"校验和", 针对证书中的各种字段, 使用特殊的算法得出一个值, 然后再用证书颁布机构的私钥对签名加密

证书颁布机构也有一对公钥和私钥, 任何一个正经的主机的操作系统中都内置了机构的公钥

上面说过, 公钥可以加密, 私钥解密, 也可以私钥加密, 公钥解密, 只是对外公开的称作公钥

在浏览器 – 设置 – 搜索"证书" – 证书管理 :

在这里插入图片描述

4.2, 证书如何能解决"中间人攻击"

客户端可以通过以下方式判断证书是不是"正品" :

证书的有效期是否过期
证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)
证书是否被篡改 : 客户端从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 这是机构已经算好的, 设为 hash1. 然后客户端使用相同的算法, 计算整个证书的 hash 值, 设为 hash2, 这是客户端自己算的. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的

在这里插入图片描述

有了证书之后, 客户端直接向服务器索要证书即可, 因为证书里包含服务器的私钥

**加粗样式**

黑客要是还想再用刚才的方式"偷梁换柱", 就不行了, 因为客户端首先能看到的就是黑客发来的 publicKey 和证书里的 publicKey 不一样

黑客能不能篡改证书里的 publicKey, 篡改证书所有者呢?

证书本质就是个字符串, 黑客当然可以把篡改字符串里的值, 黑客的操作系统中也有机构的公钥, 所以也可以轻松的把加密的签名使用发布机构的公钥解密, 然后篡改签名
但是黑客无法再针对篡改后的签名加密, 因为黑客没有发布机构的私钥 ! !, 这一步做不到, 签名的值就无法真正的被修改, 即便改了其他字段, 等到客户端自己校验的时候就会发现不对劲

所以黑客完全能看到证书里的所有信息, 但是改不了, 无能为力, 只能干瞪眼