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

Two reasons for SSL

[EconomyGuy]

Two reasons for SSL: verification and encryption. Sure, if the domains don't match you don't have verification, but the communication is still encrypted, and if you happen to control both ends of the exchange, that's all you need.

Re:Two reasons for SSL

[marcansoft]

Unfortunately, all the browser vendors decided to implement this backwards and instead throw around ridiculously alarming warnings at the user if you dare use SSL for encryption only, and not verification.

You know, instead of the sane thing, just dropping the lock icon or otherwise indicating diminished (but not nonexistent security). Find that a non-expiring cert changes or a page with a verified SSL cert suddenly has a non-verified SSL cert? Then scare the living hell out of the user.

Re:Two reasons for SSL

[Deorus]

The worst is when they even force users to add exceptions just to watch random websites (Firefox, I'm looking at you). Now not only do I have to deal with the annoying warning blown out of all imaginary proportions, but I'm also adding an exception to a random website just because I want to browse it once in a life time that I may never remember to remove in the future and may cause real security issues later.

I really can't understand what's so wrong with temporary exceptions...

Re:Two reasons for SSL

[DragonWriter]

Two reasons for SSL: verification and encryption. Sure, if the domains don't match you don't have verification, but the communication is still encrypted, and if you happen to control both ends of the exchange, that's all you need.

If you don't control the whole path between (in which case, you probably don't need encryption), the absence of verification renders encryption pointless.

If you control both ends, there is no reason not use valid certificates (both matching the domain and signed by a CA -- your own, if nothing else).

Invalid certificates of the type at issue (not matching the domain) usually mean you've bought a certificate from a commercial CA, and are using it on a domain other than the one you've bought it for, possibly because you have different domains that resolve to the same address (domains with and without "www." prefix where both use the same certificate that is intended to have the "www." prefix are the most common ones I've personally encountered on the web.)

Re:Two reasons for SSL

[no-body]

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.

Part of the great pyramid where all the money is rising upwards to a small top, partially fueled by the - is it the dripping down - or trickling down - fantasy.

Verisign must have severely lobbied (greased) the browser vendors...

Certs should be issued by the government, like passports - for a reasonable fee. Probably a dud in US where free market rules with great results as one more and more can see.

Re:Two reasons for SSL

[fyngyrz]

Certificates don't ensure you're talking to anyone in particular, other than someone who has managed to get their hands on the certificate, which, based on prevalance of rooting and etc., could be quite a range of people.

Certs reliably encrypt traffic between the two endpoints. That's the entire usefulness to the two endusers.

HOWEVER: An entire deceptive financial ecosystem was created when the browser manufacturers put those "scare the heck out of the user" dialogs in there; that meant that ecommerce types *HAD* to get certs that would not raise those warnings -- meaning, buying a bag of bits from someone else, a bag you could have made yourself for free, for all the good it would do you, instead purchased for $50 (or many more) dollars.

It's all based upon one key falsehood: The idea that a cert "assures" you that you're talking to someone in particular. As opposed to the guy who physically walked up to the machine while root was logged in, lifted the cert, and walked away. As opposed to the guy who rooted Apache or Postgres or etc., went in, lifted the cert AND the access to the DNS server, and disconnected. As opposed to the guy who has rooted the DNS elsewhere and has your cert.

It's 100% pure bunk. Certs encrypt. Probably not from the government, but from your average hacker, yeah, they generally succeed in making traffic look like a mess of indecipherable bitrot. That's all the actual service they're good for. That, and keeping browser warnings from ruining your attempt to do e-commerce. Just remember: The latter problem was *caused* by the browser writers in collusion with people like Verisign. The problem didn't exist until they put their heads together.

Reminds me very much of the government's war on drugs. The violence, the killings, the black market... 99.9999% a consequence of stupid, stupid rules, every one of which the government is entirely responsible for. Here, every scared consumer was created by the certificate "authorities" in conjunction with the browser makers. They created a fear of a non-issue so strong that everyone was forced to get in line and pretend (or be bewildered into thinking) that the threat was resolved with the purchased certificate, when that is utter bunkum from start to finish.

Re:Two reasons for SSL

[forkazoo]

You folks all know why this is right ? I mean what is the use of SSL-encryption if you don't know who your 'talking' to ?

Yeah, because talking to somebody whose identity I can't be sure of over an encrypted link is *soooo* much worse than talking to somebody whose identity I can't be sure of over a link that can be trivially sniffed. That's why telnet is better than SSH.

Which would be semi-significant if having a "proper" SSL cert actually gave me an iron-clad guarantee that I was talking to who I thought I was talking to, which it naturally can't.

Almost completely useless as a result.

[Gavin Scott]

This week I'm helping a customer with some remote testing with a large hosting company who provides remote system console access via a Java/Web thing.

They sent me a PDF with the instructions for logging in that have a couple pages dedicated to telling you how to ignore the fact that all their certificates are expired or simply invalid, and tell you to check the "Always trust content from this publisher" box in order to eliminate the need for one extra click.

How can we ever expect to get any use out of this stuff if we're constantly training the users to ignore everything the security software is trying to tell them?

It seems to be considered completely acceptable behavior by very large well-known companies too.

G.

Re:Almost completely useless as a result.

[Alwin Henseler]

How can we ever expect to get any use out of this stuff if we're constantly training the users to ignore everything the security software is trying to tell them?

We can't, and we shouldn't. When users regularly see warning messages that are abacadabra to many of those users, the effect is predictable (and well understood): user won't read warnings anymore, and just do whatever is most likely to make the warning disappear.

At that point, you're just wasting user's time, making sure that genuine serious events dive below the radar, and waste system resources / application code (warning dialog boxes, etc) that doesn't get you any real-world gain. Which means that overall, you're doing worse than if you had just silently ignored those warnings.

If you want secure: make it work, solid, and easy to use. If that's too much to ask, better forget about it - a half-baked feeling of security is worse than being aware of its absence.

So an obvious better solution would be to handle invalid/broken security tokens for what they are (non-secure), and don't bother users with it other than small (visible) clues that could be checked by users who care and/or know what they're doing. Eg. expired SSL cert in a browser session -> no warning dialog, show URL like regular URLs in address bar (vs. special markup used for secure connections), and open/no lock icon in status bar.