Hacker News Reader

Comment by hannob | Hacker News Reader

The author doesn't explain at all why he thinks that not using StartSSL solves any problem. This indicates a major and common misunderstanding of how certificates and PKI work.

Essentially it doesn't matter which Certificate Authority you use for security reasons - because any CA can attack you, whether you're their customer or not. This can only be mitigated by using key pinning (hpkp), but then - at least if you pin leaf certificates - it still doesn't matter which CA you choose.

Every text that indicates "I don't trust CA X for reason Y, therefore I don't use them" is based on a misunderstanding of how certificates work.

(And yes - I know that there is the issue that you can let StartSSL create the private key for you. Just don't do this ever, no matter which CA you use.)

View on HN

Can you pin leaf certificates?

Quoting https://developer.mozilla.org/en/docs/Web/Security/Public_Ke...:

> Firefox (and Chrome) disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor (rather than a built-in trust anchor).

I understand this as "when using HPKP, you have to pin a CA certificate, not your site's leaf certificate". If this understanding is correct, I think your comment about HPKP is wrong and it is in fact a good idea to use a CA you find trustworthy and pin its certificate. Agree?

No, that phrasing is saying that custom CA certificates override pinning (e.g. for corporate MITM proxies).

It's my understanding that you can pin to any certificate in your chain, but if a server presents a certificate that leads to a user-defined trust anchor (i.e. your typical corporate MitM proxy cert), no HPKP check is performed.

Sorry, accidentally down-voted.

> "I don't trust CA X for reason Y, therefore I don't use them" is based on a misunderstanding of how certificates work.

I don't think so. If you don't trust a particular CA then you shouldn't in good conscience make trusting them a requirement to access your services. And by using an untrustworthy CA you are making it harder for browsers and distribution maintainers to distrust them if they start abusing that trust.

Since a pretty typical HPKP configuration pins to CAs, this seems like bad advice.

They do ? I had no idea. That sounds terrible.

I have not implemented key-pinning myself, but I always assumed you were pinning the key of the actual site you were communicating with ... sort of like SSH ...

That's not the case ?

You can pin to any of the public keys in your certificate chain, so that's the root cert, intermediate certs, or your own cert.

Most deployments currently pin to a main and backup CA. This is because HPKP makes it fairly easy to essentially brick your domain (Think: Heartbleed and a lost backup key. Say goodbye to your domain!). It's possible, but you better know what you're doing.

Wow. So there's no way to simply say "here is the public key that I expect to see for this website, and alert me if it's different" ?

Isn't that the simplest thing with the most utility ?

What am I missing here ?

"any of the public keys in your certificate chain" includes your own certificate, so yes, that's possible.

However, if your main and backup key is lost or compromised, you have essentially bricked your domain. That's why most real-life deployments pin to two CAs instead (since CAs are generally better at managing keys).

If you use StartSSL, and then down the line they go well and truly rogue, browser vendors will have to consider ceasing to trust StartSSL in future releases. If your site is popular, it will be one more reason for them not to do that, which would leave their users less safe. If they do decide to untrust StartSSL, this will break your site.

Well, you could pin your CA's certificate so at the very least your repeat users won't be at risk but fundamentally you're right and it is a common misconception.

"because any CA can attack you, whether you're their customer or not"

Can you (or someone) explain why this is? I don't understand.

Every CA in your trust store can issue certificates for every domain. "Attack", in this context, means issuing a trusted certificate that can be used to MitM users of your site. HPKP helps mitigate this risk on a Trust on First Use (TOFU) basis.

As long as the certificate is ultimately signed by a root CA in your computer's trust store, the certificate will be regarded as valid by your computer. So basically, any CA in your trust store or signed by a CA in your trust store can issue the certificates for anyone, anything and any domain. It doesn't matter if the owner of domain consents or not.

Reply on news.ycombinator.com