《Linux网络编程》5.HTTPS协议

💡Yupureki:个人主页

✨个人专栏:《C++》 《算法》《Linux系统编程》《高并发内存池》《MySQL数据库》

《个人在线OJ平台》《Linux网络编程》《CMake自动化构建工具》《Redis数据库》

---

🌸Yupureki🌸的简介:

---

目录

[1. HTTPS是什么](#1. HTTPS是什么)

[1.1 HTTPS和HTTP的区别](#1.1 HTTPS和HTTP的区别)

[2. 加密的概念](#2. 加密的概念)

[2.1 什么是加密?](#2.1 什么是加密?)

[2.2 为什么要加密?](#2.2 为什么要加密?)

[2.3 常见的加密方式](#2.3 常见的加密方式)

[1. 对称加密](#1. 对称加密)

[2. 非对称加密](#2. 非对称加密)

[3. 哈希算法](#3. 哈希算法)

[3. HTTPS的流程](#3. HTTPS的流程)

[3.1 只使用对称加密](#3.1 只使用对称加密)

[3.2 只使用非对称加密](#3.2 只使用非对称加密)

[3.3 双方都使用非对称加密](#3.3 双方都使用非对称加密)

[3.4 非对称加密 + 对称加密](#3.4 非对称加密 + 对称加密)

[3.5 非对称加密 + 对称加密 + 数字证书认证](#3.5 非对称加密 + 对称加密 + 数字证书认证)

---

1. HTTPS是什么

HTTPS 的全称是 超文本传输安全协议（HyperText Transfer Protocol Secure）。

简单来说，它就是 HTTP 的安全版本，用来在网页浏览器和网站服务器之间安全地传输数据。

你可以把它想象成给普通 HTTP 加上了一层"保护壳"，这层壳就是 TLS（传输层安全协议），以前也叫 SSL。

1.1 HTTPS和HTTP的区别

普通的 HTTP 传输是明文的，就像寄明信片，内容在路上可以被任何人看到或篡改。而 HTTPS 是加密传输，相当于把信锁进一个只有你和收件人能打开的保险箱，别人即便截获也看不懂、改不了。

具体保护了这三点：

• 加密（防偷窥）：通信内容被加密，黑客抓包看到的只是一堆乱码。

• 完整性（防篡改）：数据如果在传输中被改动，接收方能立刻发现并拒绝。

• 身份验证（防冒充）：通过 CA 机构签发的数字证书，证明你访问的网站是真的，而不是假冒的钓鱼网站。

浏览器地址栏的开头是 https:// ，并且通常会显示一个小锁🔒图标 。默认使用 443 端口，而 HTTP 默认用 80 端口。

今天互联网上绝大多数网站（包括我们现在的对话）都已经默认使用 HTTPS，没有小锁的网站浏览器甚至会直接标记为"不安全"。

所以，HTTPS 就是"加了密的 HTTP"，解决了 HTTP 明文传输不安全的问题。

2. 加密的概念

2.1 什么是加密?

简单说，加密就是把一段能看懂的信息（明文） ，通过特定规则和一把钥匙（密钥） ，转换成**看不懂的乱码（密文）**的过程。只有拥有对应钥匙的人，才能把乱码恢复成原文。

2.2 为什么要加密?

在数字世界里，加密能解决三大核心安全问题，也就是 HTTP 明文传输完全做不到的事：

• 防偷窥（机密性）

  你的密码、聊天记录、银行卡号如果在网络上"裸奔"，任何人都能轻易截获。加密后，即便数据被窃听，黑客也只能看到一串无意义的乱码。

• 防篡改（完整性）

  加密通常与"完整性校验"一起工作。如果有人在路上偷偷改了你的数据（比如把收款账号改了），接收方用钥匙解不开或校验不通过，会立刻发现数据被动了手脚。

• 防冒充（身份验证）

  在非对称加密中，"用公钥加密，只有对应私钥持有者才能解开"这个特性，还能用来验证对方的身份，确保你确实在跟真正的网站通信，而不是钓鱼网站。

2.3 常见的加密方式

现代加密主要分为三大类，HTTPS 里会混合用到它们：

1. 对称加密

加密和解密用的是同一把密钥。

• 特点：速度飞快，适合加密海量数据。但难在如何安全地把这把钥匙告诉对方，一旦钥匙在传输中被偷，加密就失效了。

• 常见算法 ：AES（今天最主流，微信、Wi-Fi 密码都用它）、ChaCha20。

• 在HTTPS中的角色：证书验证通过后，用来加密传输的所有网页内容。

2. 非对称加密

有两把数学上相关的钥匙：公钥 和私钥。公钥可公开给任何人，私钥则必须严格保密。

• 核心逻辑：公钥加密的内容，只有对应私钥能解开；反之，用私钥签名，别人可用公钥验证签名是否由你发出。

• 特点：完美解决了对称加密"密钥传输被偷"的问题，但计算慢，不适合处理大量数据。

• 常见算法 ：RSA 、ECC（椭圆曲线，在移动端更高效安全）。

• 在HTTPS中的角色：握手阶段，用来安全地传递那个"对称加密的钥匙"，以及验证网站身份的数字签名。

3. 哈希算法

严格来说它不是加密，因为无法从结果反推出原文。它把任意长度的数据，变成固定长度的一串数字（比如几十位的十六进制串）。

• 特点 ：哪怕是原文的一丁点改动，生成的"指纹"都会截然不同。常用于 检查数据是否被篡改 和 安全存储密码。

• 常见算法 ：SHA-256、SHA-3。

• 在HTTPS中的角色：对证书信息生成摘要，并用CA的私钥签名，形成最终的数字证书。

3. HTTPS的流程

3.1 只使用对称加密

• 工作过程：

  1. 你和服务器事先约定好一把相同的密钥。

  2. 你发消息时，用这把密钥加密；服务器收到后，用同一把密钥解密。

  3. 全程使用 AES 等算法，速度极快。

• 致命缺陷：密钥配送问题

  你俩怎么隔着满是窃听者的互联网，安全地约定这第一把钥匙？如果通过网络明文发送，就会被直接截获，后续加密形同虚设。线下见面约定又不现实。

结论：单用对称加密，无法解决互联网通信的安全初始化问题。

3.2 只使用非对称加密

• 工作过程：

  1. 服务器公布公钥，私藏私钥。

  2. 浏览器用服务器的公钥加密消息，只有服务器的私钥能解开。

  3. 反过来，服务器用私钥加密（签名），浏览器用公钥解密（验证）。

  4. 公钥公开传输，不怕被截获，完美解决了方案1的难题。

• 致命缺陷：性能极差且不安全

  • RSA 等非对称算法计算极慢，是 AES 的成百上千倍，不适合加密大量网页数据。

  • 无法抵御中间人攻击：攻击者可以截获服务器的公钥，然后把自己的公钥冒充成服务器的发给你。整个过程你毫无察觉，攻击者就成了一个能解密、查看并重新加密转发的透明代理。

结论：非对称加密安全解决了密钥分发，但性能差，且存在公钥身份被篡改的风险。

3.3 双方都使用非对称加密

• 工作过程：

  1. 不仅服务器有公钥私钥，客户端也要生成自己的公私钥对。

  2. 通信时，客户端用服务器的公钥加密，再用自己的私钥签名；服务器则反过来操作。

• 缺陷 ：

  方案2的性能问题 和身份冒充风险一个都没解决，反而因为客户端也要进行复杂运算（对当时的移动设备是灾难），让整个过程更慢、更重。它只是互相确认了来源，但未解决根本问题。

3.4 非对称加密 + 对称加密

这是关键转折点，HTTPS 的混合加密原理由此诞生。

• 工作过程：

  1. 握手阶段（用非对称，慢但安全） ：

     浏览器获取服务器公钥，然后生成一把临时的对称密钥，用服务器的公钥加密后发给它。只有服务器能解开。

  2. 数据传输阶段（用对称，快） ：

     双方都用这把临时对称密钥，进行 AES 高速加密通信。

• 它解决了什么 ：

  完美结合了非对称加密的安全密钥协商能力，和对称加密的高性能。方案1和方案2的缺陷被巧妙互补。

• 它依然没解决的致命问题 ：
  你拿到的真的是谷歌的公钥吗？

  中间人攻击依然有效。攻击者可以把自己的公钥冒充成谷歌的，在握手时解密你的"临时对称密钥"，从而破解全程。这个方案只防了被动窃听，防不住主动的身份冒充。此时，整套系统的信任根基是空的。

3.5 非对称加密 + 对称加密 + 数字证书认证

为了解决"公钥身份真伪"这个最终难题，我们引入了第三方信任体系。

• 工作过程（就是标准 TLS 握手的完整应用）：

  1. 证书颁发 ：谷歌服务器把自己的公钥、域名等信息，提交给受信任的 CA 机构。CA 核实身份后，用自己的私钥对整个信息作数字签名，生成证书。

  2. 证书验证 ：浏览器访问谷歌时，拿到的不再是裸公钥，而是这个数字证书 。浏览器用内置的 CA 公钥 验证证书签名，确保证书内容未被篡改，并核对域名。

  3. 建立加密：验证通过后，双方再用方案4的混合加密方式，安全协商对称密钥并通信。

• 它解决了什么 ：

  通过引入 CA 这个信任锚点，成功将公钥 和身份绑定。攻击者无法伪造签名，一旦篡改公钥或被冒充，证书验证立刻失败，浏览器会发出警告。至此，安全三要素------机密性、完整性和身份验证------才全部达成。