[Linux网络基础——Lesson6.「HTTPS」]

前言

[3.2.在加入CA证书的情况下遇到 MITM 攻击](#3.2.在加入CA证书的情况下遇到 MITM 攻击)

3.3.「非对称式加密」+「对称式加密」+「CA证书」

3.4.补充

前言

数据传输安全性是网络应用的核心支撑，而HTTP协议因设计缺陷，存在窃听、篡改、伪造等固有风险，无法满足隐私传输、金融支付等场景需求。为解决这一问题，加密、数字摘要、数字签名等技术逐步应用，其中对称与非对称加密的结合实现了安全性与效率的初步平衡，但身份认证缺失导致中间人攻 击（MITM）等威胁仍存。

CA证书的引入填补了身份认证空白，通过第三方权威背书构建信任体系。本文将从基础概念出发，剖析各类加密方案优劣，详解CA证书抵御中间人攻击的机制，最终提炼完整安全解决方案，为理解网络安全传输逻辑提供核心指引。

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 协议的安全问题为切入点，层层递进地梳理了网络数据传输安全的解决方案演进历程，核心内容提炼总结如下：

基础概念铺垫 ：HTTP 协议存在数据窃听、篡改、身份伪造等固有安全缺陷，而加密与解密是保障数据机密性的核心手段，数字摘要实现了数据完整性校验，数字签名则同时解决了身份认证与抗抵赖问题，三者共同构成了网络安全的技术基础。

加密方案演进：对称式加密加密解密效率高，但密钥分发与管理困难；非对称式加密解决了密钥传输问题，却存在加密速度慢的短板；二者结合的混合加密方案，兼顾了安全性与传输效率，成为数据传输的常用加密方式，但仍未解决身份认证的核心漏洞。

CA 证书补全安全闭环 ：针对混合加密方案面临的中间人攻击风险，CA 证书通过权威第三方机构颁发，为通信双方提供了可信的身份认证依据。文中详细分析了加入 CA 证书后抵御不同类型中间人攻击的场景，验证了其在身份核验中的关键作用。

最终安全方案 ："非对称式加密 + 对称式加密 + CA 证书" 的组合方案，整合了三类技术的优势 ------ 非对称式加密用于安全传输对称密钥，对称式加密保障数据传输效率，CA 证书实现可信身份认证，三者形成闭环，彻底解决了 HTTP 协议面临的机密性、完整性、身份认证和抗抵赖四大安全问题，为 HTTPS 等安全协议的实现奠定了核心基础。此外，补充内容进一步完善了方案的实用性与场景适配性，让整个安全体系更加完整。