📃个人主页：island1314

🔥个人专栏：Linux—登神长阶
⛺️ 欢迎关注：👍点赞 👂🏽留言 😍收藏 💞 💞 💞

• 生活总是不会一帆风顺，前进的道路也不会永远一马平川，如何面对挫折影响人生走向 – 《人民日报》 💫

---

🔥 目录

• • @[TOC]( 🔥 目录)
  • 一、背景知识
  • • 1.1 HTTPS 是什么及其工作原理？
    • 1.2 HTTP与HTTP两者区别
    • 1.3 什么是加密
    • 1.4 常见的加密方式
    • 1.5 数据摘要与数据指纹
    • 1.6 数字签名
  • 二、HTTPS 工作方案
  • • 方案一：只使用对称加密
    • 方案二：只使用非对称加密
    • 方案三：双方都使用非对称加密
    • 方案四：非对称加密 + 对称加密
    • • 中间人攻击
  • 三、非对称加密 + 对称加密 + 证书认证
  • • 1. CA 认证
    • 2. 原理 -- 客户端进行认证
    • 3. 疑问
    • • 🐇 中间人有没有可能篡改该证书？
      • 🐇 中间人整个掉包证书？
    • 4. 常见问题
    • 5. 完整工作流程
  • 四、百度网盘的工作原理
  • • 1. MD5校验与文件存储机制
    • 2. HTTPS加密传输与数据安全
    • 3. 技术优势与用户场景
    • 4. 技术局限与应对
  • 五、共勉

---

一、背景知识

🔥 之前我们已经了解了 Http 协议，但是后面我也说道 Http 协议无论是 GET 还是 Post 方法传输数据。都是以明文进行传输，这意味着数据极易受到拦截和篡改。 而为了解决这一问题，HTTPS应运而生。本文将详细探讨HTTPS协议的工作原理、HTTP与HTTPS的区别、加密技术的应用以及如何通过证书认证保障安全通信

1.1 HTTPS 是什么及其工作原理？

HTTPS协议则通过在 应用层 和 传输层 之间增加一个加密层（SSL/TLS），为数据传输提供安全保障。

HTTPS的工作原理如下：

• 当用户通过HTTPS访问网站时，数据首先被加密层处理，进行加密后再交给传输层。

• 接收方在接收到数据后，同样通过加密层解密，解密后的数据再交给应用层使用。

• 在整个传输过程中，只有在用户层数据是明文的，而网络中的传输数据始终处于加密状态。

HTTPS 也是一个应用层协议. 只是 在 HTTP 协议的基础上引入了一个加密层.

加密方式的定义？

• web 组织定义的

站在一个黑客角度

1. 攻破成本 > 攻破后的收益，就可以认为是相对安全的，起码一般都不会做这种亏损的事
2. ssl 有权威的官方的加密解密方案

1.2 HTTP与HTTP两者区别

HTTP与HTTPS在工作方式和应用场景上有显著区别：

• 端口不同：HTTP使用80端口，而HTTPS使用443端口。
• 安全性：HTTP是明文传输，不安全；HTTPS则通过加密保证数据的安全性。
• 效率：由于HTTPS需要进行加密解密操作，因此效率略低于HTTP。在内网等安全环境下，可以考虑使用HTTP提高效率。

1.3 什么是加密

加密：是将明文数据通过一定的规则转换成密文的过程，从而保证数据在传输过程中不会被非法获取或篡改

解密：就是把 密文 再进行一系列变换, 还原成 明文 .

密钥：在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这
样的数据称为 密钥 (正确发音 yue 四声, 不过大家平时都读作 yao 四声) .

结论：

• 明文：未加密的原始数据。
• 密文：经过加密后的数据。
• 加密：将明文转换为密文的过程。
• 解密：将密文还原为明文的过程。
• 密钥：用于加密和解密过程的核心数据。

为什么要加密？

因为 http 的内容是明文传输的，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。

• 劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击 ，所以我们才需要对信息进行加密

1.4 常见的加密方式

① 对称加密

• 采用单钥 密码系统 的加密方法，用同一个密钥来作为信息的加密和解密，也称为单密钥加密
• 特点：算法公开、加密速度快效率高、计算量小。
• 常见的对称加密算法：DES、AES、Blowfish等。

举个例子：一个简单的对称加密 — 按位异或

假设 明文 a = 1234, 密钥 key = 8888

• 则加密 a ^ key 得到的密文 b 为 9834.
• 然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.
• (对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)

当然, 按位异或只是最简单的对称加密，HTTPS 中并不是使用按位异或.

② 非对称加密

• 需要两个密钥来进行加密和解密：公钥（public key）和 私钥（private key）
• 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.
  • 通过公钥对明文加密, 变成密文
  • 通过私钥对密文解密, 变成明文
• 也可以反着用
  • 通过私钥对明文加密, 变成密文
  • 通过公钥对密文解密, 变成明文
• 常见的非对称加密算法：RSA、DSA、ECDSA 等。
• 虽然非对称加密的安全性更高，但由于算法复杂，效率较低使得加密解密速度没有对称加密解密的速度快

1.5 数据摘要与数据指纹

• 数字指纹(数据摘要)：基本原理是利用单向散列函数(Hash 函数)对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制（因为哈希不是个可逆的过程），但可以用来判断数据有没有被篡改
  • 摘要的作用：快速判断数据是否被篡改，但不能反推出原始信息。
  • 和加密算法的区别是，摘要严格意义上不是加密，因为没有解密，不过从摘要很难反推原信息，通常用来进行数据对比
  • 基本具有唯一性
• 摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

1.6 数字签名

数字签名是对摘要进行加密后的结果，用来确保数据的完整性和身份验证。

通过非对称加密技术，使用私钥对摘要加密，接收方用公钥解密，经过比对，可以验证数据是否被篡改。

二、HTTPS 工作方案

既然要保证数据安全, 就需要进行 “加密”，网络传输中不再直接传输明文了, 而是加密之后的 “密文”.

• 加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密

其实在网络通信，我们要解决的是如下问题：

1. 数据被监听
2. 数据被篡改

方案一：只使用对称加密

如果通信双方都各自持有同一个密钥X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）

但是服务器同一时刻其实是给很多客户端提供服务的，这么多客户端, 每个人用的秘钥都必须是不同的 (如果是相同那密钥就太容易扩散了, 黑客就也能拿到了).

• 因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情~

上面还是其次的，最重要的是最开始的时候我们怎么保证客户端和服务器看到的是同一个密钥

1. 如果最开始客户端把密钥发给服务器，那这个密钥是明文传还是密文传？
2. 明文传那黑客不就拿到了，
3. 暗文加密传那就需要对密钥进行加密，就仍然需要先协商确定一个 “密钥的密钥”
4. 这不就是鸡生蛋还是蛋生鸡的问题吗？所以纯纯使用对称加密是不行的！

方案二：只使用非对称加密

通信之前先得交换密钥，鉴于非对称加密的机制，用公钥和私钥都可以加密，但用公钥加密就要使用私钥解密，使用私钥加密就要使用公钥解密，所以可以尝试如下图操作：

缺点：

• 单项的数据安全：现在只能保证从C->S的安全性(暂时的安全)，没有办法解决S->C的安全性。
• 运算速度非常非常慢，给用户体验不好

方案三：双方都使用非对称加密

1. 服务端拥有公钥S与对应的私钥S’，客户端拥有公钥C与对应的私钥C’
2. 客户和服务端互相交换公钥
3. 客户端给服务端发信息：先用S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S’
4. 服务端给客户端发信息：先用C对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥C’

缺点：

1. 效率太低
2. 仍然有安全问题

方案四：非对称加密 + 对称加密

这种方案通过非对称加密进行密钥交换，之后的数据传输使用对称加密，从而兼顾了安全性和效率。具体流程如下：

1. 客户端发起HTTPS请求，获取服务器的公钥。

2. 客户端生成一个对称密钥C，并使用服务器的公钥S加密发送给服务器。

   1. 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥(真的吗？)

3. 服务器通过私钥 S’ 解密，获得用户发送的对称密钥 C，并且用这个对称密钥加密给客户端返回的响应数据

4. 后续客户端和服务器的通信都只用对称加密即可，但是由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义

这里虽然解决了 安全通信 的效率问题，但是还是存在安全问题

中间人攻击

中间人攻击是指在客户端与服务器通信的过程中，攻击者通过劫持并篡改数据进行窃听或伪造。

在方案2/3/4中，客户端获取到公钥S之后，客户端形成的对称秘钥C，然后用服务端给客户端的公钥S对C进加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥C，因为只有服务器有私钥S’

但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，如果 M 在请求公钥后就已经成功成为了中间人

• 客户端向服务器发起请求，服务器明文传送公钥S给客户端

• 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端

上面的攻击方案，同样适用于方案2、方案3

问题本质出在哪里了呢？

• 结论：服务器返回公钥的时候，被中间人窃取并替换了 && 客户端没有辨别公钥是否合法的能力

下面要围绕 客户端能够具有辨别服务器发过来的公钥的合法性！ 来解决问题，避免公钥被替换

• 为了防止这种攻击，HTTPS引入了 证书认证机制

三、非对称加密 + 对称加密 + 证书认证

在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个 证书，证书包含了之前服务端的公钥，也包含了网站的身份信息

1. CA 认证

为了防止中间人篡改公钥，HTTPS采用了数字证书认证机制。CA（Certificate Authority）作为权威的第三方机构，为服务器颁发数字证书，保证公钥的真实性。证书的验证流程如下：

1. 服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，CA机构对服务器的公钥进行签名并颁发证书
2. 然后客户端在建立HTTPS连接时，会首先获取服务器的证书，并验证证书是否由可信的CA签发、是否过期、是否被篡改，然后服务器就会从证书里获取公钥
3. 只有在证书验证通过后，客户端才会信任服务器，并使用其公钥进行加密通信。

证书可以理解成是⼀个结构化的字符串，里面包含了以下信息：证书发布机构、证书有效期、公钥、证书所有者、签名等

需要注意的是：申请证书的时候，需要在特定平台生成查，会同时生成一对密钥对，即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。
其中

• 公钥会随着 CSR 文件，一起发给 CA 进行权威认证
• 私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）

客户端能够具有辨别服务器发过来的公钥的合法性! 我们说是通过证书来进行甄别的，那证书如何做到的呢？

---

这里大家感兴趣的话，也可以自己去申请证书

使用在线生成 CSR 和私钥：https://myssl.com/csr_create.html

• 形成 CSR 之后，后续就是向 CA 进行申请认证，不过一般认证过程很繁琐，网络各种提供证书申请的服务商，一般真的需要，直接找平台解决就行

---

2. 原理 – 客户端进行认证

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

1. 判定证书的有效期是否过期
2. 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
3. 验证证书是否被篡改:

签名：

• 对一份文本(可以认为这里是CA证书内的明文信息)经过hash散列形成散列值，我们称之为数据摘要。然后用签名者的私钥(CA机构的私钥)对数据摘要加密形成了数据签名
• 更重要的把这个数据签名和这个明文信息合在一起，形成数字签名的数据。

验证：

• 把原始文本和签名分开（签名解密），一个对原始文本使用相同的散列函数进行散列形成散列值（数据摘要 hash1），另一个对签名用签名者的公钥解密形成散列值（hash2）

• 然后对比两个散列值，如果这两个散列值不一样，就注定有人要么改了原始文件，要么改了签名。

• 只要这两个散列值一样，那么原始文本和它曾经形成的签名是一样的，说明这个原始文本没有被篡改过！

当服务端申请 CA 证书的时候，CA 机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如下：

1. CA 机构拥有非对称加密的私钥 A 和公钥 A’
   1. CA为了签发证书，CA也有自己的CA公钥，CA私钥
   2. 因为我们使用CA的私钥形成数据签名，所以只有CA能形成可信任的证书！(CA私钥只在CA)
2. CA 机构对服务端申请的证书明文数据进行 hash，形成数据摘要
3. 然后对数据摘要用 CA 私钥 A’加密，得到数字签名 S服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书就可以颁发给服务端了

此时通过验证可以确保：数据和签名的证书不被更改啦

3. 疑问

🐇 中间人有没有可能篡改该证书？

① 明文篡改：

• 中间人可以尝试篡改证书的明文部分。
• 但是，由于中间人不具备证书颁发机构（CA）的私钥，因此无法生成与篡改后的证书相匹配的有效数字签名。

② 验证失败：

• 如果证书强行被篡改，客户端会使用其存储的信任链中的CA公钥来验证证书签名。
• 客户端将计算证书明文的哈希值，并用CA的公钥解密签名。
• 如果哈希值不匹配，则表明证书已被篡改，客户端会认为 证书不可信并中断连接

③ 私钥加密：

• 中间人不能使用自己的私钥来 替换或重新加密证书 ，因为客户端会使用特定CA的公钥来验证签名。
• 客户端将无法正确解密签名，从而检测到篡改。

🐇 中间人整个掉包证书？

• 这个肯定是不行的，因为中间人没有 CA 私钥，所以无法制作假的证书(为什么？)
• 所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包
• 但是用自己申请的证书进行掉包，这个方法确实能做到证书的整体掉包，但是：证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。

结论：

• 中间人没有 CA 私钥，无法对任何证书都无法进行合法修改，包括自己的
• 证书包含的信息以及数字签名机制确保了即使中间人尝试篡改或替换证书，客户端也能检测出异常并采取安全措施，如中断连接以防止潜在的信息泄露。

4. 常见问题

🧀 为什么摘要内容在网络传输的时候一定要加密形成签名？

MD 5 特性

• 定长： 不论输入字符串的长度如何，生成的 MD5 值都是固定长度（16 字节或 32 字节）。

• 分散： 输入字符串的任何微小变化都会导致输出的 MD5 值显著不同。

• 不可逆： 从原始字符串生成 MD5 值容易，但从 MD5 值反推回原始字符串在理论上是不可能的。

由于这些特性，如果两个字符串具有相同的 MD5 值，则可以认为这两个字符串是相同的。这使得 MD5 可以用来验证数据完整性。

理解证书篡改的判定过程：（这个过程就好比判定这个身份证是不是伪造的身份证）

1. 假设有一个简单的字符串 “hello” 作为证书内容，其 MD5 值为 BC4B2A76B9719D91。

2. 如果 “hello” 被篡改为 “hella”，则新的 MD5 值将完全不同，例如 BDBD6F9CF51F2FD8。

3. 当服务器发送 “hello” 和其对应的 MD5 值给客户端时，客户端可以通过重新计算 “hello” 的 MD5 来验证是否被篡改。

存在的问题：

如果 攻击者篡改了 “hello” 并且同时更新了相应的 MD5 值，那么客户端就无法检测到这种篡改。

因此被传输的哈希值不能传输明文, 需要传输密文.

解决方案：

• 对证书明文进行哈希处理后形成散列摘要，使用 CA 私钥 对哈希值进行加密形成签名。
• 将 明文+加密后的签名 一起组成完整的 CA 证书，并发送给服务端。
• 客户端接收证书后，利用操作系统中预存的 CA 公钥 解密签名，还原出原始哈希值，并与自己计算的哈希值对比，以此来验证证书的合法性。

🧀 为什么签名不直接加密，而是要先 hash 形成摘要?

• 缩小签名密文的长度，加快数字签名的验证签名的运算速度

🧀 如何成为中间人 - 了解

1. ARP 欺骗： 在局域网内，攻击者通过监听 ARP 请求广播包获取其他节点的 IP 和 MAC 地址信息，然后向受害者发送伪造的 ARP 应答，声称自己是另一台主机，从而使受害者的流量被重定向到攻击者处。
2. ICMP 重定向攻击： 利用 ICMP 协议中的重定向报文类型，攻击者可以伪造一个 ICMP 重定向消息，使目标设备误以为攻击者提供了一个更优的路由路径，进而所有流量都被导向攻击者指定的位置。
3. 假 WiFi 和假网站（钓鱼网站）： 攻击者设置虚假的无线网络接入点或模仿合法网站的界面，诱使用户连接并泄露敏感信息。

5. 完整工作流程

⭕ 左侧都是客户端做的事情, 右侧都是服务器做的事情.

HTTPS的完整工作流程涉及三组密钥：（双非一对）

1. 第一组密钥（非对称加密）：用于验证证书的合法性。客户端通过CA的公钥验证服务器证书是否被篡改
   1. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得),
   2. 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥).
   3. 服务器在客户端请求时，返回携带签名的证书.
   4. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性
2. 第二组密钥（非对称加密）：用于协商加密传输对称密钥。
   1. 客户端用收到的 CA 证书中的公钥(是可被信任的) 给随机生成的对称加密的密钥加密，传输给服务器,
   2. 服务器通过私钥解密获取到对称加密密钥.
3. 第三组密钥（对称加密）：用于后续数据传输的加密解密 操作。

🥑这个流程确保了客户端与服务器之间的通信安全，避免数据在传输过程中被窃取或篡改。

其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.

• 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
• 第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥（CA 认证中进行）

HTTPS通过非对称加密与对称加密的结合，再辅以CA证书认证，极大地提高了数据传输的安全性。在如今信息安全至关重要的时代，HTTPS已经成为网站保护用户隐私和数据安全的标准协议。

属性名	作用
expires=<date>[要验证]	设置 Cookie 的过期日期/时间。 如果未指定此属性， 则 Cookie 默认为会话 Cookie， 即当浏览器关闭时过期。
path=<some_path>[要验证]	限制 Cookie 发送到服务器的哪些路径。 默认为设置它的路径。
domain=<domain_name> [了解即可]	指定哪些主机可以接受该 Cookie。 默认为设置它的主机。
secure [了解即可]	仅当使用 HTTPS 协议时才发送 Cookie。 这有助于防止 Cookie 在不安全的 HTTP 连接中被截获。
HttpOnly [了解即可]：	标记 Cookie 为 HttpOnly， 意味着该 Cookie 不能被客户端脚本（如 JavaScript） 访问。 这有助于防止跨站脚本攻击（XSS） 。

四、百度网盘的工作原理

看了上面这么多，其实我们就可以类比的知道 百度网盘 的工作原理

• 百度网盘的工作原理核心在于文件指纹技术（MD5校验）与HTTPS加密传输的结合，通过优化存储效率并保障数据安全，实现大容量存储与高效管理。

1. MD5校验与文件存储机制

1. 文件指纹生成
   用户上传文件时，百度网盘会通过MD5算法（或其他组合哈希算法如SHA1+CRC32）生成文件的唯一哈希值，该值由文件内容决定，与文件名无关。例如，一个视频文件的MD5值可能为7F3B85B0A1F8E768D43C502FA03A2853

2. 秒传与去重

   • 秒传原理：系统将文件的MD5值与服务器数据库比对。若已存在相同哈希值，则仅将文件引用添加到用户文件列表，无需重复上传，实现“秒传”

   • 去重效果：用户共享的重复文件（如热门电影、软件安装包）仅存储一次，大幅减少物理空间占用。例如，6亿用户理论上需12亿T空间，实际可能仅需数亿T

3. 数据本体与用户索引分离

   • 数据层：文件实际存储为无后缀的二进制数据，按哈希值分类存放于分布式服务器中

   • 索引层：用户文件列表仅记录文件名、路径与对应的MD5值，实际存储量极小

---

2. HTTPS加密传输与数据安全

1. 传输过程加密

   • HTTPS协议：所有数据传输均通过SSL/TLS加密，防止中间人攻击或数据窃取。例如，用户上传或下载文件时，内容会被加密后传输

   • 哈希值保护：MD5值在传输过程中同样加密，确保攻击者无法篡改哈希值伪造文件

2. 完整性验证

   • 下载校验：用户下载文件后，可通过本地计算MD5值与服务器记录比对，验证文件是否完整。例如，使用Windows命令

     certutil -hashfile 文件名 md5
     

   • 违规内容屏蔽：系统通过预存违规文件的MD5值库（如涉黄、盗版内容），自动拦截匹配文件的上传或分享

---

3. 技术优势与用户场景

1. 存储效率提升

   • 动态分配：用户显示的“2T空间”为逻辑容量，实际占用取决于唯一文件数量。例如，用户A保存他人分享的1GB文件，仅增加索引记录，不占用额外物理空间

   • 资源复用：热门文件（如系统镜像）被多人保存时，仅需维护单个数据副本

2. 安全与管控

   • 加密存储：服务器端文件采用加密映射，仅授权用户可访问对应索引

   • 高效封禁：通过MD5快速定位违规文件，删除数据本体后，所有用户索引自动失效

3. 用户体验优化

   • 秒传功能：重复文件上传速度极快，适合分享场景

   • 多设备同步：通过HTTPS实时同步索引，确保跨设备文件一致性

---

4. 技术局限与应对

1. 哈希冲突风险

   • 理论上MD5存在碰撞可能（不同内容生成相同哈希值），但实际概率极低（约1/(2^128)）。百度可能采用多算法组合（如MD5+SHA1）进一步降低风险

2. 隐私争议

   • 用户文件通过MD5被系统全局识别，存在隐私泄露隐患。例如，用户A上传的私密文件若被他人通过哈希值匹配获取，可能被非法下载

---

总结

技术环节	实现方式	用户感知
文件上传	MD5校验 + HTTPS加密传输	秒传、快速分享
存储管理	哈希去重 + 分布式冗余备份	大容量、低成本
安全管控	加密映射 + 违规MD5库匹配	文件屏蔽、下载限速
数据验证	本地/服务器MD5比对	文件完整性保障

通过MD5校验与HTTPS加密的协同，百度网盘在保证数据安全的同时，极大优化了存储效率，但其技术实现也带来隐私与中心化管控的争议。用户在使用时需权衡便利性与潜在风险

五、共勉

【★,°:.☆(￣▽￣)/$:.°★ 】那么本篇到此就结束啦，如果有不懂 和 发现问题的小伙伴可以在评论区说出来哦，同时我还会继续更新关于【Linux】的内容，请持续关注我 ！！