(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.
_______________________________________________
Infowarrior mailing list
[email protected]
https://attrition.org/mailman/listinfo/infowarrior
