SSL certificate authorities put us all at risk by handing out certs for "mail" "webmail" and other unqualified domains

In the wake of the revelation that a major SSL certificate provider suffered a serious breach, Chris Palmer from the Electronic Frontier Foundation has analysis of the common practice of issuing certificates for unqualified domain names, such as "mail" and "www" and "localhost" (an unqualified domain is one that consists of a single word, without a top- and second-level domain, e.g., "www" instead of "www.boingboing.net"). These unqualified names should never be issued certificates, as doing so leaves anyone who makes a practice of using them within a company network vulnerable to man-in-the-middle attacks. Palmer found tens of thousands of these certificates, and sounds the alarm that if you're not using fully qualified domains for secure connections, you're very vulnerable.

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 Names in the SSL Observatory

• [Anonymous]

  I am a person who regularly orders and renews several SSL certificates through one of the providers above as a reseller, through an online web ordering tool provided by them.

  In the past, you could order a domain name for anything. There was an option to clarify the information presented in the CSR, but you did not have to validate it. There was also a checkbox that simply said “I certify I own this domain” or something to that affect, but your order would go through regardless. I’ve made more than one mistake on my csr with regards to a typo and I still received the certificates (things like mydomain.comx or wronghost.domain.com). Typically, I would have my request returned via email within a minute regardless of any error.

  Since the breach a couple weeks ago, these request now take 2-4 days to return an order, and I am being scrutinized for details like my company name being different than the whois entry, or having the the incorrect address (zip code) for one of my submissions.

  Though it doesn’t account for the negligence in the lack of auditing of the reseller customers, I think that the company I am working with is actually taking proper measures to increase security and finally review these submissions.

• [Anonymous]

  If your company has a server named “mailserver” using unqualified certs, and you have a typically configured corporate laptop, you can’t safely use it outside the company’s office building.

  Scenario: You go to starbucks. I’m there with my laptop and my nice, fully validated “mailserver” cert on my machine. You boot, and your email agent sends me your password. Have a nice day!

  In case anybody wonders why this happens, it’s because Old Fart Unix Bigots are still telling everyone to use unqualified names for hosts just like they did at Berkeley when everyone used the R-utilities and dropped acid on the job. This breaks lots of SSL stuff unless you get an unqualified cert.

  At any *nix shell prompt (use bash on linux) just type “unname -n” and hit enter. If the name that comes back is unqualified – like say “mailserver” instead of “mailserver.somecompany.com” – then your sysadmin need re-education. There is no excuse for using unqualified host names on the hosts themselves – the DNS system replaced host tables 20 years ago or more, your resolver will automagically supply the domain for you if you can’t type.

• [Anonymous]

  In this instance, the organization should be signing its own certs and have an in house CA cert distributed to all clients.

• [traalfaz]

  So let’s revoke the CA trust for any authority that does this. Let the fun begin!

• [ColHapablap]

  “Such an attacker would be able to perfectly forge the identity of your organization’s webmail server in a “man-in-the-middle” attack!”

  This really only works if you’re accessing the webmail server on the local network using an unqualified domain name. In which case, the attacker would also have to be on the local network, or have some other clever way of routing the local traffic to a remote server in the “middle”.

• [Joe]

  The reason why people ask for, and get, SSL certificates like this is because of a defect in the way browsers do SSL connections. Let’s say that my company has an Exchange server whose address is exchange.mycompany.com. If it speaks HTTP, I can talk to it with http:://exchange or just “exchange”. But if I type https://exchange, both IE and Firefox throw a fit, with a long scary message that the cert is for the wrong host, exchange.mycompany.com. This is even though, when the browser asked for the translation of “exchange”, it knew or should have known that the match was found by expanding “exchange” to “exchange.mycompany.com”. So what we need to do is fix browsers so they don’t scream about “name mismatches” that are not mismatches at all. Then and only then can we revoke those bogus SSL certificates on hostnames with no dots in them.

  • [dculberson]

    Could the web server redirect a request for https://exchange to https://exchange.mycompany.com?

  • [Todd Knarr]

    @Joe: the problem is that the browser *doesn’t* know the match was found at “exchange.mycompany.com”. The browser asked the local resolver for “exchange”. The local resolver returned the IP address. Only the local resolver knows it failed to get an address for “exchange”, appended the domain suffix “.mycompany.com”, tried again and got a result, and the resolver isn’t telling. That makes it possible to use hostnames on the local network without apps knowing anything about what the local network’s called, and you can change the local DNS domain by changing configuration just within the resolver. Now though there’s a mismatch between how things were designed (apps are oblivious to the local network configuration) and what we want to do (apps are sensitive to the local network configuration).

    • [Joe]

      Sorry, Todd, I’m not buying it. True, the resolver is the place where .mycompany.com was added, but when the browser sees the mismatch, it can guess that this is what has happened, and it can verify the guess by asking for exchange.mycompany.com and verifying that the IP address is the same. Alternatively it could just directly access https://exchange.mycompany.com.

      Your explanation describes internal details that aren’t the user’s concern. The important point is that when the browser is capable of verifying that the correct host was reached, it should just do so instead of alarming the user.

  • [Anonymous]

    The defect is in your user, and in your host resolution. You should

    a. never use “http://exchange/” but always use “http://exchange.mydomain.tld/”

    b. have either hosts files on the machines that maps exchange.mydomain.tld to the local IP address, OR

    c. have an internal DNS.

    The latter is VERY easy to do on a Windows domain, as DNS is a necessary part of ActiveDirectory, and ActiveDirectory is a necessary part of Exchange Server. So no, there is no bloody excuse for an unqualified cert for the hostname “exchange”.

• [show me]

  They didn’t hand out certs for “mail” and “webmail”, at least not according to the article. The article says “What if” they handed out these certs.
  #misleadingtitle

  • [Anonymous]

    I did read the article.

    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!” Palmer, the technology director of the EFF, wrote in an analysis of the certificate data.

    Nice try, though. You work for Verisign?

• [Hisso]

  @Joe, it doesn’t matter if you “buy it” or not. Todd’s description is technically accurate and it *does* make it hard for browsers to meaningfully know if they’ve connected to the “correct” host.

  I might also add that the local resolver may be configured to have search paths. When the resolver responds with an IP address the caller *does not know* if the resolver found that partial hostname by looking at the domain name or any of the additional domains listed in the search path.

  In addition, the resolver library on *all operating systems* will search “down the domain” if it can’t resolve an address. So if I type in “exchange” and my domain is “department.company.tld.cc” the resolver may search:

  1. exchange.department.company.tld.cc
  2. exchange.company.tld.cc
  3. exchange.tld.cc

  The caller will not know which of these addresses was actually matched.

  I guess a browser *could* do a “reverse lookup” on the IP address to try and get a fully qualified domain name — but it’s not guaranteed to work and will probably still result in a name mismatch.

  No, the article is correct. The problem is not the browser. The problem is the certificate authorities doing the wrong thing.

• [Zan]

  The easy answer to that “flaw” is to set up a dumb-simple web server on http://exchange to forward people to https://exchange.mycompany.com (you may need to put your exchange webmail server on a non-standard port if your users are using an https anywhere plugin).