✨个人主页： 北 海
🎉所属专栏： Linux学习之旅
🎃操作环境： CentOS 7.6 腾讯云远程服务器
文章目录
- 1.基本概念
- 1.1.HTTP协议面临的问题
- 1.2.加密与解密
- 1.3.数字摘要
- 1.4.数字签名
- 2.解决方案
- 2.1.「对称式加密」
- 2.2.「非对称式加密」
- 2.3.「非对称式加密」+「对称式加密」
- 2.4.存在的安全问题
- 3.引入证书
- 3.1.CA证书
- 3.2.在加入CA证书的情况下遇到 MITM 攻击
- 3.2.1.情况一
- 3.2.2.情况二
- 3.2.3.情况三
- 3.2.4.情况四
- 最终方案
- 3.3.「非对称式加密」+「对称式加密」+「CA证书」
- 3.4.补充
1.基本概念
1.1.HTTP协议面临的问题
在使用 HTTP 协议传递参数时，无论是 GET 方法，还是 POST 方法，都是不安全的，可以使用抓包工具抓取到敏感信息
这也就意味着在涉及敏感信息时， HTTP 协议不可取，需要使用一个更加安全的协议，于是基于 SSL/TLS 加密协议的 HTTPS 协议就诞生了
SSL/TLS是用于加密和保护网络通信的协议。它们用于确保在互联网上传输的数据在传输过程中是安全的，并且不能被未经授权的人读取或篡改。SSL是TLS的前身，TLS实际上是SSL的后续版本
1.2.加密与解密
首先需要简单了解一下 加密与解密 的概念
- 加密：把明文经过一系列变换，形成密文
- 解密：把密文经过一系列变换，还原成明文
明文就是我们能看懂的信息，比如这篇博客现在就是以明文的形式显示的，但如果我将其变为火星文，所有人都看不懂，那它就变成密文了
在加密与解密的过程中需要一个或者多个辅助数据，我们将其称为 「密钥」
加密是上锁，解密就是开锁，无论是上锁还是解锁，都需要钥匙，也就是「密钥」
常见的加密方式有以下两种：
- 对称式加密：采用单密码系统的加密方法
- 特点：算法公开、计算量小、加密速度快、加密效率高
- 非对称式加密：需要使用两个密码，分别是公开密钥（公钥）和私有密钥（私钥），用公钥加密，只能用私钥解密，用私钥加密，只能用公钥解密
- 特点：算法强度复杂、安全性依赖于算法与密钥、加密和解密的速度比较慢
注意： 使用公钥加密，只能使用私钥解密；使用私钥加密，只能使用公钥解密
为什么需要加密？
首先是因为信息都是以 明文 的形式传输的，难免会遇到坏人收集个人信息，其次是可能存在运营商劫持等安全问题，个人信息容易泄漏，所以才需要对信息加密，保护隐私
关于解密
在计算机领域存在一位大神：艾伦·麦席森·图灵，不仅精通计算机，还精通密码学，他在二战期间破译了德军的密码系统，加速了二战胜利的进程，后来人们为了纪念他，以他的名字命名了计算机领域的最高奖项：「图灵奖」
1.3.数字摘要
数字摘要 又称为 数字指纹，指通过哈希函数对信息进行运算后生成的一串定长字符串，具有很强的唯一性，数字摘要 并不能加密，而是用于快速判断原始内容是否被修改
这种技术还可以用于网盘存储中，比如xxx网盘中就有一个 “秒传功能”，可以快速上传目标文件，其实就是根据用户上传的文件生成了 数字摘要，将该摘要与服务器中已经记录好的摘要信息进行对比，如果发现该摘要，就证明服务器中已经存在这个文件了，无需再重复上传，只需要在用户的上传目录中建立目标文件的软链接或者硬链接，就可以实现 “秒传”
1.4.数字签名
数字签名 是指将 数字摘要 通过加密后得到的字符串，计算过程需要借助 密钥
为什么不直接对原始内容进行加密后得到 数字签名？
因为在经过哈希函数后，会得到一串定长且唯一的字符串，更适合进行加密计算
现在已经有了 加密与解密、加密方式、数字摘要、数字签名 的相关概念了，可以对 HTTP 协议进行升级了
2.解决方案
2.1.「对称式加密」
对称加密是指双方使用同一个 密钥，对原始内容进行 加密和解密
使用 密钥 进行加密与解密
对称式加密的优点是：算法公开、计算效率高，现在问题在于如何让客户端与服务器持有同一个 密钥
- 方案A：服务器生成密钥后传递给客户端
- 方案B：客户端生成密钥后传递给服务器
首先说说方案A，如果存在很多个客户端，那么它们使用的密钥就都是一样的，可以相互解密，倘若这些客户端中存在坏人，那整个加密方式都会失效；其次是传递密钥时是 明文传输，即便客户端中没有坏人，也可能遭到中间人劫持，泄漏密钥
其次是方案B，如果存在很多客户端，每个客户端都给服务器传递一个密钥，意味着服务器要对【客户端，密钥】这组关系进行维护，虽然此时每个客户端都有自己的密码，在一定程度上保证了加密的唯一性，但对关系的维护无疑会增加服务器的负担；同样必须通过 明文传输，中间人劫持也是无法避免的
客户端将 密钥 交给服务器
密钥 在传输过程中，有可能被 “劫持”
在只使用「对称式加密」的情况下，存在很大的安全漏洞，可以说这种方法在实际中几乎无法使用
2.2.「非对称式加密」
非对称式加密指存在一个 公钥 和 一个 私钥，公钥加密，只能使用私钥解密；私钥加密，只能使用公钥解密
首先来看看只有服务器使用非对称式加密的情况
服务器将 公钥 交给客户端
使用 公钥 和 私钥 进行加密与解密，也可以使用 私钥 和 公钥 进行加密与解密
此时服务器中存在 公钥 与 私钥，凡是与服务器进行连接的客户端，都可以得到服务器的 公钥，因为此时只有服务器使用非对称式加密，所以后续无论有多少客户端连接，服务器都只需要使用自己的 公钥 与 私钥，私钥只有服务器自己持有
服务器在传递 公钥 时，仍然是使用 明文传输，坏人仍然能获取 公钥，当客户端使用 公钥 加密原始内容后，只有服务器能解密，因为 使用公钥加密，只能使用私钥解密，数据传输安全，但如果是服务器使用 私钥 加密原始内容后，凡是持有 公钥 的客户端都能进行解密，这是比较危险的
再来看看客户端、服务器都使用非对称式加密的情况
服务器与客户端交换 公钥
在交换公钥之后，无论是客户端还是服务器，在进行加密时，都是使用对方的 公钥 进行加密，确保只有对方的 私钥 能进行解密，这种方法确保了 加密与解密 的唯一性，能有效的确保安全，但这样做面临着很严重的效率问题：
- 非对称加密算法强度高，加密与解密时间长
- 客户端与服务器都需要存储并管理彼此的公钥，非常麻烦
这样做就一定安全吗？当然不是，中间人攻击了解一下
中间人有自己的 公钥 和 私钥，当客户端与服务器交换 公钥 时，中间人劫持它们的 公钥，并将自己的 公钥 交给它们，让它们误以为已经完成了交换；后续在进行加密时，无论是客户端还是服务器，都是在使用中间人的 公钥 进行加密，当密文来到中间人手里时，中间人可以使用自己的 私钥 解密，获取到信息后，再使用 客户端/服务器 的 公钥 进行加密，重新发送给它们
如此一来，客户端和服务器以为自己的密文是不可能被他人破解的，但实际上密文已经被偷梁换柱了
下面开始表演 “偷梁换柱”
这种攻击方式常见吗？
非常常见，且容易上当，可能仅仅是连接一个公共环境下的免费WIFI，亦或是无名基站，个人信息就有可能会泄漏，无论是「对称式加密」、「非对称式加密」，还是后面的「非对称式加密」+「对称式加密」，都无法避免中间人攻击
2.3.「非对称式加密」+「对称式加密」
中间人攻击现在还无法解决，但可以解决使用非对称式加密时的效率问题
首先服务器使用非对称式加密，将公钥交给客户端，然后客户端使用公钥加密，传输密钥，后续在传递信息时，使用密钥进行加密与解密
服务器先将 公钥 交给客户端
客户端使用 公钥 加密 密钥 后，交给服务器
因为此时 密钥 是使用服务器的 公钥 加密的，只能使用服务器的 私钥 解密，所以确保了 密钥 传输的安全性
后续直接使用 密钥 进行加密与解密
这种解决方案首先使用非对称式加密保证了 密钥传输时的安全性，确保只有客户端和服务器拥有 密钥，因为 密钥 加密与解密的特点就是 效率高，所以后续在传输数据时，整体效率就会高很多
然而这种方式也是不安全的
2.4.存在的安全问题
上面提出的几种解决方案都存在一个致命问题：客户端和服务器在进行第一次交流时，并不认识对方
这就导致无论是传递 公钥 还是传递 密钥，都无法确保最终到达对端手里的 钥匙 是正确的，也就给中间人制造了一个攻击的好机会
中间人劫持到服务器 公钥 后，将自己的 公钥 交给客户端
中间人通过自己的 私钥 成功解密了客户端的密文，获取了 密钥，然后使用服务器 公钥 重新加密后，将 密钥 交给服务器
宏观上来看，客户端和服务器获取了唯一的 密钥，但实际上中间人已经劫持到了 密钥，后面传输数据时，中间人可以轻易解密，获取信息
被攻击的核心原因：客户端无法验证公钥的合法性（客户端不认识服务器），此时就需要一个公平公正的第三方机构来进行认证，确保客户端所连接的服务器是合法的
3.引入证书
3.1.CA证书
在今天，如果想使用 HTTPS 协议，服务器就需要向 CA机构 申请一份 CA证书，证书就如同该服务的身份证，其中包含了 证书申请者信息、公钥信息 等重要信息，服务器在成功申请到证书后，就会将证书交给客户端（也就是浏览器），以进行证书认证和获取 公钥
CA证书 中有该证书的 数字签名，是由 CA机构 使用自己的 私钥 进行加密而形成的密文，其他人都无法进行签名，至于 CA机构 的 公钥，一般浏览器出厂就已经进行了内置
当客户端获取到服务器的 CA证书 后，会使用 CA机构 的 公钥 对 数字签名 进行解密，获取 数字摘要，同时使用相同的哈希算法，根据证书中的内容，计算出 数字摘要（散列值），与证书中的摘要进行对比，如果摘要一致，就证明证书是正常的，可以使用其中包含的 公钥，否则就证明证书已经被篡改过了，拒绝与网站进行连接（拒绝使用 “公钥”）
也就是说，之前单纯的传输服务器 公钥，变成了传输 CA证书，这样是否防止中间人攻击呢？
3.2.在加入CA证书的情况下遇到 MITM 攻击
3.2.1.情况一
中间人在劫持到 CA证书 后，什么都不做，转交给客户端
结果：没有丝毫影响，CA证书仍然是正常的，同时中间人也没有获取到任何信息
3.2.2.情况二
中间人在劫持到 CA证书 之后，更改其中的 公钥 信息，改为自己的 公钥
结果：客户端根据 CA证书 内容进行哈希计算后，得出的 数字摘要 与 CA证书 自带的 数字摘要 并不相同，认为该证书失效，不使用
3.2.3.情况三
中间人认为情况二失败的关键在于 摘要不一致，于是中间人在修改 公钥 的同时，修改了 数字摘要，并自己生成了一份 数字签名
结果：客户端无法使用 CA公钥 解密签名，因为这个签名非法
注意： 私钥加密，需要使用公钥解密，但 CA机构 的私钥只有它们自己拥有
3.2.4.情况四
中间人气急败坏，既然假证书不行，那就直接向 CA机构 申请一份证书，内容为自己的 公钥，即便它能申请到 CA证书，客户端在读取证书内容后，也会立马将证书丢弃，因为证书中包含了服务器的信息，客户端能轻而易举的发现当前证书中的服务器与自己想访问的目标服务器信息不一致
结果：客户端识别出证书不是自己想要的，丢弃证书，拒绝连接
需要明白的是，证书申请比较麻烦，并且证书是有使用时限的，一旦过期，就需要重新申请，这就保证了合法的证书是可靠的，可以根据其中的内容判断是否丢弃
最终方案
3.3.「非对称式加密」+「对称式加密」+「CA证书」
在「非对称式加密」+「对称式加密」的基础上，引入「CA证书」，确保客户端获取到的是安全、可靠的 公钥，再使用该 公钥 加密 密钥，形成密文，该密文只能由服务器使用自己的 私钥 解密，获取 密钥，进行数据传输
只要公钥是安全可靠的，那么服务器在收到密文时，得到的密钥也是安全可靠的
客户端通过 CA证书 获取到服务器的 公钥
使用 公钥 向服务器发送 密钥
双方使用 密钥 进行数据传输
有了「非对称式加密」+「对称式加密」+「CA证书」的解决方案，可以充分保证我们在上网冲浪时的安全性，这也就是为什么大多数钓鱼网站仍在使用
HTTP协议，因为这样可以跳过整个安全检测方案
证书 扮演着重要角色，在访问那些 证书 过期，或者是没有 证书 的网站时需要提高警惕
3.4.补充
如何成为中间人？
ARP 欺骗、ICMP 攻击、假 WIFI、假网站
HTTPS 工作过程涉及到的三组密钥
第一组（非对称）：CA 私钥加密后将证书颁发给服务器，CA 公钥公开
第二组（非对称）：服务器把证书发送给客户端，其中包含了服务器的公钥，客户端（浏览器）中内置 CA 公钥，解密验证摘要合法后，客户端获取服务器公钥
第三组（对称）：客户端将自己的密钥通过服务器公钥加密后，发给服务器，此时只有服务器能解密
相关文章推荐
网络基础「HTTP」
网络基础『 序列化与反序列化』
网络编程『简易TCP网络程序』
网络编程『socket套接字 ‖ 简易UDP网络程序』
网络基础『发展 ‖ 协议 ‖ 传输 ‖ 地址』
