网络基础【HTTPS】

💓博主CSDN主页:麻辣韭菜💓

⏩专栏分类：Linux初窥门径⏪

🚚代码仓库:Linux代码练习🚚

💻操作环境： CentOS 7.6 华为云远程服务器

🌹关注我🫵带你学习更多Linux知识
🔝

1. HTTPS

1.1 什么是加密？

1.2 为什么要加密？

2. 常见的加密方式

2.1 对称加密

2.2 非对称加密

2.3 数据摘要&&数据指纹

2.4 数字签名

3. 加密方案

3.1 对称加密方案

3.2 非对称加密方案

3.3 对称加密 + 非对称加密

4. 引入证书

4.1 CA证书

4.2 在加入CA证书的情况下遇到 MITM 攻击

4.2.1 情况一

4.2.2 情况二

4.2.3 情况三

4.2.4 情况四

最终方案

1. HTTPS

我们前面通过实验在HTTP中不管是URL传输数据，还是通过正文方式，都是明文传输的。这就导致了中间人都能拿到报文，对报文进行修改。安全的问题非常明显。

基于这样背景诞生了 HTTPS，HTTPS是在HTTP基础上引入一个加密层。

1.1 什么是加密？

在上面的网络协议栈示意图中，报文层层向下交付，到了传输层和网络层这里就有一个问题。 传输层和网络层属于OS，但是人家OS没有义务给你添加加密算法。下三层人家解决的是数据如何传输的问题。

所以我们的请求和响应要想不被中间人拿到，需要在应用层添加加密解密层。

以前是直接发给OS ，现在有了加密解密层，HTTP的报文先发给加密解密层，然后加密解密层发给OS。给报文加密就变成了密文，给密文解密还原成明文。加密也是需要其他的数据来辅助的，而这部分辅助的数据叫做密钥。对于服务器来说也是一样！这就是HTTPS

那这个SSL 是程序员自己定制吗？

有公司专门来定制网络安全协议。但是话说，任何网络安全协议都是基于当下是安全的。

为什么这么说？

如果攻破的成本大于攻破收益，那么就是安全的。反之就是不安全因为随着计算机硬件的发展算力得到提升，攻破都是迟早得事。这个世界没有一劳永逸得事！

1.2 为什么要加密？

前面说过不加密我们报文就是明文，中间人拿到报文做修改，就比如说我们在浏览器中下载东西，最后安装完毕才发现不是自己要下载的软件。

以前是直接下载链接被篡改成其他软件的下载链接，现在是先下什么最后才是你想要下的。

2. 常见的加密方式

2.1 对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，

特征：加密和解密所用的密钥是相同的。

常见对称加密算法

AES（高级加密标准）：目前最流行的对称加密算法，支持128、192和256位的密钥长度。
DES（数据加密标准）：较老的加密标准，已被AES取代，只有56位有效密钥长度，容易受到暴力破解攻击。
3DES：基于DES，使用三个56位的密钥，更加安全，但现在逐渐被AES取代。
Blowfish：一种替代DES的加密算法，支持不同长度的密钥。

优点：

速度：对称加密算法比非对称加密算法要快很多，适合大量数据的加密。
资源效率：由于算法简单，计算成本低。

缺点：

密钥分发：必须安全地交换密钥，如果密钥泄露，通信的安全性会受到威胁。
密钥管理：随着参与通信的用户数量增加，密钥管理变得更加复杂。

2.2 非对称加密

需要两个密钥来进行加密和解密，这两个密钥是 公开密钥（简称公钥）和 私有密钥 （简称私钥）。

常见非对称加密算法： RSA DSA ECDSA

特点：算法强度复杂，安全性依赖于算法于密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

公钥和私钥是配对的，最大的缺点就是运算速度慢。比对称加密要慢很多。

通过公钥对明文加密，变成密文
通过私钥对密文解密，变成明文

也可以反着用

通过私钥对明文加密，变成密文
通过公钥对密文解密，变成明文

2.3 数据摘要&&数据指纹

数字摘要 又称为 数字指纹，指通过哈希函数对信息进行运算后生成的一串定长字符串，具有很强的唯一性，数字摘要 并不能加密，而是用于快速判断原始内容是否被修改

摘要常见算法：MD5 SHA1 SHA256 SHA512 等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

摘要的特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来数据对比。

2.4 数字签名

数字摘要经过加密就得到了数字签名

3. 加密方案

当我们有了 对称加密、非对称加密、数据摘要、数字签名 相关概念对HTTP协议进行升级

3.1 对称加密方案

密钥都是同一把那么意味着客户端的其他人当中间人，也是可以拿到报文的。就算客户端的人没有坏人，但是密钥本身就是明文的 中间人也是可以拿到密钥的。

这里关于密钥的产生有两种方案：

服务器生成，客户端生成。

如果是客户端生成无疑是加大了服务器的负担，对每个客户的密钥要进行增删改查。

但是的但是不管是哪一种方案密钥本身就是明文传输的。有人说对密钥也进行加密，如果是这样就变成了先有鸡还是先有蛋的问题了，一直死循环走不出来。

密钥在传输过程中，有可能被 “劫持”

由此对称加密也不是安全的。

3.2 非对称加密方案

既然对称加密不是安全的，毕竟加密和解密都是用的同一个密钥，那我们使用非对称加密 密钥是两个一个公钥一个私钥

只有服务器使用非对称加密

服务器 生成公钥和密钥

把公钥交给客户端

使用公钥和私钥进行加密与解密，也可以使用私钥和公钥进行加密与解密

我们先说使用公钥和私钥进行加密与解密的方案

利用这种方式虽然客户端数据经过公钥加密 变成密文，发给服务器，这个过程是安全的。毕竟只有服务器有私钥。

但是的但是，服务器发过来的密文可是用私钥加密的，那么公钥就可以解密。而公钥又是公开的，所以中间人攻击一样也能拿到服务器响应的报文。

只有服务器使用非对称加密方案还是不安全

那我们让服务器和客户端都使用非对称加密。

双方都使用 公钥加密 和 私钥解密。

这一样一看感觉是无懈可击，安全的很。但是这样真的就是安全的吗？

如果中间人攻击，自己也有公钥和私钥？

这时我们假设一下客户端和服务器 交换公钥 ，这时中间人攻击劫持它们各自的公钥，中间人把 自己的公钥 给了服务器和客户端。

这时公钥被偷梁换柱了，客户端和服务器双方浑然不知。

那么不管是服务器还是客户端，它们对明文利用公钥进行加密，用的都是中间人的公钥。所以双方的密文在中间人这里就明文。然后中间人获取到信息后，在用它们各自的公钥加密发送给客户端和服务器双方。

抛开安全性不说，就双方都使用非对称加密，效率非常低下。

非对称加密算法强度高，加密与解密时间长
客户端与服务器都需要存储并管理彼此的公钥，非常麻烦

这种攻击方式常见吗？
非常常见，且容易上当，可能仅仅是连接一个公共环境下的免费WIFI，亦或是无名基站，个人信息就有可能会泄漏，无论是「对称式加密」、「非对称式加密」，还是后面的「非对称式加密」+「对称式加密」，都无法避免中间人攻击

3.3 对称加密 + 非对称加密

中间人攻击现在还无法解决，但可以解决使用非对称式加密时的效率问题

服务器先将公钥交给客户端

客户端使用公钥加密密钥后，交给服务器

因为此时密钥是使用服务器的公钥加密的，只能使用服务器的私钥解密，所以确保了密钥传输的安全性

后续直接使用密钥进行加密与解密

这种解决方案首先使用非对称式加密保证了 密钥传输时的安全性，确保只有客户端和服务器拥有密钥，因为密钥加密与解密的特点就是 效率高，所以后续在传输数据时，整体效率就会高很多

然而这种方式也是不安全的

上面提出的几种解决方案都存在一个致命问题：客户端和服务器在进行第一次交流时，并不认识对方

这就导致无论是传递公钥还是传递密钥，都无法确保最终到达对端手里的钥匙是正确的，也就给中间人制造了一个攻击的好机会

中间人劫持到服务器公钥后，将自己的公钥交给客户端

中间人通过自己的私钥成功解密了客户端的密文，获取了密钥，然后使用服务器公钥重新加密后，将密钥交给服务器

宏观上来看，客户端和服务器获取了唯一的密钥，但实际上中间人已经劫持到了密钥，后面传输数据时，中间人可以轻易解密，获取信息

被攻击的核心原因：客户端无法验证公钥的合法性（客户端不认识服务器），此时就需要一个公平公正的第三方机构来进行认证，确保客户端所连接的服务器是合法的

4. 引入证书

4.1 CA证书

在今天，如果想使用 HTTPS 协议，服务器就需要向 CA机构 申请一份 CA证书，证书就如同该服务的身份证，其中包含了 证书申请者信息、公钥信息 等重要信息，服务器在成功申请到证书后，就会将证书交给客户端（也就是浏览器），以进行证书认证和获取公钥

CA证书 中有该证书的 数字签名，是由 CA机构 使用自己的私钥进行加密而形成的密文，其他人都无法进行签名，至于 CA机构 的公钥，一般浏览器出厂就已经进行了内置

当客户端获取到服务器的 CA证书 后，会使用 CA机构 的公钥对 数字签名 进行解密，获取 数字摘要，同时使用相同的哈希算法，根据证书中的内容，计算出 数字摘要（散列值），与证书中的摘要进行对比，如果摘要一致，就证明证书是正常的，可以使用其中包含的公钥，否则就证明证书已经被篡改过了，拒绝与网站进行连接（拒绝使用 “公钥”）