The EFF has issued a report that's gaining some attention in the media. It exposes the bad habit of issuing SSL certificates to unqualified domains. In the process of revealing this issue, some focus has also been given to the discovery of incorrectly assigned EV SSL certificates. Yet, many reports on the topic fail to mention said certificates were corrected months ago.
The focus of the report from Chris Palmer, the EFF’s technology director, is the number of SSL certificates signed by established CAs (Certificate Authorities) and subsequently trusted by every browser on the market. These certificates are valid, but issued improperly. The report says that, by doing so, the CAs have undermined their claims to be “trustworthy authorities for internet names”.
“We have discovered many examples of CA-signed certificates unqualified domain names. In fact, the most common unqualified name is “localhost”, which always refers to your own computer!” Palmer's report outlines.
“It simply makes no sense for a public CA to sign a certificate for this private name,” it continues. “Some CAs have signed many, many certificates for this name, which indicates that they do not even keep track of which names they have signed. Some other CAs do make sure to sign “localhost” only once. Cold comfort!”
Searching through the collected data, the EFF discovered more than 2,000 certificates issued to “localhost”. Moreover, nearly 8,000 certificates were issued to “exchange”, “exch”, or other variants. In all, some 37,000 certificates were issued to non-qualified domains.
SSL certificates are supposed to be issued only to Fully Qualified Domain Names (FQDN), such as www.google.com or mailbox.somecompany.local, if they are issued to other names, there is an entire world of problems that can come from this.
“What if an attacker were able to receive a CA-signed certificate for names like ‘mail’ or ‘webmail’? Such an attacker would be able to perfectly forge the identity of your organization’s webmail server in a “man-in-the-middle” attack!” wrote Palmer.
“Everything would look normal: your browser would use HTTPS, it would show a lock icon that indicates HTTPS is working properly, it would show that a real CA validated the HTTPS certificate, and it would raise no security warnings. And yet, you would be giving your password and your email contents to the attacker.”
The EFF post also referenced research by George Macon at Georgia Tech, who performed a similar study. Macon’s data discovered that GoDaddy was the largest offender when it came to issuing non-FQDN certificates.
Macon also discovered 28 EV SSL certificates that were incorrectly issued to domains like “webmail”. Of the 28 EV certificates discovered earlier this year, 18 of then had been revoked or had expired. Yet, that still left 10 certificates unaccounted for.
However, as the news about the incorrect EV certificates started to spread, The Tech Herald did some checking. As it turns out the EV incident was actually cleared up back in January.
Rick Andrews, technical director at Symantec (which owns VeriSign), reported to Mozilla that VeriSign was made aware of the incorrectly issued EV certificates, and took mitigating steps to resolve the problem [source].
Still, given the checks an organization needs to go through to obtain an EV certificate, we were curious as to how this happened. So we contacted VeriSign, which issued a majority of the EV certificates discovered by Macon, and it explained there was a problem with domain checks.
“We found our system did not proactively block the issuance of certificates containing non-FDQNs. We expeditiously revoked the affected certificates and established enhanced programmatic blocks to ensure proper FQDN checks. We have confirmed that no certificates can be issued to non-FQDNs and that all active EV certificates have been issued within CAB Forum guidelines,” a spokesperson explained.
In addition, we were informed that, while the EV certificates were issued incorrectly, the organization responsible for issuing them was fully vetted. Based on communications to Mozilla, VeriSign issued a hard deadline to the customers using non-FQDN certificates or certificates with less than 2048-bit encryption, and within about two weeks they were replaced and correctly implemented.
So what about the other certificates? As mentioned, when it comes to DV (Domain Validated) SSL certificates, GoDaddy is the largest offender where issuing them to unqualified domains is concerned. However, VeriSign also issues DV certificates under the 'Thawte' and 'GeoTrust' brands.
We’ve asked VeriSign if the same checks for unqualified domains used for EV certificates apply to DV certificates as well. At the time this article went to press, we were still waiting to hear back.
Update 7:09 PM EST - VeriSign has responded with the following:
"The same non-FQDN checks that we have for our EV SSL certs are not the same for DV certs. DV certs by design require the lowest level of authentication and are purchased primarily for encryption purposes. The lower level of assurances required by DV certs were a driving factor behind the higher standards developed for EV SSL certificates."
So in short, no it does not use the same level of checks for DV certificates as it would with EV certificates.
The EFF report highlights a major vector of abuse when it comes to SSL certificates. Given the growth in targeted attacks on organizations hitting the news lately, a fully validated domain such as “webmail” or “exchange” is a prize find for an attacker who has access to a given network.
The EFF has shown a clear need for CAs and businesses to work together and stamp out the problem. So far, it seems as if only one CA is being proactive, and, unless otherwise stated, this is only for EV certificates. EV certificates are a clear minority when compared to the usage of DV certificates around the globe.
“While I hope that the awareness being raised by the EFF report shakes up the certificate industry, I have a feeling the lack of verification in the way certificates are being issued may just be the beginning of the problems,” commented Sophos’ Chester Wisniewski on the matter.
“While it is nice to see a padlock in your browser…it doesn't mean much if certificates are being issued that compromise the entire system. At the moment little can be done by end users about this problem. As a community we need to continually apply pressure on the industry to make meaningful changes to the process to make the best of the transitive trust model that we currently possess.”