MITM attacks made possible by SSL certs issued for unqualified names

The recent compromise of a Comodo affiliate Registration Authority which resulted in the issue of nine rogue SSL certificates for seven popular domains has jolted the security community and has justifiably made it question whether the Web’s certificate authority infrastructure is a system that can be trusted.

Incidents such as that one – however unfortunate they may be for companies involved – have the benefit of pointing out weaknesses that could be exploited by more than just one attacker in the future, and making the companies patch them or change their ways in order to minimize the attack surface.

One of the mistakes that has a lot of potential of being misused by malicious individuals has been pointed out by EFF’s Technology Director Chris Palmer in a recent blog post.

He analyzed a batch of data collected by the EFF’s project called SSL Observatory, and sifted through it in order to verify just how many signed certificates for unqualified names are actually out there.

As it turns out, there are quite a lot of them.

“Normally, a public CA like Verisign or Comodo should sign only public names. On the internet, only fully-qualified domain names are public and routable. For example, ‘www.eff.org.’ is a fully-qualified name. By contrast, the name ‘www’ is unqualified or not fully-qualified. This name is not globally unique, and may refer to a different computer on my network than it does on your network. (On some networks, it may not refer to any computer at all.),” Palmer explains.

“As a convenience for users, the administrators of local networks will often configure their networks to use unqualified names for internal services. This is why, at many companies, you can simply type ‘mail’ or ‘wiki’ or ‘intranet’ into your browser, and get to your company’s internal web resources. But these names have — or should have — no meaning on the global internet.”

So, imagine the EFF’s surprise when they discovered more than 37,000 CA-signed certificates of unqualified domain names. According to Palmer, the most common unqualified name is “localhost” (2,201 instances), which always refers to the user’s computer.

“It simply makes no sense for a public CA to sign a certificate for this private name. 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!” he comments.

They also analyzed the SSL Observatory database for unqualified names similar to “exchange” – since Microsoft Exchange is on of the most used email servers. The result? 8,846 certificates signed for some variation of “exchange” and “exch”.

“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!” he explains. “Everything would look normal: your browser would use HTTPS, it would show a the 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.”

Since the potential for misuse is high, he advises CAs to stop signing unqualified names and IP addresses and revoke the certificates they signed for them. Users should stop using unqualified names to access internal resources, and organizations should use their own CA for issuing certificated for unqualified names in their namespace.