安全与密码学2017jhalderm.com
HTTPS 拦截的安全影响
The Security Impact of HTTPS Interception
进阶 · 约 40 分钟读完前置知识：TLS/HTTPS 基础、证书链与 CA、中间人攻击概念
导读
论文测量了现实网络中 HTTPS 中间人拦截（企业代理、杀毒软件等中间盒）的普遍程度与安全后果。作者在 Mozilla 更新服务器、一批电商站点和 Cloudflare CDN 三类网络上部署启发式检测，发现拦截率高达 4–11%，远高于此前估计；且被中间盒转发的流量中约 62% 安全性被削弱、58% 的连接存在严重漏洞（如不校验证书）。论文还指出，即使用户安装了本地根证书，浏览器也会跳过 public key pinning 的额外校验，因此 pinning 并不能阻止这类拦截。
HN 关注点：它用量化数据揭示了企业/杀毒软件 TLS 拦截的普遍性与实际危害，尤其是“本地根证书可绕过 pinning”这一反直觉细节，引发对默认安全策略和拦截产品责任的讨论。
后来怎么样
该研究成为 HTTPS 中间盒测量领域的基准工作，其数据常被用来论证企业代理和杀毒软件的 TLS 拦截会普遍削弱连接安全，并促使浏览器与安全社区重新审视本地根证书和 pinning 策略。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
补充证书 pinning 对本地安装的根证书不生效，这个默认行为应当告知用户。
论文第 2 页的一个注释让我很意外：与普遍看法相反，public key pinning 并不能阻止这种拦截。Chrome、Firefox 和 Safari 只有在证书链终止于浏览器或操作系统自带的 CA 时才强制执行 pin；如果证书链终止于本地安装的根证书（即管理员安装的 CA），这项额外校验就被跳过。我觉得这个默认行为很奇怪，至少应该提示用户——比如你在公司电脑上登录网银的时候。
simias查看英文原文
I was surprised by this note (on page 2): > Contrary to widespread belief, public key pinning [19] — an HTTPS feature that allows websites to restrict connections to a specific key — does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain terminates in a locally installed root (i.e., a CA certificate installed by an administrator). Seems like a strange default to me. I feel like the user should be notified of this, for instance if they're using a work computer to access their bank account or something like that.
支持引用论文结论：拦截率 4–11%，62% 流量安全性下降、58% 中间盒连接有严重漏洞。
结论部分说：他们在三类不同网络上部署启发式检测——(1) Mozilla Firefox 更新服务器，(2) 一批热门电商网站，(3) Cloudflare CDN——每种情况下发现的拦截都比此前估计高一个数量级以上，达 4–11%。作为一类产品，拦截手段大幅降低了连接安全性；最令人担忧的是，经过网络中间盒的流量中 62% 安全性被削弱，58% 的中间盒连接存在严重漏洞。他们调查了流行的杀毒软件和企业代理，发现几乎全部都会降低连接安全，许多还引入了漏洞（例如不校验证书）。
nailer查看英文原文
From the conclusion: > We deployed these heuristics on three diverse networks: > (1) Mozilla Firefox update servers, > (2) a set of popular e-commerce sites, and > (3) the Cloudflare content distribution network. > In each case, we find more than an order of magnitude more interception than previously estimated, ranging from 4–11%. > As a class, interception products drastically reduce connection security. Most concerningly, 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities. We investigated popular antivirus and corporate proxies, finding that nearly all reduce connection security and that many introduce vulnerabilities (e.g., fail to validate certificates).
补充呼吁制定“只阻断、不 MITM”的标准，避免强制客户安装 CA。
借机宣传我一直主张的观点：我们需要一套标准，让中间人可以实施阻断而不必做拦截（MITM），并提供更好的用户体验。这不能覆盖所有场景，但能解决我在 DNSFilter 的痛点：如果浏览器能识别我们的 SSL 证书，或证书里某个特殊字段，然后向用户展示阻断页面和了解详情的链接，我们就不必让客户安装我们的 CA 并 MITM 流量。我们目前还没这么做，也不希望这么做，但这似乎已是业界避免用户被证书错误搞糊涂的标准做法。
LogicX查看英文原文
I'll jump on my current soap box, which is that we need a standard to allow MITM blocking, without interception, and a nicer user experience. This won't solve all use-cases, but selfishly, It will solve mine at DNSFilter: If a browser could recognize our SSL cert, or a special field in our cert, and present the user with a block message, and a static link to learn more, it would eliminate the need for us to have our customers install a CA of ours, and MITM traffic. We have not yet done so, and I'd prefer not to, but it seems to be the industry standard way of avoiding users being confused by errors when we block/MITM an SSL site.
质疑为拦截辩护：实现得当的代理优于端点安全，关键是产品安全性和用户选择权。
拦截因为那些破烂安全产品而名声很差，这很可惜。是的，代理是薄弱环节；但如果实现得当、可信赖，它比端点安全更好，端点安全往往更糟。而且代理不应该装在端点本机上！如果做代理拦截的组织无法扫描流量，他们干脆直接丢包。与其采用完全不允许拦截的 MITM 缓解方案，不如改善用户体验（给用户选择权）和产品安全性。我自己有个小项目在写自用代理，想用来去广告、扫描和缓存下载——比起广告拦截插件和端点安全产品，我更信任自己写的 MITM 代理。
einrealist查看英文原文
Its sad that interception receives such a bad reputation because of broken security products. Yes, a proxy is a weak link. But if implemented properly and in a trustworthy way, then its better than having endpoint security, which is often worse. And no, the proxy does not belong on the endpoint itself! If organizations with proxy interception are not able to scan traffic, they will just drop the traffic. Instead of using MITM mitigations that don't allow interception at all, we need better user experience (with choice) and safe(r) products. I have a little side project where I try to implement a proxy for myself. I want to remove ads and be able to scan and cache downloads. I trust the adblock plugins and endpoint security products far less than a MITM proxy, I wrote myself.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖160 分 · 65 评
同领域还值得读
如何入侵一台已关机的电脑：在 Intel ME 中运行未签名代码
How to hack a turned-off computer, or running unsigned code in Intel ME
这篇 Black Hat 2017 白皮书讨论 Intel Management Engine（ME）的安全问题：如何在 ME 中运行未签名代码，以及攻破处于关机状态的电脑的相关…
安全与密码学2017 · 543 分 · 107 评专业 · 约 40 分钟编辑精选比特币：一种点对点的电子现金系统（2008）
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)
中本聪 2008 年发表的比特币白皮书，提出了无需可信第三方的点对点电子现金系统。
安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点
Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness
首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。
安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选Signal 消息协议的形式化安全分析
A Formal Security Analysis of the Signal Messaging Protocol
用形式化方法分析 Signal 消息协议（TextSecure）的安全性：作者在多阶段密钥交换模型下，借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…
安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选A2：模拟恶意硬件
A2: Analog Malicious Hardware
论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门，使其难以被常规检测发现。
安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选