Unqualified Names in the 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”

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.