HTTP/HTTPS 协议与 TLS

01 HTTP 协议基础：请求响应模型

上一篇你理解了 TCP 如何在不可靠的网络层之上构建可靠传输。HTTP（HyperText Transfer Protocol，超文本传输协议）运行在 TCP 之上，是 Web 通信的核心协议。它采用简单的请求-响应模型：客户端发请求，服务器回响应，一次交互完成。

这就像在餐厅点餐：你（客户端）看菜单后向服务员说"我要一份炒饭"（请求），服务员把订单传给厨房，厨房做好后服务员端回来（响应）。整个过程是一问一答，不会你还没点菜厨房就主动上菜。

HTTP 请求方法

请求方法告诉服务器客户端想做什么操作：

方法	含义	安全	幂等
GET	获取资源	是	是
POST	提交数据	否	否
PUT	更新资源	否	是
DELETE	删除资源	否	是

安全指不修改服务器数据（只读），幂等指多次执行结果相同。理解这两个属性对设计 RESTful API 至关重要——GET 请求绝不应有副作用，否则可能导致爬虫或预取机制意外修改数据。

HTTP 状态码

状态码是服务器对请求的处理结果，按首位数字分为五类：

范围	类别	常见状态码
1xx	信息性	100 Continue
2xx	成功	200 OK, 201 Created, 204 No Content
3xx	重定向	301 Moved, 302 Found, 304 Not Modified
4xx	客户端错误	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	服务器错误	500 Internal Error, 502 Bad Gateway, 503 Service Unavailable

💡 小贴士

从安全角度，401 和 403 经常被混淆。401 Unauthorized 表示"你是谁？"——需要身份认证（登录）；403 Forbidden 表示"我知道你是谁，但你没权限"——认证通过但授权失败。渗透测试中，从 401 变 403 说明认证已突破，剩下是权限提升。

02 HTTP 请求与响应结构详解

你已了解请求方法和状态码。现在深入 HTTP 报文的完整结构。HTTP 报文是纯文本格式，分为请求报文和响应报文，各自由三部分组成。

用 curl 观察完整请求响应

curl -v（verbose 模式）能同时显示请求和响应的完整报文：

Shell

curl -v http://httpbin.org/get > /dev/null

# > 开头是客户端发送的请求

# > GET /get HTTP/1.1

# > Host: httpbin.org

# > User-Agent: curl/7.88.1

# > Accept: */*

# < 开头是服务器返回的响应

# < HTTP/1.1 200 OK

# < Date: Sat, 09 Aug 2026 10:30:00 GMT

# < Content-Type: application/json

# < Content-Length: 198

# < Server: gunicorn/19.9.0

# { 响应体JSON数据... }

请求报文三部分

1 请求行：GET /get HTTP/1.1 — 方法 + URL路径 + 协议版本，一行搞定

2 请求头：键值对格式，每行一个。关键头包括 Host（目标域名）、User-Agent（客户端标识）、Cookie（会话凭证）

3 请求体：GET 请求通常没有体；POST/PUT 请求的体携带提交数据（JSON、表单等）

响应报文三部分

1 状态行：HTTP/1.1 200 OK — 协议版本 + 状态码 + 状态描述

2 响应头：Content-Type（数据类型）、Content-Length（体长度）、Set-Cookie（设置会话）

3 响应体：服务器返回的实际数据——HTML 网页、JSON 数据、图片二进制等

⚠️ 常见错误

在 GET 请求的 URL 中传递密码等敏感参数 — URL 会被记录在浏览器历史、服务器访问日志、代理日志中

✓ 正确：敏感数据放 POST 请求体中，并使用 HTTPS 加密传输。URL 中的参数（如 ?id=123）只用于非敏感的查询参数。

03 HTTPS：HTTP 的安全增强

你已经能读懂 HTTP 报文了。但 HTTP 有一个致命缺陷——所有数据都是明文传输。在餐厅点餐的比喻中，HTTP 就像在大堂大声喊出你的订单，旁边桌的人都能听到。HTTPS 则是把你和服务员请进包间，关上门再交流。

HTTP 的三大安全缺陷

窃听风险 HTTP 报文在网络中明文传输，Wi-Fi 抓包即可看到密码、Cookie 等敏感信息

篡改风险中间人可以修改报文内容，如在网页中注入广告或恶意脚本

伪造风险没有身份验证机制，攻击者可以伪造服务器，骗取用户输入的凭据

HTTPS = HTTP + TLS

HTTPS（HTTP Secure）并非新协议，而是在 HTTP 和 TCP 之间插入了一层 TLS（Transport Layer Security，传输层安全）。数据流向变为：HTTP → TLS 加密 → TCP 传输 → TLS 解密 → HTTP。

HTTP vs HTTPS 协议栈对比

HTTP

应用层：HTTP

传输层：TCP

网络层：IP

明文传输

HTTPS

应用层：HTTP

安全层：TLS

传输层：TCP

加密传输

两种加密的分工

HTTPS 使用两种加密方式配合工作，各取所长：

类型	原理	速度	用途
非对称加密	公钥加密，私钥解密	慢	TLS 握手阶段交换密钥
对称加密	同一密钥加解密	快	传输数据阶段批量加密

这个设计的精妙之处在于：非对称加密虽然安全但太慢，不适合加密大量数据；对称加密速度快但密钥如何安全传递是个问题。TLS 用非对称加密在握手阶段安全协商出一个对称密钥（会话密钥），之后的数据传输全部用这个对称密钥加密。一次慢速握手，换来全程快速加密。

04 TLS 握手过程：加密通道的建立

你已理解了 HTTPS 的加密原理。现在来看 TLS 握手的具体步骤。当前主流是 TLS 1.2（RFC 5246）和 TLS 1.3（RFC 8446），两者握手流程有显著差异。

TLS 1.2 握手流程

客户端

ClientHello（支持的加密套件、随机数）

服务器

↓

客户端

ServerHello + 证书 + ServerKeyExchange

服务器

↓

客户端

验证证书 + ClientKeyExchange + 切换加密

服务器

↓

客户端

服务器切换加密 + 开始加密通信

服务器

TLS 1.2 需要 2-RTT（2个往返时间）完成握手

核心步骤解读：

① ClientHello：客户端告诉服务器自己支持哪些加密算法、TLS 版本，并生成一个客户端随机数（Client Random）

② ServerHello + 证书：服务器选定加密算法，返回服务器随机数（Server Random）和数字证书（含公钥）

③ 密钥交换：客户端验证证书合法性后，生成预主密钥（Pre-Master Secret），用服务器公钥加密后发送。双方用三个随机数计算出会话密钥

④ 切换加密：双方互发 Finished 消息确认切换到加密通信，之后所有数据用会话密钥对称加密

TLS 1.3 的优化

TLS 1.3（2018年发布）大幅简化了握手流程，从 2-RTT 减少到 1-RTT，还支持 0-RTT 恢复模式：

特性	TLS 1.2	TLS 1.3
握手往返	2-RTT	1-RTT（恢复时 0-RTT）
密钥交换	RSA / DHE / ECDHE	仅 ECDHE（强制前向保密）
加密套件	数十种组合	精简为 5 种
安全性	部分套件不安全	移除所有不安全算法

💡 小贴士

前向保密（Forward Secrecy）是 TLS 1.3 的强制特性：每次连接使用临时密钥，即使服务器私钥日后泄露，过去已捕获的加密流量也无法被解密。TLS 1.2 中如果使用 RSA 密钥交换则没有前向保密——这也是 TLS 1.3 废弃 RSA 密钥交换的原因。

证书验证链

TLS 握手中服务器发送的证书不是自签的，而是由证书颁发机构（CA）签发的。验证过程形成一条信任链：

根CA
自签名

→

中间CA
根CA签发

→

网站证书
中间CA签发

浏览器/操作系统预装了根 CA 证书（信任锚）。验证时逐级检查签名：根 CA 签中间 CA → 中间 CA 签网站证书。只要根 CA 可信，整条链就可信。如果证书过期、域名不匹配、或签名链断裂，浏览器会显示安全警告。

05 实战分析：curl 与 openssl 工具

理论理解之后，用工具实际观察 HTTPS 和 TLS 握手过程。curl 和 openssl 是 Kali 中最常用的两个网络诊断工具。

curl 查看 TLS 握手详情

用 curl -v 访问 HTTPS 网站可以看到 TLS 握手的每一步：

Shell

curl -v https://www.example.com 2>&1 | head -20

# * Trying 93.184.216.34:443...

# * Connected to www.example.com

# * TLSv1.3 (OUT), TLS handshake, Client hello (1):

# * TLSv1.3 (IN), TLS handshake, Server hello (2):

# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

# * Server certificate:

# *  subject: CN=www.example.com

# *  start date: Jan 30 00:00:00 2026 GMT

# *  expire date: Mar  2 23:59:59 2027 GMT

可以看到连接使用了 TLS 1.3，加密套件为 TLS_AES_256_GCM_SHA384，以及证书的域名、有效期等信息。

openssl 查看证书链

openssl s_client 能展示完整的证书链：

Shell

echo | openssl s_client -connect www.example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# subject=C = US, O = Let's Encrypt, CN = www.example.com

# issuer=C = US, O = Let's Encrypt, CN = R3

# notBefore=Jan 30 00:00:00 2026 GMT

# notAfter=Mar  2 23:59:59 2027 GMT

# subject=网站域名 issuer=中间CA(R3)

# notBefore/notAfter=证书有效期范围

输出中 subject 是证书持有者（网站域名），issuer 是签发者（CA）。notBefore 和 notAfter 是有效期。渗透测试中检查证书的有效期、签发者和域名匹配是信息收集的重要步骤。

安全视角：HTTPS 常见攻击

降级攻击攻击者干扰握手过程，迫使双方使用较低版本的 TLS 或弱加密套件。防御：TLS 1.3 移除了降级机制，TLS_FALLBACK_SCSV 防止意外降级

中间人攻击攻击者伪造证书截获通信。防御：浏览器验证证书链和域名匹配，用户注意证书警告

证书伪造利用 CA 漏洞或社会工程获取合法证书。防御：Certificate Transparency（CT）日志公开所有签发的证书，可审计

✏️ 动手练习

🟢 基础验证

执行 curl -v https://www.baidu.com 2>&1 | head -30，找到输出中 TLS 版本和加密套件信息，记录网站证书的 CN（域名）和有效期。

🟡 组合应用

用 openssl s_client 分别连接 3 个不同的 HTTPS 网站，对比它们的证书签发者（issuer）、TLS 版本和加密套件。思考：为什么大型网站常用不同的 CA？证书有效期有什么规律？

🔴 开放挑战

用 curl 分别请求同一个网站的 HTTP 和 HTTPS 版本（如 http://example.com 和 https://example.com），用 tcpdump 抓包对比两种请求的报文内容。思考：在 HTTP 抓包中能看到什么明文信息？HTTPS 抓包中还能看到这些信息吗？