Hacker News Reader

Comment by phasmantistes | Hacker News Reader

It's specifically to discourage intermediate key pinning. If folks want to pin their own end-entity public key (and always re-use the same key when renewing their cert), go for it -- dealing with compromise of their own key is their own problem to solve. Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it (although that doesn't prevent a bad actor from getting the same CA to issue a MITM certificate; there are other mechanisms to prevent that).

Just please don't pin intermediate CA keys, which should be opaque to the end-user and need to be able to change quickly without breaking a bunch of apps.

View on HN

> Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it

Please don't pin roots, as that makes it harder to distrust CAs, reducing the agility of the WebPKI. See the Symantec distrust for a painful example.

Chrome and Firefox will be introducing term limits on roots in the near future, which will hopefully help to discourage this harmful practice.

> Please don't pin roots

So what would be the recommended way to protect against government MitM by using some obscure CA?

Currently CT logs:

https://certificate.transparency.dev/

Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted.

At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.

CT logs only mean that if after the horse has bolted, you can start the process to close the door within hours.

That's adequate for low-value targets, but it's hardly sufficient for high-value targets. If a CA mis-issued a cert for *.aws.amazon.com should we be waiting around for a manual process on some mailing list to invalidate it?

I agree conceptually, and I think it's sad that we don't have anything more absolute. (I was a fan of HPKP, which has been deprecated as a "footgun" because apparently users often didn't understand what it was doing or weren't cautious enough when using it.)

But the CT system seems to work very well in practice. While the detection and remedy part is awkwardly manual, there are people working hard on them. There are also (following a "you have to disclose all intermediates ahead of time" rule introduced by Mozilla) fewer intermediates and we actually have a list of them.

https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRe...

Detected incidents involving intentional misissuance are very rare. When unintentional misissuance happens, the responsible CA has to publicly explain how it happened and what it will do to prevent the situation from happening again.

And then what? What are you supposed to do in the meantime until browsers have decided to distrust the CA?

Also, how do you detect "obscure" CAs in the log? If your CT monitoring daemon has some logic to distinguish "good" from "bad" CAs, why not use that logic directly in the app and implement certificate pinning?

I'm curious: What's the defense mechanism for a dodgy CA not publishing a CT log entry for the misused domain?

A CT-honoring client should reject an end-entity certificate that isn't accompanied by a SCT. In other words: a dodgy CA that skips CT to avoid disclosure of their mis-issued certificate should be unable to convince any CT-honoring client to accept that certificate.

An adversary might MITM the CT as well.

How?

Reply on news.ycombinator.com