告诉 HN：谷歌声称“未受影响”，数小时后悄悄修复，未作说明
2 分•作者: Eikon•7 个月前
证书透明度系统可以保护您免受恶意 HTTPS 证书的侵害。当 CT 日志拥有可预测的私钥时，整个 Web PKI 安全模型就会崩溃。
这将危及该日志签署的每一个证书——过去、现在和未来。
我报告了 Google Chrome 信任的证书透明度基础设施中的安全漏洞。他们将其驳回为“不是漏洞”，未经同意就公开了我的私人报告，然后在几个小时后默默地实施了我的修复方案。
发现：
在基准测试过程中，我使用了 echo " " > seed.bin (32 个空格)。Sunlight 接受了这一点，并为 CT 日志生成了有效但可预测的私钥。没有警告，没有错误。
为什么这很重要：
1. 操作员正确运行：cat /dev/urandom > seed.bin
2. 文件系统损坏，用空值/空格填充种子（发生在生产环境中）
3. Sunlight 从损坏的种子中默默地生成可预测的密钥
4. CT 日志“正常”运行——有效的签名，没有错误
5. 任何知道损坏的人都可以重新创建私钥
如果没有校验和，即使是完美的操作员也会被默默地攻破。这是保护 HTTPS 证书的 PKI 基础设施。
这并非假设——文件系统损坏在生产系统中很常见。断电、内核崩溃和存储故障经常会导致部分写入和空字节。
谷歌的回应：
- “不是漏洞”：https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ
- 未经同意就发布了我的私人安全报告
- 几个小时后实施了我的确切修复方案
- https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663
- https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d
- 禁止我指出矛盾：https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ
额外漏洞：
他们使用 User-Agent 字符串进行身份验证。任何人都可以伪造这些标头来绕过速率限制并压垮服务：
- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176
- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148
这是生产代码，今天被 Google Chrome 信任 (https://www.gstatic.com/ct/log_list/v3/all_logs_list.json) 请参阅“sunlight”日志。
导致我被禁的电子邮件就在这里 https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ - 请您自己判断它是否违反了任何合理的行为准则。
还有其他人因为负责任的安全披露而遭到报复吗？我们如何修复一个报告漏洞会被禁止而问题却被悄悄修补的系统？
查看原文
The Certificate Transparency system protects you from malicious HTTPS certificates. When CT logs have predictable private keys, the entire web PKI security model breaks down.
This compromises every certificate the log ever signed - past, present, and future.<p>I reported security vulnerabilities in Certificate Transparency infrastructure that Google Chrome trusts. They dismissed them as "not vulnerabilities," made my private report public without consent, then silently implemented my fixes hours later.<p>The discovery:<p>While benchmarking, I used echo " " > seed.bin (32 spaces). Sunlight accepted this and generated valid but predictable private keys for a CT log. No warnings, no errors.<p>Why this matters:<p>1. Operator correctly runs: cat /dev/urandom > seed.bin<p>2. Filesystem corruption fills seed with nulls/spaces (happens in production)<p>3. Sunlight silently generates predictable keys from corrupted seed<p>4. CT log operates "normally" - valid signatures, no errors<p>5. Anyone knowing about corruption can recreate the private keys<p>Without checksums, even perfect operators get silently compromised. This is PKI infrastructure that protects HTTPS certificates.<p>This isn't hypothetical - filesystem corruption is common in production systems. Power failures, kernel panics and storage failures regulary cause partial writes and null bytes.<p>Google's response:<p>- "Not a vulnerability": https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ<p>- Published my private security report without consent<p>- Implemented my exact fixes hours later<p><pre><code> - https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663
- https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d</code></pre>
- Banned me for pointing out the contradiction: https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ
Bonus vulnerability:<p>They authenticate using User-Agent strings. Anyone can spoof these headers to bypass rate limits and overwhelm the service:<p>- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176<p>- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148<p>This is production code, trusted by Google Chrome today (https://www.gstatic.com/ct/log_list/v3/all_logs_list.json) see the "sunlight" logs.<p>The exact email that got me banned is here https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ - judge for yourself if it violates any reasonable code of conduct.<p>Has anyone else experienced retaliation for responsible security disclosure? How do we fix a system where reporting vulnerabilities gets you banned while the issues get quietly patched?