当前位置：首页 > news >正文

HTTP 与 HTTPS

news 来源：原创 2025/5/26 8:00:48

HTTP 与 HTTPS 有哪些区别？

HTTP 与 HTTPS 是两种常用的网络通信协议，虽然它们的名字只有一个字母之差，但在安全性、数据传输方式、端口号等方面有本质区别。下面是它们的对比与解释：

🔐 一句话区别：

HTTP 是明文传输的，HTTPS 是加密传输的 HTTP。

📊 HTTP 与 HTTPS 对比一览表：

特性	HTTP	HTTPS
安全性	❌ 不安全，数据明文传输	✅ 使用 SSL/TLS 加密，防窃听、防篡改
端口号	80	443
加密协议	无	使用 SSL（已过时）或 TLS（主流）
证书要求	不需要证书	需要数字证书（CA 签发或自签）
URL 前缀	`http://`	`https://`
性能开销	小，因无需加解密	稍大，需要 SSL/TLS 握手及加解密过程
数据完整性保障	无	有，防止中间人攻击和数据篡改
搜索引擎权重	较低	更高（Google等搜索引擎优先 HTTPS 页面）
应用场景	一般网站、无敏感信息页面	登录、支付、个人信息、企业应用等敏感数据传输场景

🔧 二、HTTPS 的工作原理（简要）

客户端发起 HTTPS 请求；
服务端返回数字证书（含公钥）；
客户端验证证书合法性（如是否被信任）；
客户端生成对称密钥，用公钥加密后发送给服务端；
服务端用私钥解密得到对称密钥；
双方后续使用对称密钥加密通信，提高效率。

TLS 协议保障了数据的机密性（加密）、完整性（防篡改）、身份认证（防伪造）。

💡 三、什么时候用 HTTPS？

是否推荐使用 HTTPS	场景示例
✅ 强烈推荐	登录、注册、支付、企业系统
✅ 推荐	API 接口、WebSocket、私有数据
⚠️ 可选（测试环境）	静态页面、无数据交互的展示页

现代网站基本默认启用 HTTPS，且可以使用 Let's Encrypt 提供的免费 SSL 证书。

✅ 总结

HTTP：传输效率高，但无加密，存在安全隐患。
HTTPS：传输安全，适合处理敏感信息，已成为主流。

如果你是开发者，在所有生产环境中，强烈建议默认使用 HTTPS，这已经是 Web 安全的基础要求。

HTTPS 解决了 HTTP 的哪些问题？

HTTPS 是为了解决 HTTP 在安全方面的重大缺陷而提出的。下面我们系统讲解 HTTPS 解决了 HTTP 的哪些核心问题。

🔧 一、HTTP 存在的主要安全问题

HTTP 本身是明文传输协议，没有任何加密或身份认证机制，会带来以下问题：

问题类别	描述
1️⃣ 信息泄露	数据在网络中明文传输，容易被第三方（如中间人）窃听，比如密码、账号、身份证号等
2️⃣ 数据篡改	传输过程中内容可能被篡改，例如黑客更改网页内容、注入恶意代码
3️⃣ 身份伪造	客户端无法验证服务端身份，容易被钓鱼网站冒充；服务端也无法确认客户端真实身份
4️⃣ 中间人攻击	攻击者伪装成客户端和服务器之间的中介，获取通信内容甚至控制连接

🔐 二、HTTPS 解决的 HTTP 问题

HTTPS 在 HTTP 上加入了 SSL/TLS 协议，通过加密、身份验证和完整性校验，解决了上述所有问题：

✅ 1. 防止窃听（保障机密性）

数据通过对称加密（如 AES）进行加密；
第三方即使截获数据包，也无法读取明文内容。

👉 解决了 信息泄露 问题。

✅ 2. 防止篡改（保障完整性）

每个加密消息都附带 MAC（消息验证码）或哈希值；
一旦数据被修改，接收端可立即识别，拒绝处理。

👉 解决了 数据被劫持或伪造 的问题。

✅ 3. 验证身份（防止伪造）

使用服务器的 数字证书（CA 签发）验证服务器真实身份；
防止用户被假冒网站欺骗（如钓鱼网站）。

👉 解决了 服务端伪装 / 钓鱼问题。

✅ 4. 防中间人攻击（MitM）

HTTPS 的握手过程中，客户端校验服务器证书，确保通信的唯一合法性；
即便攻击者中间拦截，也无法篡改或伪造会话。

👉 解决了 中间人攻击风险。

🔄 三、HTTPS 实现安全的三大核心技术

机制	功能
非对称加密	解决密钥交换的安全性（公钥/私钥）
对称加密	加密实际传输数据（高效）
数字证书	确保服务器/网站身份真实可信

✅ 总结一句话：

HTTPS = HTTP + TLS/SSL，加密 + 认证 + 完整性保护，从根本上解决了 HTTP 无法提供的安全性保障。

它是现代 Web 安全通信的基石，几乎所有涉及用户数据的服务（如登录、支付、API调用等）都必须使用 HTTPS。

HTTPS 是如何建立连接的？其间交互了什么？

✅ 简要回答：

HTTPS 建立连接过程 = TCP 三次握手 + TLS 握手 + HTTP 请求/响应
在这个过程中，客户端与服务器协商加密算法、交换密钥、验证证书，最终建立起一个安全的通信通道。

🧠 HTTPS 建立连接全过程（分步骤讲）

🌐 0. 先进行 TCP 三次握手（建立传输层连接）

与普通 HTTP 一样，HTTPS 也首先通过 TCP 建立连接。

🔐 1. TLS 握手阶段（核心）

TLS 握手是 HTTPS 安全通信的关键，分为以下几个阶段：

📥 步骤 1：客户端发起 “Client Hello”

客户端向服务器发送如下内容：

支持的 TLS 协议版本（如 TLS 1.2、TLS 1.3）
支持的加密套件列表（对称加密算法、哈希算法等）
一个随机数（Client Random）
可选的扩展字段，如 SNI（表示想访问的域名）

📤 步骤 2：服务器回应 “Server Hello”

服务器返回以下信息：

确定的协议版本和加密算法（从客户端支持中选择）
一个随机数（Server Random）
数字证书（含服务器公钥、公钥签名等）
可选的证书链、中间证书等
若开启双向认证，还会请求客户端证书

📁 步骤 3：客户端验证服务器身份

客户端会：

使用操作系统或浏览器内置的 CA 根证书，对服务器证书进行校验（证书是否可信、未过期、合法）
若验证失败，则提示“此连接不安全”

🔑 步骤 4：密钥协商（以下是 TLS 1.2 常见做法）

客户端生成一个“预主密钥”（pre-master key）
用服务器公钥加密后发给服务器（只有服务器私钥能解密）
双方基于：
```
pre-master key + client_random + server_random
```
使用密钥导出函数（PRF）生成对称加密密钥（session key）

🔐 此后，通信将使用这个对称密钥进行加密传输（高效）

🔐 步骤 5：握手完成 & 通信开始

双方发送“Finished”消息，表示握手完成
正式使用对称密钥进入安全通信阶段（加密的 HTTP）

✅ 总结流程图（简化版）：

Client                                Server| --------- ClientHello -----------> ||                                    || <--------- ServerHello ------------|| <-------- Certificate -------------||                                    || -- PreMasterKey (Encrypted) -----> ||                                    || -------- Finished (Encrypted) ---> || <-------- Finished (Encrypted) --- ||                                    || <<<     Encrypted HTTP Data     >>>|

🔍 TLS 握手过程中交互了哪些关键数据？

阶段	交互数据	作用
ClientHello	支持的协议版本、加密算法、随机数	告知服务器如何协商加密方式
ServerHello	确定协议/算法、服务器证书	提供身份、公钥、服务器随机数
客户端验证	检查证书链、签名等	确保服务器可信
客户端发密钥	预主密钥（公钥加密）	提供对称密钥基础
双方 Finished	使用生成的对称密钥验证通信	确保握手数据未被篡改，验证安全性

🚀 TLS 1.3 的简化（补充）

在 TLS 1.3 中：

握手步骤大幅简化，减少 RTT（延迟）
使用 前向安全（PFS） 的密钥交换方式（如 ECDHE）
默认启用 0-RTT 机制（复用旧会话密钥，提升性能）

✅ 总结一句话：

HTTPS 通过 TLS 握手在客户端和服务器之间建立一个安全的加密通道，实现数据机密性、完整性和身份认证，从而解决 HTTP 的安全问题。

rsa为什么存在前向安全问题，出现了ecdhe是怎么解决的？

🧠 一、什么是前向安全（Forward Secrecy, FS）？

前向安全指的是：即使服务器的私钥在未来某天被泄露，攻击者也无法解密之前已经截获的历史通信内容。

这是为了防止攻击者长期监听流量，等待服务器密钥泄露后“回放解密”所有历史数据。

❌ 二、为什么 RSA 密钥交换不具备前向安全？

在 TLS 1.0 ~ 1.2 中，如果使用 RSA 做密钥交换，其过程是这样的：

客户端生成 Pre-Master-Key（预主密钥）
用服务器的公钥（在证书中）加密
服务器用私钥解密得到密钥，双方计算对称密钥

⚠️ 问题出在哪里？

客户端生成的密钥是发送给服务器的加密数据，依赖服务器的 RSA 私钥来解密。
如果攻击者：
- 长期监听网络流量并保存（比如保存一个月的 HTTPS 数据包）；
- 之后通过黑客攻击拿到了服务器的私钥；
- 就可以将过去所有监听到的 pre-master key 解密，推导出对称密钥，解密所有历史通信内容！

👉 因此 RSA 密钥交换不具备前向安全性。

✅ 三、ECDHE 是如何实现前向安全的？

ECDHE = Elliptic Curve Diffie-Hellman Ephemeral（椭圆曲线临时密钥协商）

这是当前 HTTPS/TLS 主流使用的密钥交换方式，具备前向安全。

🧠 原理（简化解释）：

客户端和服务器各自生成一次性密钥对（临时的、每次握手都不同）
使用 Diffie-Hellman 算法 交换公钥，协商出共享的对称密钥
协商过程只依赖双方的临时密钥，不依赖服务器证书的私钥！

✅ 为什么它是前向安全的？

即使：

攻击者拿到了服务器私钥；
监听并记录了之前的通信数据；

也无法通过服务器私钥还原任何一次的临时密钥，因为临时私钥根本没传输、也没存储。

👉 每次握手生成的密钥都是一次性的、不可预测的。

🔐 四、RSA vs ECDHE 对比总结

特性	RSA 密钥交换	ECDHE 密钥交换（椭圆曲线 DH 临时）
是否前向安全	❌ 否	✅ 是
是否依赖服务器私钥	✅ 是	⚠️ 仅用于身份认证（签名）
每次握手密钥是否相同	✅ 是（固定）	❌ 否（每次随机生成）
是否支持双向匿名	❌ 不支持（需要证书）	✅ 支持匿名 DH（不推荐）
加密性能	一般	更快（椭圆曲线更高效）