3 ms·

Surprisingly low quality article from Cloudflare. None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client

Surprisingly low quality article from Cloudflare. None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client who trusts a misbehaving/rogue/malicious CA (perhaps you installed a VPN or AV or something that added a system-wide CA to your machine?) and their connection to your service gets mitm-d. Shorter certificate lifetimes - does nothing to mitigate that risk. CAA records - not checked by client, only ensures that if a malicious actor somehow gets a hold of your domain, they need to use a particular CA to issue their publicly-trusted malicious cert. CT monitoring - yes, for WebPKI certs, but does not protect against the risk above, as the bad CA-s are likely not sending certs to CT log. Distributed DCV checks - sure, this is something CA-s should be doing, not something you have control over. ACME URI in CAA - operational issues quite likely, good if you can pull it off, but again, does not address the risk above. What is an actual alternative to cert pinning? Your API should have an additional layer of encryption with keys that you have full control over.

JackSlateur 2y ago
Yes Also, the "Understanding the trade-offs of different certificate pinning implementations" misses one important thing : you can pin the CA, and still requires the cert to be valid for your FQDN I've seen this a couple of time, and this is wonderful : fully secure, and denies the managed mitm setup by the security team.
- patrakov 2y ago
  And the only one time where I have seen this (in a private discussion of the mobile app with a bank employee), they said that they see no valid use case for a managed MitM against their production website. Preventing proxies like Charles and mitmproxy from working was one of their explicit goals for the app.
hn_throwaway_99 2y ago
While I agree this is a low quality article in desperate need of an editor (there were large sections that were essentially just repeated), I'm not sure I agree with your analysis, especially as it relates to CAA records. I think the fundamental issue is that all of the players in the PKI world want to essentially enforce that services must be able to deal with short-lived certificates and certificate revocations. As an example, see the recent HN article where Digicert tried to do mass certificate revocations due to a bug with their certificate issuance, and were then sued by a client (Alegeus) who did not have things set up to deal with revocations quickly, so Digicert postponed the revocation: https://news.ycombinator.com/item?id=41114794 https://news.ycombinator.com/item?id=41114794 . So basically, the powers that be are trying to say "certificate cycling is part of the process - 'set it and forget it' is a thing of the past." Now, in your objections, you state "None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client who trusts a misbehaving/rogue/malicious CA", but CAA with CT monitoring should largely prevent that. With CAA monitoring you state "only ensures that if a malicious actor somehow gets a hold of your domain..." - well, if a malicious actor somehow gets ahold of your domain, you're generally fucked in any case - if they've got control of your domain it's probably not a huge step up to get control of your signing cert. I think your comment brings up good points to someone like me who's not an expert, but it still feels like the overall point that needs to be addressed is that "certificates should be expected to expire or be revoked at any instant" and certificate pinning breaks that.
- peanut-walrus 2y ago
  There are ways a bad actor can get enough temporary control of your domain that they can issue a domain-validated certificate without actually breaching your service (BGP, DNS hijacks, Cloud provider vulnerabilities, etc). These cases you really need to catch with CT monitoring and CAA does help somewhat as well. And ACME uri pinning should mitigate this completely. Edit: just to clarify, I agree with the article in principle, pinning public certs is just not a workable solution in the current TLS ecosystem and should be avoided, but the author of the article does not understand what attacks pinning is supposed to prevent in the first place, as the solutions offered do not offer the same security guarantees.
  - hn_throwaway_99 2y ago
    Thanks for the reply! Helped me understand your points better, and the larger issues at hand.

JackSlateur 2y ago

Yes Also, the "Understanding the trade-offs of different certificate pinning implementations" misses one important thing : you can pin the CA, and still requires the cert to be valid for your FQDN I've seen this a couple of time, and this is wonderful : fully secure, and denies the managed mitm setup by the security team.

patrakov 2y ago
And the only one time where I have seen this (in a private discussion of the mobile app with a bank employee), they said that they see no valid use case for a managed MitM against their production website. Preventing proxies like Charles and mitmproxy from working was one of their explicit goals for the app.

hn_throwaway_99 2y ago

While I agree this is a low quality article in desperate need of an editor (there were large sections that were essentially just repeated), I'm not sure I agree with your analysis, especially as it relates to CAA records. I think the fundamental issue is that all of the players in the PKI world want to essentially enforce that services must be able to deal with short-lived certificates and certificate revocations. As an example, see the recent HN article where Digicert tried to do mass certificate revocations due to a bug with their certificate issuance, and were then sued by a client (Alegeus) who did not have things set up to deal with revocations quickly, so Digicert postponed the revocation: https://news.ycombinator.com/item?id=41114794 https://news.ycombinator.com/item?id=41114794 . So basically, the powers that be are trying to say "certificate cycling is part of the process - 'set it and forget it' is a thing of the past." Now, in your objections, you state "None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client who trusts a misbehaving/rogue/malicious CA", but CAA with CT monitoring should largely prevent that. With CAA monitoring you state "only ensures that if a malicious actor somehow gets a hold of your domain..." - well, if a malicious actor somehow gets ahold of your domain, you're generally fucked in any case - if they've got control of your domain it's probably not a huge step up to get control of your signing cert. I think your comment brings up good points to someone like me who's not an expert, but it still feels like the overall point that needs to be addressed is that "certificates should be expected to expire or be revoked at any instant" and certificate pinning breaks that.

peanut-walrus 2y ago
There are ways a bad actor can get enough temporary control of your domain that they can issue a domain-validated certificate without actually breaching your service (BGP, DNS hijacks, Cloud provider vulnerabilities, etc). These cases you really need to catch with CT monitoring and CAA does help somewhat as well. And ACME uri pinning should mitigate this completely. Edit: just to clarify, I agree with the article in principle, pinning public certs is just not a workable solution in the current TLS ecosystem and should be avoided, but the author of the article does not understand what attacks pinning is supposed to prevent in the first place, as the solutions offered do not offer the same security guarantees.
- hn_throwaway_99 2y ago
  Thanks for the reply! Helped me understand your points better, and the larger issues at hand.