网络基础「HTTPS」-易微帮

✨个人主页： 北海
🎉所属专栏： Linux学习之旅
🎃操作环境： CentOS 7.6 腾讯云远程服务器

成就一亿技术人

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机构 的公钥对 数字签名 进行解密，获取 数字摘要，同时使用相同的哈希算法，根据证书中的内容，计算出 数字摘要（散列值），与证书中的摘要进行对比，如果摘要一致，就证明证书是正常的，可以使用其中包含的公钥，否则就证明证书已经被篡改过了，拒绝与网站进行连接（拒绝使用 “公钥”）