[Infowarrior] - Unqualified Names in the SSL Observatory

[Richard Forno]

(a colleague and I wrote about this problem nearly 10 years ago ... funny how what's old becomes new again .... or what's bad becomes horrific...... --- rick)


April 5th, 2011
      
Unqualified Names in the SSL Observatory

Technical Analysis by Chris Palmer

https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory

Internet certification authorities (CAs) are charged with the task of vouching for the identities of secure web servers. When you browse to https://www.wellsfargo.com/, your browser knows it’s the real wellsfargo.com because VeriSign, a CA, says it is.

However, if CAs don’t validate the identities of the sites they vouch for, the whole system breaks down. In this post, I’ll discuss one way in which CAs frequently fail.

Using data in EFF's SSL Observatory, we have been able to quantify the extent to which CAs engage in the insecure practice of signing certificates for unqualified names. That they do so in large numbers indicates that they do not even minimally validate the certificates they sign. This significantly undermines CAs’ claim to be trustworthy authorities for internet names. It also puts internet users at increased risk of network attack.

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.)

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.

In the Observatory 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! 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!

Although signing “localhost” is humorous, CAs create real risk when they sign other unqualified names. 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! 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.

To test the prevalence of the validated, unqualified names problem, I queried the Observatory database for unqualified names similar to “exchange”. (Microsoft Exchange is an extremely popular email server, and servers that run it commonly have “exchange” or “exch” in their names. Likely examples include “exchange.example.net” and “exch-01.example.com”.) My results show that unqualified “exchange”-like names are the most popular type of name, overall, that CAs are happy to sign.

Unqualified Name Pattern	Valid Certificates Observed
“localhost”	2,201
“exchange”	806
“exchange” with characters on either side, e.g. “exchange01” or “aexchange3”	2,383
“exch” with characters on either side, e.g. “exch01” or “01srvexch”	5,657
All unqualified names	37,244

Related Work

George Macon at Georgia Tech has also used the Observatory to investigate the unqualified names problem. For example, he isolated the CAs that sign unqualified names, and counted how many times each one did so. (GoDaddy is by far the worst offender.) He also identified some extended-validation certificates that are issued to unqualified names. In January 2011, when he ran his analysis, ten of the twenty-eight unqualified EV certificates were still valid.

Impact

It is far too easy for an attacker to perform a very convincing MITM attack against private exchange servers. The bad behavior of CAs helps attackers.

Recommendations

Users should avoid using unqualified names to access internal resources. Instead, create a bookmark to the URL with the fully-qualified name, e.g. “https://mail.example.com/”. Users should also alert their network administrators to the problem.

Browsers (and other TLS clients, like email readers and web service applications) should stop treating certificates for unqualified names and for IP addresses as valid.

Organizations relying on certificates for unqualified names should use their own private CA for their private namespace. For example, all those Exchange shops can use Microsoft's CA software.

Certifcate authorities should stop signing unqualified names, and should revoke existing certificates for unqualified names. They should also stop signing IP addresses — especially private, non-routable addresses — and should revoke existing IP address certificates, too.