The Problem of Issuing Certs For Unqualified Names

The recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web’s certificate authority infrastructure works–or doesn’t. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are tens of thousands of legitimate certificates issued by CAs for unqualified names such as “localhost” or “Exchange,” a practice that could simplify some forms of man-in-the-middle attacks.

EEF CertificatesThe recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web’s certificate authority infrastructure works–or doesn’t. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are tens of thousands of legitimate certificates issued by CAs for unqualified names such as “localhost” or “Exchange,” a practice that could simplify some forms of man-in-the-middle attacks.

The data that the EFF analyzed came from the group’s SSL Observatory database, which compiles information on all of the certificates used on the Web. After looking through the database, Chris Palmer of the EFF discovered that CAs have issued more than 37,000 legitimate, signed certificates for names that are commonly used to identify machines on local corporate networks. In some environments users will often just type the name  of an internal resource into their browsers in order to access it.

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

“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.”

What the EFF found is that the data in their SSL Observatory showed a total of 2,201 certificates signed for the name “localhost”, and more than 8,000 certificates for some variation of “exchange” or “exch.” This isn’t a problem anywhere close to the level of the Comodo RAs being compromised, but as Palmer said, it’s something that needs to be addressed, especially now that there is a renewed focus on the workings of the CA infrastructure.

“Certificate 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,” Palmer wrote.

Suggested articles

Discussion

  • Anonymous on

    What a loose conglomeration of unstructured nothingness! Yet to think that we rely on this foundation for our most valuable and sensative transactions is just hard to imagine why there aren't more problems.

  • Anonymous on

    If we've ever learn a lesson from the recent economic crisis is You Cannot Trust Ratings Agencies. They are profil driven, period.

    Certificate authorities == Rating agencies

    You see the picture now ?!

  • Anonymous on

    If we've ever learn a lesson from the recent economic crisis is You Cannot Trust Ratings Agencies. They are profil driven, period.

    Certificate authorities == Rating agencies

    You see the picture now ?!

  • ic3scrap3r on

    My bigger issue with certs is the simple existence of EV certificates. They now want you to pay EXTRA for them to do the work that they should have been doing with standard SSL certificates they issue!

    From Wikipedia:"An important motivation for using digital certificates with SSL was to add trust to online transactions by requiring website operators to undergo vetting with a certificate authority (CA) in order to get an SSL certificate. However, commercial pressures have led some CAs to introduce "domain validation only" SSL certificates for which minimal verification is performed of the details in the certificate."

  • Anonymous on

    localhost is humorous, however I am not sure what solution the author/researchers are pushing in regards to trust on corporate networks? 

    If my company has a internal wiki (for example) on an internal domain (unqualified domain) and wants to secure the login to that wiki, how can they do this without a trusted SSL certificate? 

    The alternative of creating a corporate CA and signing the cert on our own falls apart when you have employees connecting to the wiki with several different web browsers on several different operating systems (let alone contractors or anyone else on our network).

    The last thing we want is to further train people to 'just click through' the browser security warnings. That is a behavior that should be avoided an unlearned as fast as possible.

    Perhaps the browser manufacturers need a more robust infrastructure that would allow corporation A, to be trusted in near real-time, in their browser. Have the corp go through whatever legal hurdles they need and publish a list of issued certs for automated review to help with revocation/untrusting.??

     

    I don't know what the solution is, but it seems like not allowing all these types of unqualified certs actually creates a much larger problem from a usability and behavior perspective.

     

  • Anonymous on

    Distributing certificates via DNSSEC seems like a good idea to me. Has a protocol for doing so been developed yet?

  • John Nagle on

    Name names. Tell us what CAs signed bogus certs, and the root certificates thus compromised.  Those root certs need to be removed from our system, and from various browsers.

    John Nagle / SiteTruth

  • Carl Peterson on

    Can you justify "They should also stop signing IP addresses — especially private, non-routable addresses — and should revoke existing IP address certificates, too"?  I would agree for non-routable IP space but what's the justification for not signing certs for real IP addresses?  

     

  • Melinda on

    Clearly CAs should not be issuing certificates for unqualified names, but I tend to think the bigger problem is that browser certificate validation processes are accepting them.  Also, I'd dispute that the downside of creating a corporate CA has much to do with "the work to configure your OSes and browsers to trust your certs."  If you've got reasonable provisioning mechanisms that's not a problem.  The bigger problem is making sure that your CA is adequately protected and can't be subverted by a hostile insider, potential liability issues, and the near-impossibility of getting your root cert accepted anywhere else.

  • Anonymous on

    Actually, you can get your CA trusted by Verizon's OmniRoot. The CAs do not want you to know this. Verisign even told us that it was not possible. We now have our own CA that is trusted to issue certificates for our domain only.

  • Anonymous on

    The infrastructure should move toward multiple certificates by independent CAs so if one is hack the system is not compromised. The process should also get improved, say it should be like getting a governmental id card. Using localhost and similar addresses is ridiculous. There is no need for them. It is plain obvious that if you have a unqualified domain it should not get a certificate. Certificates are not made for that purpose.
  • Anonymous on

    And... what if we started using serious encryption and authentication for a change?

    SSL was designed to make it as cheap as possible to bypass or break.

    It might be a good time to think about what that means.

  • kogawam on

    Seems that your SSL cert for this site is expired...

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.