文章目录一、为什么 HTTP/HTTPS 是安全人的「必修课」二、HTTP 协议安全速览2.1 明文传输的风险2.2 无状态与会话2.3 安全相关 HTTP 头预览三、实验环境3.1 拓扑延续专栏 Host-Only3.2 受害机同时提供 HTTP 与 HTTPS3.3 打快照四、HTTP 抓包实战Wireshark4.1 本机直连抓包4.2 过滤器4.3 Follow HTTP Stream4.4 结合 ARP MITM 抓 HTTP4.5 HTTP 抓包分析清单五、HTTPS 基础TLS 在保护什么5.1 HTTPS HTTP TLS5.2 握手阶段TLS 1.2 简图5.3 SNI域名在加密前暴露六、HTTPS 抓包看不见内容时看什么6.1 无密钥时的分析价值6.2 识别弱配置七、HTTPS 解密实战三种合法路径7.1 方法一SSLKEYLOGFILE浏览器导出密钥7.2 方法二Burp Suite / mitmproxy代理 MITM7.3 方法三服务端私钥自有服务器7.4 三种方法对比八、Wireshark 解密操作详解8.1 配置 TLS 密钥日志8.2 验证解密成功8.3 常见问题九、证书陷阱全解析9.1 证书链与信任9.2 常见证书陷阱9.3 用户心理「有小锁就安全」9.4 渗透视角Burp 证书与主机名9.5 HSTS防降级的重要防线十、HTTP → HTTPS 迁移与安全加固10.1 全站 HTTPS 检查表10.2 nginx 强制跳转示例10.3 开发常见坑十一、蓝队如何发现异常 HTTPS11.1 主机侧11.2 网络侧11.3 日志十二、攻击链位置十三、完整实验步骤120 分钟十四、常见踩坑十五、法律与伦理十六、本篇小结附录 AWireshark 过滤器速查附录 Bcurl 证书调试附录 Cmitmproxy 快速命令附录 D与专栏前篇关联一、为什么 HTTP/HTTPS 是安全人的「必修课」上一篇 ARP 欺骗 把流量引到中间人后你第一眼看到的往往是HTTP或HTTPSARP MITM 成功 ├─► HTTP → 明文直接 Follow Stream └─► HTTPS → 密文但证书、握手、解密仍有大量学问场景协议攻击者能看到什么老旧内网系统HTTPURL、Cookie、密码、响应体现代网站HTTPS域名SNI、证书信息内容需解密配置错误HTTPS 忽略证书用户点「继续访问」 主动放弃保护企业审计HTTPS合法 MITM 代理解密需用户信任企业根证书本文覆盖三条线HTTP 抓包分析、HTTPS 解密实战、证书陷阱与防御。二、HTTP 协议安全速览2.1 明文传输的风险HTTP 报文以明文在网络上传输应用层二层 MITM 后可直接阅读GET /login HTTP/1.1 Host: 192.168.56.30 Cookie: sessionabc123 User-Agent: curl/8.0 HTTP/1.1 200 OK Set-Cookie: sessionxyz789; Path/敏感信息常见位置位置风险URL 查询参数?tokenxxx进访问日志Cookie会话劫持Authorization 头Basic 编码非加密等同明文响应体API 返回 token、个人信息2.2 无状态与会话HTTP 本身无状态靠Cookie / Session / JWT维持登录。攻击者嗅探到sessionCookie 即可会话劫持Session Hijacking无需知道密码。2.3 安全相关 HTTP 头预览头部作用Strict-Transport-SecurityHSTS强制 HTTPSSet-Cookie; Secure; HttpOnly; SameSite防窃听、防 XSS 读 Cookie、防 CSRFContent-Security-Policy限制脚本与资源加载X-Frame-Options防点击劫持HTTPS 篇会深入HTTP 抓包时先学会认这些头。三、实验环境3.1 拓扑延续专栏 Host-Only受害机 Ubuntu/nginx 192.168.56.30 HTTP :80 / HTTPS :443 Kali抓包/代理 192.168.56.10 分析机可选 本机 Wireshark 网段 192.168.56.0/243.2 受害机同时提供 HTTP 与 HTTPS# 安装 nginxsudoaptinstall-ynginx openssl# 自签名证书靶场用sudoopenssl req-x509-nodes-days365-newkeyrsa:2048\-keyout/etc/ssl/private/nginx-selfsigned.key\-out/etc/ssl/certs/nginx-selfsigned.crt\-subj/CN192.168.56.30# nginx HTTPS 站点片段sudotee/etc/nginx/sites-available/defaultEOF server { listen 80; server_name _; root /var/www/html; location / { try_files $uri $uri/ 404; } } server { listen 443 ssl; server_name _; ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; root /var/www/html; } EOFsudonginx-tsudosystemctl reload nginx测试页/var/www/html/index.htmlh1Lab HTTP/HTTPS/h1formaction/loginmethodpostinputnameuservalueadmininputnamepasstypepasswordvaluePssw0rd/formcurl-khttps://192.168.56.30curlhttp://192.168.56.303.3 打快照victim-web-clean/kali-clean四、HTTP 抓包实战Wireshark4.1 本机直连抓包在受害机或同网段 Kalisudowireshark-ieth1-fhost 192.168.56.30 and tcp port 80受害机浏览器访问http://192.168.56.30提交表单。4.2 过滤器目的过滤器只看 HTTPhttp指定主机ip.addr 192.168.56.30 http登录相关http.request.uri contains login含 Cookiehttp.cookie4.3 Follow HTTP Stream右键 HTTP 包 → Follow → HTTP Stream应看到 POST 体中的useradminpassPssw0rd——这就是 HTTP 明文的风险。4.4 结合 ARP MITM 抓 HTTPKali 双向 ARP 欺骗后见前篇sudoettercap-T-q-ieth1-Marp:remote /192.168.56.1// /192.168.56.30//sudowireshark-ieth1-fhost 192.168.56.30 and http受害机访问外网 HTTP站点靶场自建勿扫公网Kali 同样可 Follow Stream。4.5 HTTP 抓包分析清单□ 请求方法 GET/POST 是否合理 □ URL 是否带 token □ Cookie 是否 HttpOnly □ 是否混用 HTTP 加载 HTTPS 页面的资源混合内容 □ 响应码 302 跳转是否降到 HTTP五、HTTPS 基础TLS 在保护什么5.1 HTTPS HTTP TLS应用层 HTTP方法、路径、头、体 ↓ 加密 传输层 TLS 记录层密文 ↓ 网络层 TCPTLS 提供简化能力说明机密性对称加密保护内容完整性MAC/AEAD 防篡改认证证书链验证服务器身份5.2 握手阶段TLS 1.2 简图Client Server │ ClientHello套件、随机数 │ ├──────────────────────────────►│ │◄──────────────────────────────┤ ServerHello 证书 ServerKeyExchange │ ClientKeyExchange │ ├──────────────────────────────►│ │ ChangeCipherSpec Finished │ │◄──────────────────────────────┤ ChangeCipherSpec Finished │ Application DataHTTP 密文 │Wireshark 未配置密钥时握手可见Application Data 为密文。5.3 SNI域名在加密前暴露ClientHello 中含SNIServer Name Indication未加密前可见访问域名过滤器tls.handshake.extensions_server_name蓝队可用 SNI 做审计攻击者 MITM 时也需要正确 SNI 选证书。六、HTTPS 抓包看不见内容时看什么6.1 无密钥时的分析价值可见用途TLS 版本、套件弱套件排查证书 CN/SAN、颁发者是否自签、是否过期ALPNh2/http/1.1协议协商证书透明度、OCSP合规与吊销流量时序、大小元数据分析侧信道过滤器tls tls.handshake.type 1 # ClientHello tls.handshake.type 2 # ServerHello ssl.handshake.certificate # 证书旧版显示名6.2 识别弱配置· TLS 1.0 / 1.1 仍启用 · 套件含 EXPORT、RC4、3DES · 证书过期、hostname 不匹配七、HTTPS 解密实战三种合法路径解密前提你拥有密钥或用户信任你的 CA——靶场/授权渗透/本机调试非未授权窃听。7.1 方法一SSLKEYLOGFILE浏览器导出密钥适用本机 Chrome/Firefox 访问站点Wireshark 解密。步骤# 启动 Chrome 并写密钥日志exportSSLKEYLOGFILE/tmp/sslkeys.log google-chrome https://192.168.56.30# 或 chromium# WiresharkEdit → Preferences → Protocols → TLS# (Pre)-Master-Secret log filename → 选 /tmp/sslkeys.log# 重新打开抓包或 live captureApplication Data 可解密为 HTTP/2 或 HTTP/1.1原理浏览器把 TLS 会话密钥写入日志Wireshark 用同一密钥解密记录层。局限只能解本机该浏览器产生的流量不能解他人手机上的 HTTPS。7.2 方法二Burp Suite / mitmproxy代理 MITM适用渗透测试、API 调试客户端需信任 Burp/mitm 根证书。Burp 流程Kali 常见1. 启动 BurpProxy → 127.0.0.1:8080 2. 浏览器代理指向 Kali:8080 3. 访问 http://burp → 下载 CA 证书并导入系统/浏览器信任 4. 访问 https://192.168.56.30 → Burp 用自签证书冒充目标解密后重签转发mitmproxy 命令行mitmproxy --listen-host0.0.0.0 --listen-port8080# 客户端设代理 192.168.56.10:8080安装 mitm.it 证书流量路径 浏览器 ──TLS(信任mitm CA)──► mitmproxy ──TLS(信任真实站)──► 真实服务器 ↑ 此处明文 HTTP与 ARP 欺骗组合靶场ARP 把流量引到 Kali再配合透明代理或 WPAD —— 见专栏后续 SSL 剥离篇。7.3 方法三服务端私钥自有服务器若你控制 nginx 且持有/etc/ssl/private/nginx-selfsigned.keyWireshark → TLS → RSA keys list → 添加 IP:443 私钥文件仅适用于RSA 密钥交换的旧套件现代 TLS 1.3 / ECDHE前向保密无法用长期私钥批量解密历史流量只能逐会话拿密钥KEYLOG 或代理。7.4 三种方法对比方法谁信任谁典型场景SSLKEYLOGFILE本机浏览器开发调试、协议学习Burp/mitmproxy用户导入攻击者 CA授权渗透、QA 测 API服务端私钥仅 RSA 旧握手自有服务器日志分析八、Wireshark 解密操作详解8.1 配置 TLS 密钥日志Edit → Preferences → Protocols → TLS (Pre)-Master-Secret log filename: /tmp/sslkeys.log抓包后应出现Decrypted TLS或下层HTTP协议树。8.2 验证解密成功过滤器http ip.addr 192.168.56.30能看到GET /、POST /login即成功。8.3 常见问题现象原因仍全是 Application Data密钥日志路径错、抓包与浏览器不是同一会话只解了部分包抓包开始晚于握手需从头抓或 KEYLOG 持续写HTTP/2 显示乱码需启用 HTTP/2 解析Follow HTTP/2 Stream九、证书陷阱全解析HTTPS 安全高度依赖PKI公钥基础设施与用户是否验证证书。9.1 证书链与信任根 CA内置在系统/浏览器 └─► 中间 CA └─► 站点证书CN/SAN 域名验证项包括签名有效、未过期、域名匹配、链完整、未吊销OCSP/CRL。9.2 常见证书陷阱陷阱表现攻击/风险自签名证书浏览器大红警告用户点「继续」→ MITM 可同样自签域名不匹配CNfoo.com 访问 bar.com钓鱼站、错误配置过期证书NET::ERR_CERT_DATE_INVALID运维疏忽用户习惯忽略警告弱 CA 被入侵合法链但恶意签发历史案例DigiNotar企业透明代理安装公司根证书合法审计 vs 隐私争议免费证书滥用Let’s Encrypt 自动签发钓鱼站也能有「小锁」证书固定绕过移动端无用户确认需逆向/Hook难度高9.3 用户心理「有小锁就安全」误区 1HTTPS 网站可信只保证传输加密与身份核验流程不保证站非钓鱼 误区 2警告页点「高级 → 继续」无后果等于信任未知证书 误区 3HTTP 页面里的登录框「也算安全」表单可 HTTP POST 明文蓝队话术培训用户绝不在证书警告页继续访问生产系统。9.4 渗透视角Burp 证书与主机名Burp 为https://192.168.56.30动态签发证书SAN 含该 IP/域名。若客户端未导入 Burp CA浏览器报错您的连接不是私密连接导入后地址栏仍显示锁信任的是 Burp CA不是 DigiCert这就是授权 MITM与SSL 剥离的前置条件下一篇 SSL 剥离会展开。9.5 HSTS防降级的重要防线服务器发送Strict-Transport-Security: max-age31536000; includeSubDomains浏览器在max-age内强制 HTTPS拒绝用户改 HTTP。首次访问仍可能被 MITM无 HSTS 缓存时——见HSTS Preload列表。检查curl-sIhttps://某站|grep-istrict十、HTTP → HTTPS 迁移与安全加固10.1 全站 HTTPS 检查表□ 80 端口 301 跳转 443 □ 所有资源 https 加载无 mixed content □ HSTS 考虑 preload □ CookieSecure; HttpOnly; SameSiteLax/Strict □ 禁用 TLS 1.0/1.1优先 TLS 1.2 □ 证书自动续期acme.sh / certbot10.2 nginx 强制跳转示例server { listen 80; server_name lab.local; return 301 https://$host$request_uri; }10.3 开发常见坑坑后果API 走 HTTP内网 MITM 直接读 token移动端忽略证书校验TrustAllCerts类库 关闭 HTTPS测试环境自签证书进生产用户学会点「继续」十一、蓝队如何发现异常 HTTPS11.1 主机侧· 是否安装了未知根证书企业代理除外 · 系统代理是否被改为 8080 · hosts 文件是否被改11.2 网络侧· 同一内网 IP 对多目标 TLS 且证书颁发者异常一致批量 MITM · JA3/JA3S 指纹突变恶意代理工具特征 · DNS 解析到内网 IP 却声称公网域名11.3 日志Web 服务器access.log中 HTTP 明文请求WAF 记录 TLS 版本与套件。十二、攻击链位置ARP 欺骗 / DNS 劫持 └─► HTTP 明文嗅探无需证书 └─► HTTPS ├─► 诱骗用户忽略证书警告 ├─► 导入恶意根证书社工/恶意软件 ├─► Burp/mitmproxy授权测试 └─► SSL 剥离专栏第 15 篇十三、完整实验步骤120 分钟□ 1. nginx 同时开 80/443自签证书 □ 2. Wireshark 抓 HTTPFollow Stream 看 POST 密码 □ 3. 抓 HTTPS确认 Application Data 密文 □ 4. 分析 ClientHello 中 SNI、证书链 □ 5. SSLKEYLOGFILE Chrome 访问Wireshark 解密 HTTPS □ 6. mitmproxy 8080受害机设代理并安装 mitm.it 证书复现解密 □ 7. 不安装证书访问 HTTPS记录浏览器警告页 □ 8. 安装后对比「锁」的变化理解信任的是 mitm CA □ 9. 配置 HSTS 头观察 HTTP 是否被浏览器自动升 HTTPS □ 10. 撰写实验报告明文风险 解密条件 证书陷阱十四、常见踩坑问题解决Wireshark 解不出 HTTPS确认 KEYLOG 与抓包同会话检查 TLS 协议设置mitmproxy 证书装错用户Android 7 用户证书不被 app 信任需系统证书或调试curl -k 习惯测试可用生产脚本勿-k只抓 lo 看不到 VM在 Kali eth1 或受害机本机抓HTTP/2 在 Wireshark 显示差用 Follow HTTP/2 或导出到 Burp认为 TLS 1.3 能拿私钥解密ECDHE 前向保密历史流量不可逆十五、法律与伦理✅ 允许自有 VM、本机 KEYLOG、授权渗透中 Burp、企业授权审计 ❌ 禁止咖啡厅 WiFi 抓他人 HTTPS、未授权部署透明代理 ❌ 禁止伪造银行证书钓鱼企业 MITM需告知员工并符合当地隐私法规GDPR、个保法等。十六、本篇小结┌─────────────────────────────────────────────────────────────┐ │ HTTP/HTTPS 核心记忆 │ ├─────────────────────────────────────────────────────────────┤ │ HTTP 明文 → MITM 直接读 Cookie/密码 │ │ HTTPS 密文 → 握手/证书可见内容需密钥或用户信任代理 CA │ │ 解密三路径KEYLOG、Burp/mitmproxy、RSA 服务端私钥旧 │ │ 证书陷阱自签、过期、名不符、用户点「继续」 │ │ HSTS 防降级全站 HTTPS Secure Cookie 是基线 │ └─────────────────────────────────────────────────────────────┘下一篇预告《TLS 1.3 握手过程动画级讲解 Wireshark 验证》——逐字段对照 ClientHello/ServerHello把加密协商看懂。附录 AWireshark 过滤器速查http http.request.method POST http.cookie contains session ip.addr 192.168.56.30 tcp.port 443 tls tls.handshake.extensions_server_name tls.alert_message附录 Bcurl 证书调试# 查看证书链curl-vIhttps://192.168.56.3021|grep-A5Server certificate# 指定 CA 文件curl--cacert/path/to/ca.crt https://lab.local# 测试靶场跳过校验 — 勿用于生产curl-khttps://192.168.56.30附录 Cmitmproxy 快速命令# 交互界面mitmproxy-p8080# 无界面保存mitmdump-p8080-wflows.mitm# 指定上游链式mitmproxy--modeupstream:http://corp-proxy:3128附录 D与专栏前篇关联前篇关联ARP 欺骗MITM 后抓 HTTP/注入代理Wiresharkhttp、tls过滤器DNS 安全假 IP 假证书钓鱼链靶场搭建56.30 nginx 实验机