Avoiding downtime: modern alternatives to outdated certificate pinning practices
Certificate pinning is becoming obsolete due to frequent certificate rotations causing outages. Modern practices like shorter lifetimes and enhanced monitoring improve security and reduce risks associated with legacy pinning.
Read original article
Certificate pinning, once a widely accepted security practice, is becoming increasingly obsolete due to advancements in Public Key Infrastructure (PKI) and the evolving landscape of TLS certificate management. Originally designed to prevent man-in-the-middle attacks by ensuring clients only trust specific certificates, certificate pinning has led to significant outages as certificate authorities (CAs) rotate certificates more frequently. This mismatch between pinned and newly issued certificates can cause clients to reject valid connections, resulting in service disruptions. The rise in outages reported in 2024, particularly during Cloudflare's migration from DigiCert, highlights the risks associated with outdated pinning practices. Modern alternatives, such as shorter certificate lifetimes, regular intermediate certificate rotations, and enhanced certificate transparency, provide robust security without the management overhead of pinning. These practices allow for real-time monitoring of certificate issuance, reducing the likelihood of misissued certificates and the need for manual updates. As organizations adapt to these new standards, they can achieve higher security levels while minimizing the risks associated with legacy practices like certificate pinning.
- Certificate pinning is increasingly causing outages due to frequent certificate rotations by CAs.
- Modern practices like shorter certificate lifetimes and certificate transparency are replacing the need for pinning.
- Cloudflare's migration from DigiCert revealed many customers were unaware of their certificate pins.
- Enhanced monitoring and automation in certificate management improve security and reduce risks.
- Organizations are encouraged to adopt modern standards for better security without the overhead of certificate pinning.
Related
Telekom Security: Revocation delay for TLS certificates
Telekom Security experienced a delay in revoking TLS certificates, affecting 336 certificates due to basicConstraints not marked as critical. Efforts were made to prompt customers for replacement within 5 days. Lessons included the need for customer sensitization and faster certificate replacement procedures. Automation via protocols like ACME was considered for future processes. Stakeholders questioned the delay, but Telekom Security defended its decision based on low security risk and impact on critical infrastructures. The incident underscored challenges faced by CAs in ensuring timely revocation and the importance of continuous improvement for industry standards and trust.
Deutsche Telekom issued invalid certificates, hasn't revoked them since 6 months
Telekom Security faced delays in revoking TLS certificates, impacting critical infrastructures. Efforts were made to replace 336 certificates within 5 days, highlighting the need for faster procedures and customer sensitization. Mozilla raised concerns about the response, emphasizing the importance of compliance with industry standards.
All I Know About Certificates – Certificate Authority
The article highlights the critical role of certificates in the TLS handshake for website identity verification, emphasizing trusted Certificate Authorities' responsibilities and the impact of free certificates from Let’s Encrypt.
Jeremy Rowley resigns from DigiCert due to mass-revocation incident
DigiCert identified a bug allowing certificate issuance without an underscore prefix, affecting 83,267 certificates. They plan revocation within 24 hours, but critical sector customers may face reissuance challenges.
Local Networks Go Global When Domain Names Collide
Namespace collision from new top-level domains poses security risks for organizations using outdated domain names. Philippe Caturegli identified over 9,000 vulnerable domains, highlighting the need for improved cybersecurity practices.
11 commentsNone 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.
Is pinning to certs signed by CAs you don't control, but that are public and trusted, beneficial over using self signed ones? I guess you won't (easily) land in CT log. Anything else?
I’ve heard multiple times that “certificate pinning is obsolete.” Who is pushing this narrative?
* The client requests additional certificate chains
* The server returns multiple certificate chains (typically two), one chaining to a public CA, once chaining to a private CA
* The connection only succeeds if all expected chains are present and valid
* The public-key of the leaf certificates must be identical
This means:
* The public chain can follow standard practices around certificate transparency, renewal, revocation, expiration, etc.
* Clients which don't care about pinning but expect a standard public chain will work
* The chain to the private CA protects against a compromised public CA for clients which request/validate it
* Requiring identical public-keys means that this only impacts chain validation, not the key-exchange
I understand the "leaf" or "domain" update is done when the request is made, and that I as the end user don't need to do anything.
However if an intermediate certificate is updated, do I now need to update the app or client (OS/browser etc)?
Because I can sure see it in Google's interest to ensure clients only use the latest browsers, OS'. I suppose it becomes another "control" point.
If your client cannot resolve a domain (outdated hardware/software) you're out of luck.
If Google pushes changes to, for example, data collection within Chrome, they're going to want all users to update ASAP (e.g manifest V3, break older versions of chrome by rotating certificates).
We ended up doing slow brown-outs over a long time period to deal with it.
At a large company I have to imagine that monitoring them would just end up being noise.
All that lengthy blog post and no explanation of what configuration is causing this and in what kinds of software. And how to find certificate pins in your infrastructure.
Anyone know?
So I guess it's disappointing not only that they're wrong here in this article, but it's also disappointing they'd sell off some of their credibility earned by their expertise to trick people into an implementation with a much larger maintenance cost.
Anyone have any alternatives to cloudflare, is there anyone who still values correctness over making money?
Related
Telekom Security: Revocation delay for TLS certificates
Telekom Security experienced a delay in revoking TLS certificates, affecting 336 certificates due to basicConstraints not marked as critical. Efforts were made to prompt customers for replacement within 5 days. Lessons included the need for customer sensitization and faster certificate replacement procedures. Automation via protocols like ACME was considered for future processes. Stakeholders questioned the delay, but Telekom Security defended its decision based on low security risk and impact on critical infrastructures. The incident underscored challenges faced by CAs in ensuring timely revocation and the importance of continuous improvement for industry standards and trust.
Deutsche Telekom issued invalid certificates, hasn't revoked them since 6 months
Telekom Security faced delays in revoking TLS certificates, impacting critical infrastructures. Efforts were made to replace 336 certificates within 5 days, highlighting the need for faster procedures and customer sensitization. Mozilla raised concerns about the response, emphasizing the importance of compliance with industry standards.
All I Know About Certificates – Certificate Authority
The article highlights the critical role of certificates in the TLS handshake for website identity verification, emphasizing trusted Certificate Authorities' responsibilities and the impact of free certificates from Let’s Encrypt.
Jeremy Rowley resigns from DigiCert due to mass-revocation incident
DigiCert identified a bug allowing certificate issuance without an underscore prefix, affecting 83,267 certificates. They plan revocation within 24 hours, but critical sector customers may face reissuance challenges.
Local Networks Go Global When Domain Names Collide
Namespace collision from new top-level domains poses security risks for organizations using outdated domain names. Philippe Caturegli identified over 9,000 vulnerable domains, highlighting the need for improved cybersecurity practices.