Stories with Tag CA

• How to distrust a CA without any certificate errors

  permalink

  Posted: 2025-03-06 22:28:01

  Verbose tl;dr

  This blog post explores how a Certificate Authority (CA) could maliciously issue a certificate with a valid signature but an impossibly distant expiration date, far beyond the CA's own validity period. This "fake future" certificate wouldn't trigger typical browser warnings because the signature checks out. However, by comparing the certificate's notAfter date with Signed Certificate Timestamps (SCTs) from publicly auditable logs, inconsistencies can be detected. These SCTs provide proof of inclusion in a log at a specific time, effectively acting as a timestamp for when the certificate was issued. If the SCT is newer than the CA's validity period but the certificate claims an older issuance date within that validity period, it indicates potential foul play. The post further demonstrates how this discrepancy can be checked programmatically using open-source tools.

  This blog post by Dadrian, titled "How to distrust a Certificate Authority without any certificate errors," explores a nuanced vulnerability related to Signed Certificate Timestamps (SCTs), which are crucial for ensuring the transparency and integrity of certificate issuance. The core issue revolves around the "notAfter" field within these SCTs. While a certificate itself has a validity period defined by its own "notAfter" date, the SCTs that vouch for its inclusion in a Certificate Transparency (CT) log also possess their own "notAfter" dates. The post highlights a potential scenario where a malicious or compromised Certificate Authority (CA) could issue a perfectly valid certificate – meaning the certificate's own "notAfter" date is in the future – yet manipulate the SCTs associated with that certificate. Specifically, the CA could backdate the SCTs, setting their "notAfter" dates to a point in the past.

  This manipulation wouldn't immediately trigger certificate errors in browsers or other relying parties because the certificate itself remains technically valid. However, it undermines the core principle of Certificate Transparency. Certificate Transparency logs are designed to provide an auditable record of all issued certificates, allowing for public scrutiny and detection of mis-issued or fraudulent certificates. The "notAfter" date of an SCT serves as a timestamp guaranteeing the certificate's inclusion in the log up to that specific point in time. By backdating the SCTs, the CA effectively creates a situation where the proof of inclusion in the CT log expires prematurely. This creates a window of opportunity where the CA could potentially issue other, fraudulent certificates without those certificates being reflected in the CT logs, as the now-expired SCTs no longer offer valid proof of inclusion. This undermines the entire auditability and transparency mechanism.

  The blog post details a practical demonstration of this vulnerability, showing how one can programmatically examine SCTs embedded in a certificate and compare their "notAfter" dates with the current time. This allows for the identification of certificates with potentially backdated SCTs, raising a red flag regarding the trustworthiness of the issuing CA, even in the absence of traditional certificate errors. The post concludes by emphasizing the importance of validating SCT "notAfter" dates as a critical part of robust certificate verification procedures and underscores the subtle ways in which the Certificate Transparency ecosystem can be compromised, requiring vigilance beyond simply checking for standard certificate validity. It implies that relying solely on the validity of the certificate itself isn't sufficient for guaranteeing trustworthiness and that scrutiny of associated SCTs is paramount.

  • TLS
  • SSL
  • certificates
  • Certificate Authority
  • CA
  • PKI
  • Security
  • Web Security
  • SCT
  • Signed Certificate Timestamps
  • transparency
  • X.509
  • Not After
  • Expiration
  • Distrust
  • verification
  • Cryptography

  Summary of Comments ( 43 )
  https://news.ycombinator.com/item?id=43285671

  Verbose tl;dr

  Hacker News users discuss the practicality and implications of the blog post's method for detecting malicious Sub-CAs. Several commenters point out the difficulty of implementing this at scale due to the computational cost and potential performance impact of checking every certificate against a large CRL set. Others express concerns about the feasibility of maintaining an up-to-date list of suspect CAs, given their dynamic nature. Some question the overall effectiveness, arguing that sophisticated attackers could circumvent such checks. A few users suggest alternative approaches like using DNSSEC and DANE, or relying on operating system trust stores. The overall sentiment leans toward acknowledging the validity of the author's points while remaining skeptical of the proposed solution's real-world applicability.

  The Hacker News post "How to distrust a CA without any certificate errors" sparked a discussion with several insightful comments. Many commenters engaged with the core concept of the blog post, which explored how a Certificate Authority (CA) could potentially manipulate certificates without triggering typical browser warnings.

  One commenter highlighted the difficulty in detecting this type of manipulation, emphasizing that the trust model inherently relies on the CA. They pointed out the unlikelihood of a user independently verifying the certificate chain, especially given the complexity involved. This reinforced the article's point about the potential vulnerability.

  Another commenter discussed the "certificate pinning" technique, which involves hardcoding expected certificate information into an application. While effective against the specific attack described in the article, they acknowledged that it's not a widespread solution and introduces its own set of management challenges, such as the need to update pinned certificates regularly.

  The conversation also touched upon the broader issues of trust and security in the digital landscape. One commenter expressed a general lack of trust in CAs, citing past incidents of compromised CAs and questionable practices. This sentiment resonated with other users who echoed concerns about the centralized nature of the CA system.

  Some commenters suggested alternative approaches to enhance security. One idea involved using DNSSEC combined with DANE (DNS-based Authentication of Named Entities), allowing domain owners to specify which CAs are authorized to issue certificates for their domain. Another suggestion was to explore decentralized identity solutions, moving away from the reliance on centralized CAs altogether.

  Several comments also delved into the technical details of the attack described in the article, with users discussing specific aspects of certificate validation and the potential implications for different browsers and operating systems. There was some debate about the practicality of the attack and the likelihood of it being exploited in the wild, with some arguing that the complexity involved would make it a less attractive option for attackers.

  Overall, the comments section reflected a general understanding of the potential vulnerabilities associated with the current CA system and a desire for more robust and transparent security solutions. While no single solution emerged as a clear winner, the discussion provided valuable insights into the challenges and potential future directions of certificate management and online trust.

• DigiCert: Threat of legal action to stifle Bugzilla discourse

  permalink

  Posted: 2025-02-25 01:40:14

  Verbose tl;dr

  DigiCert, a Certificate Authority (CA), issued a DMCA takedown notice against a Mozilla Bugzilla post detailing a vulnerability in their certificate issuance process. This vulnerability allowed the fraudulent issuance of certificates for *.mozilla.org, a significant security risk. While DigiCert later claimed the takedown was accidental and retracted it, the initial action sparked concern within the Mozilla community regarding potential censorship and the chilling effect such legal threats could have on open security research and vulnerability disclosure. The incident highlights the tension between responsible disclosure and legal protection, particularly when vulnerabilities involve prominent organizations.

  This Bugzilla report, titled "DigiCert: Threat of legal action to stifle Bugzilla discourse," details a concerning interaction between Mozilla developers and representatives of DigiCert, a prominent Certificate Authority (CA). The issue at hand revolves around public discussion on the Mozilla Bugzilla platform regarding a specific certificate issuance incident involving DigiCert. The report alleges that DigiCert, instead of engaging in open and constructive dialogue about the technical aspects and potential security implications of the incident being discussed on the platform, resorted to legal threats aimed at suppressing further conversation and removing existing commentary.

  The author of the Bugzilla report expresses apprehension that such actions by a trusted CA like DigiCert could have a chilling effect on the vital role Bugzilla plays in fostering transparency and collaborative security research. They argue that open discussion of potential vulnerabilities and certificate issuance problems is paramount to maintaining the integrity and security of the internet ecosystem. The report highlights the potential conflict between the desire of a CA to protect its reputation and the broader community interest in openly analyzing and addressing potential weaknesses in certificate issuance processes. The author underscores the importance of Bugzilla as a crucial platform for facilitating this essential public discourse and argues that legal threats against such discourse are detrimental to the collective security efforts of the internet community. The report concludes by calling for a reaffirmation of Mozilla's commitment to maintaining an open and transparent platform for discussing security issues, even in the face of pressure from external entities. The implication is that succumbing to such pressure could set a dangerous precedent, potentially discouraging future disclosures and hindering the collaborative identification and resolution of security vulnerabilities.

  • DigiCert
  • Bugzilla
  • Mozilla
  • Certificate Authority
  • CA
  • Legal Threat
  • Censorship
  • Open Source
  • Security
  • SSL/TLS
  • Web Security
  • privacy
  • vulnerability disclosure
  • Free Speech

  Summary of Comments ( 125 )
  https://news.ycombinator.com/item?id=43167087

  Verbose tl;dr

  HN commenters largely express outrage at DigiCert's legal threat against Mozilla for publicly disclosing a vulnerability in their software via Bugzilla, viewing it as an attempt to stifle legitimate security research and responsible disclosure. Several highlight the chilling effect such actions can have on vulnerability reporting, potentially leading to more undisclosed vulnerabilities being exploited. Some question the legality and ethics of DigiCert's response, especially given the public nature of the Bugzilla entry. A few commenters sympathize with DigiCert's frustration with the delayed disclosure but still condemn their approach. The overall sentiment is strongly against DigiCert's handling of the situation.

  The Hacker News post "DigiCert: Threat of legal action to stifle Bugzilla discourse" (linking to a Mozilla Bugzilla report about DigiCert's revocation of a certificate used for WireGuard) sparked a lively discussion with several compelling comments.

  Many commenters expressed outrage and concern over DigiCert's handling of the situation, viewing their legal threat as an attempt to suppress legitimate discussion of a potential security issue. They saw it as a heavy-handed response that discouraged responsible disclosure and could have chilling effects on future vulnerability reporting. Some specifically criticized the use of legal threats in response to public interest concerns around certificate revocation practices, arguing it sets a bad precedent.

  Several comments focused on the technical aspects of certificate revocation, debating the merits of DigiCert's actions and whether the revocation was justified. Some questioned if the key compromise was genuine or a result of a misunderstanding, while others discussed the broader challenges and limitations of certificate revocation mechanisms. This sparked a back-and-forth about best practices and responsibilities in such scenarios.

  A few comments highlighted the potential implications for WireGuard users, expressing concern about the disruption caused by the revocation and the potential for similar incidents in the future. They discussed the importance of clear communication and transparency from Certificate Authorities (CAs) during such events.

  Some commenters questioned the Bugzilla forum as the appropriate venue for this discussion, suggesting that a more private channel might have been more suitable for addressing the legal concerns raised by DigiCert. However, others countered that the public nature of the discussion was crucial for transparency and accountability.

  There was also discussion about the legal aspects of the situation, with commenters speculating about the basis of DigiCert's legal threat and the potential outcomes. Some pointed to potential defamation or tortious interference claims, while others questioned the validity of such claims in this context.

  Finally, several commenters offered alternative interpretations of DigiCert's actions, suggesting they might have been motivated by a desire to protect their reputation or avoid potential liability, rather than to stifle legitimate discourse. They encouraged considering the perspectives of all involved parties.