HTTPS中间人检测 （上篇 · 威胁机理与协议防护）

01 · 研究定位与威胁模型

1.1 为什么研究HTTPS中间人检测——迪妙的三个业务理由

TLS加密保护的是"端到端"的信道，但真实的通信链路从来不是只有两端。Wi-Fi接入点、家用路由器、企业网关、安全审计设备、被植入木马的终端——每一个环节都可能成为攻击者插入的"第三端"。对迪妙网络空间安全学院深耕的反钓鱼、反诈骗与企业安全意识培训业务，MITM检测具有不可替代的价值：

• 对抗性钓鱼已进入"AiTM时代"。以Evilginx为代表的中介式钓鱼（Adversary-in-the-Middle, AiTM）框架，不再仿造登录页面骗取口令，而是架设真实的反向代理，转发目标站点的真实页面与交互，实时截获用户提交的一切——包括用户名、密码，以及能绕过MFA的一次性验证码与会话Cookie。微软威胁情报团队2022年披露，AiTM钓鱼站点已成为商业电子邮件入侵（BEC）链条的标准入口。传统"看网址、认小锁"的培训话术对此类攻击基本失效，防御必须深入到证书与流量层面。
• 企业演练沙盘需要真实水位。MITRE ATT&CK将"中间人攻击"（T1557）及其子技术（LLMNR/NBT-NS投毒、ARP缓存投毒、DHCP欺骗）列为持久化与凭据窃取的标准战术。红蓝对抗若不能在实验环境中复现SSL剥离、透明代理与证书注入，演练的检测侧将永远停留在纸面。
• 加密可见性危机的另一面。TLS 1.3与ECH（RFC 9849，2026年3月发布）让被动观测者"失明"，但本地MITM恰恰是少数仍能让明文"重现"的攻击——代理为了解密必须出示自己的证书。这一结构性矛盾是全部MITM检测技术的立足点：攻击者要想看见明文，就必须在证书与握手行为上留下指纹。

1.2 攻击者位置四分法：MITM威胁模型的结构化描述

按照攻击者在通信路径上的位置与所需能力，HTTPS中间人攻击可划分为四类。这一分类直接决定了每类攻击的检测点部署位置与数据需求：

注：P1/P2是终端安全与内网检测的主战场；P3是运营商与大规模测量研究的范畴；P4则是反钓鱼业务最直接面对的形态——用户主动访问了攻击者控制的域名，该域名的证书、行为与真实站点存在可比对差异。

1.3 研究边界与合规声明

02 · SSL剥离攻击：加密降级的古典威胁

2.1 机理：把HTTPS"劝退"回HTTP

2009年，Moxie Marlinspike在Black Hat DC上公开演示了sslstrip：位于路径上的攻击者并不尝试破解TLS，而是改写受害者的请求——当用户点击http://链接或被重定向到HTTP页面时，攻击者将其与目标服务器的HTTPS通信内容"翻译"回HTTP转发给用户；用户与攻击者之间全程明文，攻击者却与服务器维持着正常的加密会话。用户看到的是"一切正常"的页面，浏览器地址栏却没有任何安全指示器。

• 攻击成立的根因：当时Web生态大量混用HTTP/HTTPS，用户常从搜索引擎、书签、二维码进入HTTP入口，再经服务器跳转HTTPS——这条"明文入口→跳转"的路径就是SSL剥离的猎场。
• 同源策略的盲区：页面中的Cookie若不设Secure标志，剥离攻击下会被明文泄露；攻击者甚至可主动将HTTPS链接改写为HTTP同类链接（如https://bank.com → http://bank.com），保持视觉一致性。

2.2 HSTS的问世与残余攻击面

HSTS（HTTP Strict Transport Security，RFC 6797，2012年11月发布）从协议层面封堵SSL剥离：服务器通过Strict-Transport-Security响应头声明"本域在未来N秒内只允许HTTPS访问"，浏览器收到后强制升级该域所有请求并拒绝证书错误。其工作流程如下：

HSTS的残余攻击面值得学员明确：首次访问窗口（策略尚未下发时仍走明文，Preload机制正是为消除此窗口而设计）；子域覆盖依赖includeSubDomains；用户主动忽略证书警告在现代浏览器中已不可行——HSTS下证书错误直接断连，这正是检测MITM的天然放大器：合法的透明代理若未被信任，表现为"全站证书错误"；若被信任，则进入第3节的检测范畴。

2.3 SSL剥离的当代猎场：古典攻击并未退场，只是换了入口

HSTS与Preload大幅压缩了SSL剥离在主流浏览器上的生存空间，但在以下场景中，"加密降级+明文猎杀"的攻击逻辑依然活跃：

• 恶意热点与Evil Twin接入点：攻击者在机场、咖啡馆等场景架设同名钓鱼热点，结合ARP欺骗与HTTP流量篡改，对未启用HSTS的站点注入恶意脚本——这与迪妙钓鱼演练中"免费Wi-Fi"剧本的技术内核完全一致。
• 二维码钓鱼（Quishing）与短信短链：扫码与短链天然削弱了域名可读性，受害者往往在不可见的跳转链路中被引导至HTTP入口或仿冒域名；攻击者甚至无需剥离——直接以AiTM代理承接流量（见第3页08节），SSL剥离退居"引流"角色。
• App内WebView与嵌入式浏览器：大量移动应用的内置浏览组件不强制应用HSTS策略，"首次访问窗口"被系统性放大——这也是移动端检测必须同时审计应用网络配置的原因（见第2页06.3节）。
• 强制门户（Captive Portal）滥用：公共网络认证页是少数合法的HTTP明文入口，恶意热点可借此展示伪造认证页实施凭据钓鱼。

03 · 透明TLS代理：加密世界的"持证窃听者"

3.1 双重握手：MITM的核心机理

透明TLS代理（Transparent TLS Proxy）不降级连接，而是同时扮演客户端与服务器，建立两条独立的TLS会话：与目标服务器维持一条真实加密会话，再使用代理自己签发的"假冒证书"与受害者建立另一条会话。明文在此汇聚——代理所见即全部通信内容。整个过程中，密码学本身未被攻破：用户看到的"小锁"对应的不是目标站点的真实证书，而是代理的证书。

3.2 证书链的结构性变化：检测的第一个信号

正常HTTPS连接的证书链通常为2–3层：叶子证书（目标域名）→ 中间CA → 根CA。透明代理插入自己后，链结构发生可观测的系统性变化：

注：TLS 1.3下证书链位于加密握手段，被动观测点需位于终端侧或授权检查点；TLS 1.2存量流量中证书明文可见，链深度检测仍可直接部署。

04 · 根证书注入：MITM攻击的"信任基石"

4.1 三条注入路径

透明代理能否生效，最终取决于受害者的信任库是否接纳代理的根证书。真实攻击与合法场景中，根证书的落地方式可归为三类：

• 恶意注入：木马、间谍软件在取得终端执行权限后，调用系统证书管理接口静默安装自签根证书（Windows证书存储、macOS钥匙串、Linux CA目录、Android用户证书库、浏览器自有信任库均可能被写入）；配合代理设置篡改或流量牵引，形成完整MITM链。2015年联想Superfish事件即是典型——预装广告软件内置Komodia开发的拦截组件，自签根证书且私钥可被公开提取，使全球数百万台设备对同一伪造CA敞开了大门。同年11月曝光的戴尔eDellRoot事件（CERT/CC漏洞通报VU#870761）是供应链环节的同类失误：戴尔在2015年8月后出货的部分PC上通过Dell Foundation Services预装了携带私钥的自签根证书eDellRoot，私钥可被公开提取，任何网络位置的攻击者均可据此为任意域名签发"合法"的伪造证书——再次证明终端信任库审计必须覆盖出厂预装与供应链环节。
• 企业受管下发：组织通过MDM/组策略向自有设备推送内部根证书，配合网关代理进行合规TLS检查。这是合法的，但管理不善时（私钥泄露、范围越界、豁免清单缺失）会自我制造一条完整的攻击面。
• 用户诱导安装：钓鱼页面、伪装的"安全组件""上网助手"诱导用户手动安装根证书。iOS对企业证书与根证书的安装有多重弹窗确认，安卓自7.0（API 24）起应用默认不信任用户安装的证书——这些机制抬高了攻击成本，但浏览器与老旧应用仍是缺口。

05 · HSTS与降级防护的现代形态

5.1 HSTS部署现状与策略要点

HSTS已从"最佳实践"演进为合规基线：Qualys SSL Labs评分体系将HSTS作为A+评级的前提条件；浏览器Preload名单（hstspreload.org）收录了全球大量金融、政务、互联网站域名，使策略在下发前就内置于浏览器。企业侧部署的要点包括：

• 策略强度：max-age建议≥1年（31536000秒），并启用includeSubDomains与preload声明；仅设短max-age的策略在攻击者长期驻留场景下可被"过期重置"。
• 证书生命周期纪律：HSTS下任何证书失效、轮换失误都直接变成业务中断——这倒逼企业建立自动化证书管理（ACME），也从侧面压缩了"长有效期伪造证书"的可行空间。
• 证书有效期持续收紧：CA/B论坛基线要求正分阶段压缩公开可信TLS证书的最长有效期——2026年3月15日起新签发证书最长约200天，2027年3月起降至约100天，2029年3月起仅约47天。证书"短寿命化"使伪造证书的可利用窗口同步收窄，也把证书自动化管理（ACME）从"推荐实践"变为"生存刚需"。
• 与客户端检测的联动：企业探测到内部站点证书错误率异常升高时，应排查是否存在私接代理或内网ARP欺骗，而非简单归因于配置失误。

5.2 降级攻击的现代变体

SSL剥离并未消失，而是演化出更精细的形态：TLS版本降级（诱导协商至TLS 1.0/1.1与弱密码套件——TLS 1.3的降级哨兵随机数即针对此设计）；SNI窥探驱动的选择性拦截（中间盒先按明文SNI决定是否拦截，再对目标连接实施剥离或重置）；降级至攻击者控制的"镜像站"（AiTM钓鱼的本质——用户从未抵达真实站点，自然也无从谈论降级）。

5.3 降级攻击族谱：POODLE、FREAK与Logjam

SSL剥离之外，历史上还有一整族利用"协议版本与密码套件协商"的降级攻击，其根源多在密码政策与实现缺陷的历史遗留：

• POODLE（CVE-2014-3566，2014年10月披露）：SSL 3.0的CBC填充校验缺陷构成可重复使用的预言机，攻击者诱导连接降级至SSL 3.0后，通过多次自适应攻击每次窃取少量字节。事件直接促成RFC 7568（2015）宣布废弃SSL 3.0，主流浏览器与服务器同步禁用该版本。
• FREAK（CVE-2015-0204，2015年3月披露）：上世纪90年代密码出口管制遗留的512位RSA"出口级"密码套件，被发现在OpenSSL等主流实现中仍可被强制协商；对512位RSA模数的分解在当时公有云算力下仅需数小时至数日。Android与iOS的系统组件均受影响并紧急修复。
• Logjam（CVE-2015-4000，2015年5月披露）：针对512位出口级DHE的预计算攻击——研究者预先计算常用素数的离散对数表，即可实时解密受影响连接；研究同时揭示了互联网上大量服务器复用相同硬编码DH参数的系统性风险，并据此下调了DHE参数的安全基线。

5.4 被忽视的降级面：邮件协议的STARTTLS剥离

Web生态有HSTS与Preload兜底，而邮件链路长期依赖"机会式加密"：SMTP、IMAP、POP3先以明文完成协议握手，再由服务器广告STARTTLS升级能力，客户端择机升级。这恰好复刻了SSL剥离的全部条件——中间人只需在握手阶段抹除STARTTLS广告，双方即全程明文而互不知晓；更隐蔽的变体则利用协议状态机缺陷直接阻止升级。

• 测量证据：ACM IMC 2015邮件投递安全大规模测量（Durumeric、Adrian等，密歇根大学与Google联合团队）首次系统揭示了SMTP链路的机会式加密水位：相当比例的邮件服务器虽广告STARTTLS能力，但证书校验普遍缺位——"加密"形同明文；研究者在部分网络路径的主动测量中还观测到STARTTLS能力广告被剥离、TLS专用端口被阻断的主动干扰迹象。
• 实现层缺陷：USENIX Security 2021对STARTTLS实现的系统审计（Poddebniak等）披露了40余处可被用于剥离、降级与命令注入的客户端/服务器实现缺陷（研究者已通报主流邮件客户端与服务器厂商，多数问题随后修复），并给出明确结论——在客户端到服务器方向应优先使用隐式TLS专用端口，而非STARTTLS。
• 协议对策：IETF在RFC 7435（机会式安全）与RFC 8314（邮件提交与访问强制使用TLS）中确立了方向；SMTP侧以MTA-STS（RFC 8461）公布防降级策略、以DANE/TLSA（RFC 6698/7671/7672）经DNSSEC把证书绑定到域名——两者合起来，就是邮件世界的"HSTS"。

5.5 浏览器安全指示器的演进：当"小锁"消失之后

"看地址栏有没有小锁"曾长期是安全教育的一线话术。但浏览器厂商的用户研究表明，这一指示器已被普遍误读：Google 2021年的用户研究中，仅约11%的受试者能正确理解挂锁图标的含义，多数受访者错误地把它当作"网站可信、经营合规"的标志；而此时Chrome中超过95%的页面加载已走HTTPS——攻击者的钓鱼网站同样使用HTTPS、同样显示小锁。FBI等执法机构在2023年的公众指南中明确提示：挂锁图标只表示通信加密，并不代表网站合法或安全。

2023年9月发布的Chrome 117正式将地址栏挂锁替换为中性化的"Tune（调整）"图标——新图标不再暗示"可信"，但保留点击后查看证书与站点信息的入口；HTTP明文页面则继续被明确标记为"不安全"。同期的自动升级机制也在普及：Chrome的HTTPS-First模式（2021年随Chrome 94引入，可将可升级的HTTP请求自动改写为HTTPS）与Firefox的HTTPS-Only模式（Firefox 83起提供，可对不支持HTTPS的站点先给出风险提示）分别从浏览器侧压缩了"明文入口"的存在空间。

06 · 证书固定的演进：从HPKP之死到移动Pinning

6.1 HPKP：一次失败的浏览器级实验

公钥固定（HPKP，RFC 7469，2015）曾被视为MITM的终极协议解：站点通过HTTP头声明"未来N天内，本域证书必须来自这几个公钥"，违例即断连。但实践迅速暴露致命缺陷——固定策略即自锁：私钥丢失、CDN切换、业务并购都会触发合法的"自我拒绝服务"；而攻击者一旦攻破站点响应头，又可植入恶意pin将合法用户永久锁定在伪造证书之外。2017年Chrome宣布废弃HPKP，Chrome 67（2018年5月）起移除公钥固定支持；Firefox虽在早期版本试点但从未完整落地该功能，先于Firefox 72（2020年1月）默认关闭HPKP响应头处理，再在Firefox 78（2020年）彻底移除相关代码路径（见Mozilla Bug 1412438与1630038），苹果与微软的浏览器则从未实现过HPKP。RFC 7469事实上走入历史。

6.2 现代实践：应用层Pinning与平台机制

• 移动端证书固定：银行、证券类App普遍在客户端内置服务端证书公钥哈希（SPKI Pin），握手时强校验，违例即拒绝连接并上报——这是当前对抗恶意MITM最有效的主机侧手段。Android通过Network Security Config提供声明式配置能力，iOS的App Transport Security（ATS）提供了策略框架，OWASP MASTG给出了完整的实现与测试指引。
• 浏览器侧的替代路线：Chrome放弃HPKP后，将信任重心转向证书透明度（CT，RFC 6962）——所有公开可信证书必须被记录到公开CT日志，Chrome等浏览器要求SCT证明；"事后可审计"取代了"事前硬拒绝"。对于检测方而言，CT日志同时成为发现伪造证书与异常签发的基础设施（详见第2页主动探测与第3页案例复盘）。
• 证书固定的攻防双面性：pinning抬高了攻击成本，但也带来证书轮换的运维负担与潜在自锁风险；安全团队应将其定位为"高价值App的补充防线"，而非银弹，并配套备份pin（backup pin）与灰度验证流程。

本页小结

本节参考文献（第1页 · [1]—[20]）