Slashdot Mirror
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.'"
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.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"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.)
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.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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.
In the Microsoft world, SSL Certs are primarily used for Sharepoint, Exchange Webmail, Outlook Anywhere, and Exchange ActiveSync for iPhone, Droid, and other PDAs. You can't configure them wrong or you'll know immediately that the implementation is broken. So how in the hell can we have 22 million invalid certs?
Life is not for the lazy.
Most people don't care. How many commerce engines are running in the background handling transactions? As long as the point to point transaction is "secure", who cares if its linked to the domain. The vast majority of people running mom and pop shops, or even in the tech industry doing dev / testing, don't care about tying certs down to a domain because they use lots of domains / change often and its a pain and viewed as a waste of time to manage all of them.
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.
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/ if you want to confirm it for yourself.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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.
I'm too lazy to compose a creative sig.
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.