22 Million SSL Certificates In Use Are Invalid

darthcamaro writes "While SSL certs are widely used on the Internet today, a new study from Qualys, set to be officially released at Black Hat in July, is going to show some shocking statistics. Among the findings in the study is that only 3% of SSL certs in use were actually properly configured. Quoting: '"So we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside," Ivan Ristic, director of engineering at Qualys, said.'"

Comments

Duh

[afidel]

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Re:Duh

[NNKK]

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Wish I had mod points. I was about to post the exact same thing.

Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ may point to the same IP address as https://secure.example.com/, but you're still going to get an SSL-secured response from https://example.com/, just not the one you might expect).

One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

Re:Duh

[man_of_mr_e]

Indeed. I bet there is a very large percentage of these "misconfigured" SSL certs that are in the list for this very reason. Just because you can get to an IP by a given domain name doesn't mean that's the domain it's intended to use SSL with.

Also, think about all the millions of firewalls and routers out there with enabled WAN access and a bogus ssl cert just to make it work. Think of all the development servers, think of all the self-signed certs (which whould show up as invalid to the researchers because they're not configured to accept the self-signed cert).

I would highly doubt any mroe than 20% of those "misconfigured" servers are actually misconfigured ssl certs for real sites.

No Big Deal

[harryjohnston]

"Only about 3.17 percent of the domain names matched," Ristic said. "So we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside."

If you think about it, though, all he really knows is that the certificate does not match the domain name he used to connect to the server, which may not be the domain name which is meant to be used. The obvious next step would be to attempt to connect to the name given by the certificate, which might well point to the same actual site. Of course, it might be a name that is only valid for an internal network, not on the internet as a whole.

There are also lots of contexts in which a web server includes a default (usually self-signed) certificate with a generic name out of the box - typically web servers used for management of a software or hardware device. If the users don't need SSL, there's no reason for a "valid" certificate to be installed.

In short, he's using the phrase "in use" poorly; the fact that a server responds to an SSL request with a particular certificate does not mean that the certificate is "in use" in any meaningful way.

(These figures might be more meaningful if he had excluded self-signed and locally-signed certificates, looking only at those generated by a known certificate provider. Because they cost money, the latter are more likely to have been intended for actual use, although the actual use still might use a different URL than the one you are scanning.)

Re:Almost completely useless as a result.

[kimvette]

Why pay for a root-issued certificate when a self-signed one will do perfectly well when it's a known-safe server accessed only by a few authorised users? Just click through the "add exception" or "install certificate" dialog and be done with it.

Re:Two reasons for SSL

[marcansoft]

It's considerably secure if your browser caches the certificate and puts up a warning if it changes. Then you need to be MITMed on your first visit for it to be effective, and then it has to keep up or you'll notice.

This is how SSH verification works, and I don't see many people getting MITMed, even if you don't usually check the fingerprints.

Re:Two reasons for SSL

[mysidia]

Yes... it was a total disaster... fortunately, in the future DNSSEC should make SSL certificates obsolete.

If we can publish digitally signed records in the DNS, which are verifiable with the registrar, it's not too farfetched to say define a signed TXT record which will contain public key information for the web server.

Re:Two reasons for SSL

[dwillden]

No the worst is trying to use a military computer (means only IE) to hit military sites, and having to approve half a dozen exceptions each time you visit a new page.

They seem to be unable to use standard certificates or even attempt to register them with internet registries. The best is working on a classified network. And getting "WARNING!!! This page may be unsafe! WARNING!!!" notices on an entirely closed and encrypted network.