网络基础 【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 非对称加密方案

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

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

服务器 生成公钥和密钥 

把公钥交给客户端

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

3.3 对称加密 + 非对称加密

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

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

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

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

 

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

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

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

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

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

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

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

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

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

4. 引入证书 

4.1 CA证书

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

 

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

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

也就是说，之前单纯的传输服务器 公钥，变成了传输 CA证书，这样是否防止中间人攻击呢？ 

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

4.2.1 情况一

中间人在劫持到 CA证书 后，什么都不做，转交给客户端 

 结果：没有丝毫影响，CA证书仍然是正常的，同时中间人也没有获取到任何信息

 4.2.2 情况二

中间人在劫持到 CA证书 之后，更改其中的 公钥 信息，改为自己的 公钥 

 结果：客户端根据 CA证书 内容进行哈希计算后，得出的 数字摘要 与 CA证书 自带的 数字摘要 并不相同，认为该证书失效，不使用

4.2.3 情况三 

中间人认为情况二失败的关键在于 摘要不一致，于是中间人在修改 公钥 的同时，修改了 数字摘要，并自己生成了一份 数字签名 

结果：客户端无法使用 CA公钥 解密签名，因为这个签名非法

注意： 私钥加密，需要使用公钥解密，但 CA机构 的私钥只有它们自己拥有

4.2.4 情况四 

中间人气急败坏，既然假证书不行，那就直接向 CA机构 申请一份证书，内容为自己的 公钥，即便它能申请到 CA证书，客户端在读取证书内容后，也会立马将证书丢弃，因为证书中包含了服务器的信息，客户端能轻而易举的发现当前证书中的服务器与自己想访问的目标服务器信息不一致 

 结果：客户端识别出证书不是自己想要的，丢弃证书，拒绝连接

 需要明白的是，证书申请比较麻烦，并且证书是有使用时限的，一旦过期，就需要重新申请，这就保证了合法的证书是可靠的，可以根据其中的内容判断是否丢弃

最终方案 

 在「非对称式加密」+「对称式加密」的基础上，引入「CA证书」，确保客户端获取到的是安全、可靠的 公钥，再使用该 公钥 加密 密钥，形成密文，该密文只能由服务器使用自己的 私钥 解密，获取 密钥，进行数据传输

只要公钥是安全可靠的，那么服务器在收到密文时，得到的密钥也是安全可靠的 

客户端通过 CA证书 获取到服务器的 公钥 

 使用 公钥 向服务器发送 密钥

 

 双方使用 密钥 进行数据传输

有了「非对称式加密」+「对称式加密」+「CA证书」的解决方案，可以充分保证我们在上网冲浪时的安全性，这也就是为什么大多数钓鱼网站仍在使用 HTTP 协议，因为这样可以跳过整个安全检测方案 

 证书 扮演着重要角色，在访问那些 证书 过期，或者是没有 证书 的网站时需要提高警惕

如何成为中间人？

ARP 欺骗、ICMP 攻击、假 WIFI、假网站