Pwned Certificates on the Fediverse

https://www.hezmatt.org/~mpalmer/blog/2024/01/16/pwned-certificates-on-the-fediverse.html

by JNRowe • 3 years ago

103 19 3 years ago

hunter2_2• 3 years ago

I stopped sending compromised key notifications to CAs. Instead, now I’m publishing the details of compromised certificates to everyone, so that users can protect themselves directly

If this is most feasible, ok, though it smells like the opposite of responsible disclosure. Perhaps I'm just not in tune with the nature of how this threat differs from a typical software vulnerability, and therefore the responsible disclosure method I'm familiar with is irrelevant.

doesnt_know• 3 years ago

The surrounding text explains that several CAs didn’t like having to spend resources doing revocations and intentionally made the disclosure process more onerous.

Responsible disclosure is a courtesy that should not be extended to bad faith actors.

profmonocle2• 3 years ago

though it smells like the opposite of responsible disclosure

He's not sharing the key itself, just proof that it's been leaked. Unlike disclosing a security issue without warning, this disclosure doesn't give any bad actors and power they didn't already possess. (Because any bad actors who have the key would already know what TLS certs it matches, or could trivially find out by querying CT logs themselves.)

hunter2_2• 3 years ago

Thank you!

hsbauauvhabzb2• 3 years ago

Even with the key, from what I can tell it’s fairly hard to exploit for the average netizen.

some_furry• 3 years ago

If this is most feasible, ok, though it smells like the opposite of responsible disclosure.

Read: https://adamcaudill.com/2015/11/19/responsible-disclosure-is...

profmonocle2• 3 years ago

However, several CAs disliked having to revoke all those certificates, because it cost them staff time (and hence money) to do so. They went so far as to change their procedures from the standard way of accepting problem reports (emailing a generic attestation of compromise), and instead required CA-specific hoop-jumping to notify them of compromised keys.

Maybe the baseline requirements need to be updated to require an automated mechanism for reporting key compromises. CAs have to revoke certs with compromised keys, but by going out of their way to increase the barrier to doing so, they're clearly not complying in good faith.

The ACME protocol (Let's Encrypt) makes this simple - just sign a request to the revocation API with the cert's private key.

hsbauauvhabzb2• 3 years ago

I’m unsure what part of revoking certificates is labor intensive if you’re a certificate authority, given your entire purpose is to sign and revoke keys..

wiml• 3 years ago

I get the impression that some of the big name CAs are ... not very technology oriented, you might say. They focus on the sales side, and treat the actual issuance and revocation of certificates as an unfortunate cost center and minimize investment.

alphager• 3 years ago

The CAs have automated signing and have zero labor in that part. Revoking is a manual process, infinitely more labor intensive.

viraptor• 3 years ago

You need to notify the customer and then deal with the support work when they roll the key. Also they will get some blame from the customer for having to deal with the situation. All that without much extra payment. It's much more profitable to not care.

tgsovlerkhgsel• 3 years ago

Most of their process is 100% automated. Revoking based on free-form reports would at the very least require a human to deal with the report.

Also, customer service for dealing with the certificate holder.

That said, offering an API and automating as much as they can is a lot easier than receiving the reports through free-form e-mail, with followup through Mozilla's root program (https://wiki.mozilla.org/CA/Bug_Triage#Compliance_Problems_a...), where the CA will have to take action or cease existing.

hardcopy• 3 years ago

WTF? CAs should be mandated to have an automated, public form/API where you can submit a private key to have it revoked.

Lets encrypt has this. https://letsencrypt.org/docs/revoking/#using-the-certificate...

pquerna• 3 years ago

The API for Let's Encrypt to do this requires possession of the private key, which pwned keys doesn't always have. Sometimes they just have an "attestation" of compromise:

https://pwnedkeys.com/submit.html

Which if you had an standardized representation of that attestation, maybe CAs could consume that instead.

But, the author of pwnedkeys thought of that, and started an RFC for exactly that:

https://github.com/pwnedkeys/key-compromise-attestation-rfc/...

But it seems dead right now.

ziddoap• 3 years ago

However, several CAs disliked having to revoke all those certificates, because it cost them staff time (and hence money) to do so. They went so far as to change their procedures from the standard way of accepting problem reports (emailing a generic attestation of compromise), and instead required CA-specific hoop-jumping to notify them of compromised keys.

It would have been nice to have names be named. This is obviously in bad faith, and the bad actors should be called out.

Given that Matt Palmer is an active participant of the MDSP (Mozilla Dev Security Policy) mailing list, I am surprised that I don't recall seeing discussion about this pop up, although I may have missed it. The CAs acting this way really should have to explain themselves.

Animats• 3 years ago

So the Fediverse should blacklist those CAs.

ikekkdcjkfke• 3 years ago

Gross Negligance

Everdred2dx• 3 years ago

How are private keys identified as compromised? Is that a function of certificate transparency?

Pwned Certificates on the Fediverse

Related Stories