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.
This Mozilla bug report details a critical vulnerability discovered within the SSL.com certificate issuance process, potentially enabling malicious actors to fraudulently obtain SSL/TLS certificates for arbitrary mail exchange (MX) hostnames. The core issue stems from SSL.com's flawed domain control validation (DCV) procedures, specifically related to their handling of DNS-based DCV for email domains. Legitimate certificate issuance requires applicants to prove they control the domain for which they are requesting a certificate. One common method involves adding specific DNS records to the domain's DNS zone file. SSL.com purportedly offered a DCV method allowing applicants to create a specific DNS record within the _smtp._tcp service record of their MX domain.
However, the report reveals that SSL.com's system apparently failed to properly validate the actual MX record resolution. This oversight allowed an attacker, without any control over a target domain, to create the necessary DCV DNS record on a domain they controlled, point an MX record at that domain, and successfully complete the DCV process. This effectively bypassed the intended domain ownership verification, allowing the attacker to obtain a valid certificate for the target's MX hostname, even though they held no legitimate authority over it. Such a fraudulent certificate could then be used to intercept and decrypt email traffic destined for the target domain, posing a significant security risk.
The reporter demonstrated this vulnerability by successfully obtaining a certificate for mx.mozilla.com without having any legitimate control over the mozilla.com domain. They highlighted that this issue could affect any domain utilizing SSL.com's specific MX-based DCV method. The severity of the vulnerability was underscored by the potential for widespread email interception and the undermining of trust in digital certificates issued by SSL.com. The reporter strongly urged prompt action to address this flaw and revoke any potentially fraudulently issued certificates.
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.