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.'"
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.
Only 120 characters... who can summarize their entire world understanding in 120 characters?!
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.
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.
but why do I need to check my own ID?
MiTM attack. e.g. using an internet cafe, which installs a transparent SSL proxy and can monitor all your transactions. Its OK if you have your own browser device, and previously installed your SSL certificate over a secure channel. But if you get the 'stop sign' over an insecure channel, take it seriously. They don't need to clone your server to compromise you, just a man-in-the-middle.
That number seems high. I've seen many cases where a server is configured both at the correct address (say, www.foobar.com) and at another address which is not embedded in the cert (foobar.com). Depending on how you access the site you'll either get a perfectly valid cert or an invalid certificate message.
While a setup like this is improperly configured, it may not matter that much. If nearly all visitors access the site via the correct domain name, the SSL cert is probably doing its job.
"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.)
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.
22 million virtual sites sharing IPs where only one site on an IP really needs the SSL, and the other sites weren't configured to only listen to the http port(s).
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.
For that you should be using the Perspectives Firefox Add-on. It checks with several notary signatures if the SSL key looks the same from everywhere. If it doesn't, it flags it.
Encryption without authentication is pointless. There are readily available tools that will allow a script kiddie to man-in-the-middle SSL communication with just a few clicks. This can be done from the same wireless network, physical network, or at any node between the source and destination hosts. Encryption without authentication is nothing but a false sense of security.
It's the distribution, stupid.
A self-signed cert that you just click "accept" for is worthless. It could've been useful, if you'd transferred the cert out-of-band and added it directly to the trusted list, but if you're fetching it off the internet, you've no idea whether the cert you're getting is the real one or not.
CA's are a tool for consolidating the certificate transfer process. Instead of having to manually install every certificate, you really only need to manually install through some trusted process, a single certificate that can sign all the others (presuming you have reason to trust their reasons for trusting)
Of course, nobody does that either, and using the certificates built-into a browser you downloaded insecurely is just as dumb as using self-signed certs off the net without any out-of-band component....
Can you be Even More Awesome?!
We had a decent Infosec guy at our shop, then he left the group, and they bought a Qualys scanner. Now I get chimps telling me that I might be affected by an Apache 2.0 bug, and so I'm vulnerable. I ask what the bug does, and nobody can say, other than "The Qualys test failed". Great. If I send in enough box-tops, can I get my CISSP too?
I want to delete my account but Slashdot doesn't allow it.
Funny, when Firefox went to the new style of annoyance (three step process) I made a post on the message boards to go back to the older style where it just prompted that it was invalid, click okay and you kept going. The devs/admins/users blasted back about how it was needed, how it helped, etc, and just as told them (a year + ago), finally research shows that most certs are invalid and out of date, but thats allllright because I quit using FF. It just scares me that the people that are smart enough to be involved with the programming and management of one of the most used web browsers have no insight to how the web is operating beneath them, don't they ever surf outside the mozilla domain? Weird.
Many moons ago, when I worked for a web hosting company, they had Host Header servers for the low-cost customers.
A given server may have hosted up to 1,000 customer sites all on the one IP address by using the Host header introduced in HTTP/1.1 on tcp/80 (http), but they still had a single SSL certificate representing the server itself on tcp/443 (https). A reverse DNS lookup on the hosting IP returned the server's FQDN, which matched what was on the SSL cert's CN. Apparently this was something commonly done in the web hosting industry due to the ever-decreasing pool of IP addresses (this was in the days before TLS/SSL had mechanisms for clients to request a given certificate CN during the negotiation phase).
I wonder... did the discussed tests perform a reverse-DNS lookup on the web site's IP address before trying to connect to the https port? Was the result of that reverse DNS lookup used to compare against the SSL cert's CN, or did the test blindly assume that the CN must match the original site's FQDN?
Think about their conclusions for a second. They are saying the SSL certs are worthless because the CN does not match the hostname. Why would millions of sites continue to pay ~$100 each year for a cert that will spout scary warnings in ALL browsers when their customers visit their web site? Surely this number of commercial organizations are not being that retarded so there must be an alternate explanation. Namely the author of the article and or Qualsys are total morons who are wasting our time.
Of those systems they reached how many happen to have multiple DNS records pointed at them and the domain they tried would never be used by any human person actually accessing resources of a site?
Of the systems they reached how many have a valid certificate chain? (IE were actually signed by a well known CA) vs certs that just have ssl certs installed by default with web servers or web based application servers?
How many times do you go to your bank or shop for something online or check your email and experience a cert CN/hostname mismatch error? I would be willing to bet that for most of us the answer is very close to 0.
Just discussed that here a little while ago.
Certificates may actually be perfectly valid without using the same host name as shows on the Internet, many people already gave reasons for that here on /. in this story.
I want to add that it may be that the wrong side here is the browser, not the certificate.
Treating a site that does not do https and sends data in clear text with no contempt, while treating sites that use self signed certificates as if those are broken criminal sites?
It's like treating clear text passwords (and other data) better than passwords sent over https.
Shows a clear agenda on the part of browser producers - create more revenue for the "signing authorities". Well, who are these signing authorities, how do we know they can be trusted, and what kind of a security theater is this - paying someone so that you / others can trust them? Makes no sense, the entire concept is borked.
Sites need to publish their fingerprints clearly and browsers need to behave properly - at maximum give a warning that the cert is not registered with a CA, but do not try to prevent people from using the site!
You can't handle the truth.
We're expected to shell out thousands to SSL 'companies' whose job it is to confirm what we already know. Especially the likes of GoDaddy, who wanted more info for my domain than I need to get a passport, bank account, driving license, pretty much anything else. The result? Bugger off, don't need it anyway. Now repeat into the millions.
It doesn't help that Exchange and IE both scream about SSL Certs - it's just one more thing people ignore.