A vulnerability was reported against SSL.com, a Certificate Authority (CA), allowing fraudulent issuance of SSL certificates for arbitrary MX hostnames. Their domain control validation (DCV) process was flawed: by setting specific TXT records, an attacker could bypass verification checks and obtain certificates for domains they didn't own, potentially enabling man-in-the-middle attacks. SSL.com confirmed and addressed the issue, revoking the fraudulently issued certificates. Mozilla subsequently added SSL.com to their CA incident database.
Starting September 13, 2024, the maximum lifetime for publicly trusted TLS certificates will be reduced to 398 days (effectively 47 days due to calculation specifics). This change, driven by the CA/Browser Forum, aims to improve security by limiting the impact of compromised certificates and encouraging more frequent certificate renewals, promoting better certificate hygiene and faster adoption of security improvements. While automation is key to managing this shorter lifespan, the industry shift will require organizations to adapt their certificate lifecycle processes.
Hacker News users generally express frustration and skepticism towards the reduced TLS certificate lifespan. Many commenters believe this change primarily benefits certificate authorities (CAs) financially, forcing more frequent purchases. Some argue the security benefits are minimal and outweighed by the increased operational burden on system administrators, particularly those managing numerous servers or complex infrastructures. Several users suggest automation is crucial to cope with shorter lifespans and highlight existing tools like certbot. Concerns are also raised about the potential for increased outages due to expired certificates and the impact on smaller organizations or individual users. A few commenters point out potential benefits like faster revocation of compromised certificates and quicker adoption of new cryptographic standards, but these are largely overshadowed by the negative sentiment surrounding the increased administrative overhead.
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.
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.
Summary of Comments ( 58 )
https://news.ycombinator.com/item?id=43738485
Hacker News commenters discuss the severity and implications of the SSL.com vulnerability, with some downplaying its impact due to the requirement of compromising an email account first. Several highlight the unusual nature of DCV through email, questioning its security compared to other methods like DNS or HTTP. The discussion also touches on the complexities of certificate issuance and the potential for abuse, with one commenter suggesting the core issue lies in the CA's trust and the difficulty of verifying domain ownership reliably. Others point out that this vulnerability isn't new and express frustration with the slow response from CAs. The conversation also drifts towards the broader issue of CA trust and the need for better systems, with some suggesting decentralized solutions. Finally, a few comments mention the irony of a security company like SSL.com having such a vulnerability.
The Hacker News post titled "Ssl.com: DCV bypass and issue fake certificates for any MX hostname" (https://news.ycombinator.com/item?id=43738485) has several comments discussing the implications of the vulnerability described in the linked Bugzilla report.
Several commenters express surprise and concern over the severity of the vulnerability, allowing the issuance of fake certificates for arbitrary MX hostnames. One commenter highlights the potential for significant damage, noting that email servers could be impersonated, leading to interception of sensitive information. The ease with which the vulnerability could be exploited is also mentioned, emphasizing the risk it posed.
The discussion delves into the technical details of the vulnerability, with commenters explaining how the Domain Control Validation (DCV) process was bypassed. Specifically, the comments mention how ssl.com's system misinterpreted specific responses, allowing an attacker to claim control over a domain they didn't own. The conversation also touches upon the complexities of properly implementing and securing the various DCV methods.
Some commenters question the responsibility of Certificate Authorities (CAs) in preventing such vulnerabilities, suggesting more rigorous checks and validation procedures. The impact on trust in the certificate ecosystem is also a point of discussion, with concerns raised about the potential erosion of user confidence in online security.
One commenter questions the response time and transparency of ssl.com in addressing the issue. Others speculate on the potential motivations and technical capabilities of actors who might exploit such a vulnerability.
The comments also explore the broader implications for email security and the challenges of maintaining a secure online environment in the face of constantly evolving threats. The vulnerability is framed within the context of larger systemic issues surrounding digital certificate issuance and validation.