22 Million SSL Certificates In Use Are Invalid 269
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.'"
Duh (Score:5, Interesting)
No Big Deal (Score:5, Interesting)
"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. (Score:4, Interesting)
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:Duh (Score:5, Interesting)
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/ [example.com] may point to the same IP address as https://secure.example.com/ [example.com], but you're still going to get an SSL-secured response from https://example.com/ [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:Two reasons for SSL (Score:4, Interesting)
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.
Comment removed (Score:3, Interesting)
Duh (Score:2, Interesting)
It's all too hard (Score:3, Interesting)
When it was my job to install SSL certificates, understanding it, buying the right certificate and installing it was freakishly difficult. Everyone from the certificate issuers to the server software providers needs to get together and simplify the whole process.
Re:Duh (Score:4, Interesting)
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.
Re:Two reasons for SSL (Score:3, Interesting)
They've been supported for a while now, at least in Mac OS X. (I qualify that because I'm not 100% sure they don't pull in the OS's trusted roots.) Point Firefox at https://www.gatwood.net/ [gatwood.net] if you want to confirm it for yourself.
Re:Two reasons for SSL (Score:3, Interesting)
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 (Score:5, Interesting)
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.
Re:Two reasons for SSL (Score:3, Interesting)
It's a money making scheme - if you look at the "fees" one has to shell out for certificates - has absolutely nothing to do with effort necessary to provide a certificate.
I'm guessing you think the "effort necessary to provide a certificate" is not much more than the cost of computing the hashes for the certificates, right? Everybody knows that OpenSSL is free, open-source, and is available on a freely downloaded Linux ISO and burned to a $0.10 blank DVD, right? And a $25 P4 could calculate thousands of these hashes every hour!
As somebody who almost became a Certificate Authority, I can say that it isn't all that easy. Most of the problem isn't technical at all. In fact, the technical part is basically insignificant. Most of the problem lies in certification, and much of that lies not in the technical and/or organizational solutions, but presenting the technical, organizational, and financial solutions in a way that can be independently verified. (yes, financial too - would you trust a CA that wasn't profitable?)
Do you do backups every night? Maybe you do, but can you prove it? Who does the backups? How do you make sure the backups were done? How do you guarantee that the backups are only handled by qualified personnel? How have you qualified the personnel? How do you handle a failure scenario, or worse, a disaster scenario? In the event of a disaster, how do you *still* ensure that only qualified personnel handle the backups and/or data?
And on, and on, and on. It's a much tougher problem than you could possibly imagine. For our small company (~15 employees) we figured it would cost us between $50,000 and $100,000 to get the necessary audits and certification done, including implementation, to become a certified Certificate Authority. The costs get worse and more expensive as you scale upwards.
Even at $100/certificate, it takes a *lot* of certificates just to break even. I'm not saying that Verisign et al aren't highly profitable, I'm just saying that the reasons they are there are good reasons, even if they are somewhat guilty of gaming the system a bit.