Converge (YC S23) well-capitalized New York startup seeks product developers (runconverge.com)

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.

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.

The discovery:

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.

Why this matters:

1. Operator correctly runs: cat /dev/urandom > seed.bin

2. Filesystem corruption fills seed with nulls/spaces (happens in production)

3. Sunlight silently generates predictable keys from corrupted seed

4. CT log operates "normally" - valid signatures, no errors

5. Anyone knowing about corruption can recreate the private keys

Without checksums, even perfect operators get silently compromised. This is PKI infrastructure that protects HTTPS certificates.

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.

Google's response:

- "Not a vulnerability": https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ

- Published my private security report without consent

- Implemented my exact fixes hours later

  - https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663

  - https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d

- Banned me for pointing out the contradiction: https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ

Bonus vulnerability:

They authenticate using User-Agent strings. Anyone can spoof these headers to bypass rate limits and overwhelm the service:

- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176

- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148

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.

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.

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?

Comments (1)

data_yum_yum · 21h ago

Just stay away from the toxicity that’s bringing a cultural decline in the tech world. When it’s relevant, you can inform the right people that you can trust and suggest solutions.

Enough companies hand out bounties to people who catch security vulnerabilities, some just categorize per seriousness but some go far enough to have assessed existing problems and put out a list of them with specific dollar mounts they’re willing to hand out.

I think this is the way to go honestly - creates a community, remain transparent which buys immense trust, and have a pretty neat way to attract talent.

I think at this point it’s a no-brainer that lot of big tech companies are going through a cultural decline, which explains the layoffs. AI is just an excuse for layoffs :)