告诉HN：谷歌表示“没有漏洞”，几个小时后修复但未注明出处
证书透明度系统保护您免受恶意HTTPS证书的侵害。当CT日志具有可预测的私钥时，整个网络公钥基础设施（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
额外的漏洞：
他们使用用户代理字符串进行身份验证。任何人都可以伪造这些头信息，以绕过速率限制并压垮服务：
- 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?