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?!
that's because SSL, even misconfigured SSL, provides a layer of encryption to thwart network packet sniffing... most people don't care about the potential for SSL to establish a higher degree of "trust"... they just want encryption.
I use non-conforming SSL all of the time... to get back to my own servers where I don't need to verify organizational integrity, I just want an encryption layer protecting me from snoopers.
Yeah, I'll honor the stop sign if a site asking me for money or access to another account can't verify itself, but why do I need to check my own ID?
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.
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.
Furthermore, valid certificates are now suspect.
For some reason, I thought this common and recurring problem was mine. "How could so many sites have this mismatch?" Duh, silly me. Next thing I know, my bank will lose all my money, and my home will drop in value below my mortgage balance. Nah, never happens.
Presumably a lot of these are just domains hosted on some shared box at a cheapo web host that happens to have an SSL port open, probably for the administration control panel rather than for any of the domains it hosts.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Oh yeah, she is a high class bitch.
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.
I remember reading a comment to the effect that:
"Using SSL to secure transactions between desktop browsers and web servers is like using armored cars to transport bags of money from one park bench to another."
In the free world the media isn't government run; the government is media run.
Surely they do. Over the past month I have generated about 10 million SSL certificates two times within my own PKI infrastructure just for the pure purpose of scalability and load testing and reproduction of production affecting issue. I do wonder who was the shmuk that generated the other two million.
How about companies that use publicly registered SSL certificates for private LAN servers?
Too many wholesale assumptions here.
While I doubt the 3% for several reasons other people have mentioned, I have noticed just how freakishly evil it is for even otherwise competent admins I've dealt with to get SSL certs working properly. It seems like something that's so important yet so seemingly designed to thwart you at every turn is either a horribly bad and cobbled together design (it's certainly /fragile/) or specifically intended to increase Verisign's consulting and certificate generation revenues.
Did anyone else think they meant only 3% of sites didn't match? 3% of sites do match - wow.
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?
So what I care about is the encryption side of SSL., I perceive that snooping is more likely then stolen card numbers as I am pretty careful about what online shops I use. But its all a crap shoot.
6.8SPC TR of 550, l xwind at 6, drift rt at 26" drops 77". AT has 503 ft-lbs at 1403 fps. FT 0.86
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.
I suspect that most of those are for 'private' use. I personally have a self signed certificate so that I can do secure webmail from anywhere. Webmail is at a public address where anyone can see it, so a check would show an invalid cert. But in reality, it doesn't matter at all.
The number are skewed and probably meaningless because I strongly suspect I am not the only one doing this.
In my case I only have three domains connecting to one server, others have many more. Of course only one third of all random connections in my case will succeed. Obviously that one domain is where I expect any legitimate SSL requests to go.
This study is bogus, and I can say why. Let's say you have a web server, and let's say it has a few dozen name-based websites hosted, one of which uses SSL for a shopping cart. If you "scanned" the server by domain name for SSL support, ALL of the name-based virtual hosted domains would "reply" because SSL is IP-specific, not domain specific. Thus, with 25 domains, all would "support" SSL with mis-matched domain names.
This problem is WORSE when you have multiple IPs on a single server (as I've done many times in the past) because even though all the domains "support" ssl and many even have their own legit SSL websites, those SSL IPs will be in a different IP address and thus a different subdomain. (like shopping.domain.com instead of www.domain.com)
Numbers this far out of line simply show gross ignorance about how SSL is actually applied.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
In the present context, there is no such thing as a valid SSL certificate.
Until the browser can tell the difference between your bank's cert and a driver vendor's cert, you can't meaningfully tell the browser to trust a cert.
But, really, you shouldn't be doing bank business with the same browser that you use for downloading drivers.
My argument is that every cert is invalid.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Microsoft lead the world in bulk-loading certs in the browser, because they wanted to put that "feature" on the label.
You can't bulk-load certs in the browser like that unless the browser is able to delineate all the contexts successfully. No Microsoft browser I know of is able to properly delineate contexts.
The best way to solve the problem would be to quit trying to build an all-in-one browser, but Microsoft engineers can't understand that concept. (That's part of the reason they can't properly delineate contexts.)
Even though Microsoft's software will tell you that it thinks the cert is correctly or incorrectly configured, any time it tells you the cert is correct it's lying to you.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Certificates are used to the essential minimum, and mostly for the one purpose of encryption in place of encryption+verification, because they are highly unpractical
.
In 2010 admins still have to openssl around with tiny text files holding a cert or a key, or get crazy about a stray comma or space in a CN.
In short: certificates are not up to their task, as a much primitive way to identify the parties based on text. No surprise a majority of users ignore their validation role.
Bad luck is that:
1. Big business is happy enough with that and does not see that change (again, what a surprise)
2. As a support of 1, there is an intricated business web for certificate root validation, sale (above all) and renewal.
Trusted Roots can have huge turnover, charge sometimes absurd amounts for a piece of text they signed but above all they keep the business patient alive. So
a. I don't see any change on short notice there. This is 2010, creativity is dead or forever copyrighted, remember?
b. If people use self signed or simply don't bother building a good chain of trust, I'm not worried. I carefully look after my counterpart ("is this the right website?"), which I often trust more than their CA, whereas I generally trust nobody on the Net, anyways.
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.
You can explain a good chunk of this as the result of Akamai's world-wide content caching/load balancing solution. The default Akamai plan doesn't get you SSL support, but the thousands and thousands of web servers they have (which host a good 10% of the Internet's web traffic, last I heard) will all reply on the SSL port, and will present a certificate for an Akamai domain name, whether you connect to ocw.mit.edu or www.whitehouse.gov or www.mtv.com or whatever it may be.
In general, this can also be explained by servers that happen to listen on port 443 but aren't intended to do SSL.
HTTPS withouth a signed certificate can be compromised, but wen you browse the web on a open wife, or a promiscuous lan, maybe all you want is your trafic to be send encryped as oposed to clean text. So SSL withouth certificates (read: self signed) is usefull, and part of all these warnings are scare tactics to get people buying SSL certificates.
-Woof woof woof!
because, you know, cpanel and similar control panels are very dominant in hosting, and each box houses hundreds of sites. and cpanel and other firms do not go buying certificates for each server license they issue, and the hosts that are using those cpanel/whm installs do not require all the 200 or so clients using the same box buy their own server certificates to reach their own control panels. therefore, the certificates are self issued. ie mydomain.com/cpanel will redirect you to very probably a ssl connection, but the cert wont match the domain. there isnt anything wrong with this either, these people just access their own site's control panel themselves and need encryption for it. they dont need to verify that their own domain, is their own domain.
did that guy calculate this in to his bots that were doing the research by crawling ?
Read radical news here
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.
CAs actually hand out certificates to anyone who happens to have too much cash in their hands, the bigger, the more probable. IMO, each country should have a local CA that are viewed as trusted and sign only certs of local businesses/private people. The government probably knows most about you and your trustworthiness.
I have read articles similar to this where the company spends a fortune on Versign certificates and they are not configured right and a security breach happens.
http://www.thetechnologygeek.org
If browsers simply refused to operate with broken sites, the sites would have to get fixed. End of story. The warning message should indicate the site is the problem.
not checkboxes and button trees and other stupid stuff, the choice needs to be 3 buttons,
make permanent exception, temporary exception, ignore
Step 1: Generate root certificate
Step 2: Develop clear, easy to understand instructions on how to install your root certificate on all popular browsers. Include any software necessary, and instructions to bypass all warnings.
Step 3: Develop dancing hamster or similar popular site
Step 4: Protect site with cert signed by your root certificate. Include pointer to instructions developed in step 2 to get rid of browser warning.
Step 5: ???
Step 6: PROFIT!
Does he have a brother named Hugh?
Thank you, I'll be here all week.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
How long until we get a server/browser plugin set to allow the use of AES (or a similar simple, common encryption scheme)? Users would trade public keys with the server when registering for a website. The website then sends any sensitive files through a encryption phase. The file is downloaded to a temp folder, unencrypted to HTML, and displayed on the browser window. Surely this would be a better solution than the needlessly complex SSL "solution"!
SSL is a scam; let's replace it with something that works.
I am angrier than usual because I had to spend hours struggling to configure a VMWare server through a browser interface that refused to work with modern web browsers, all because of nosy browsers which refused to accept its self-signed cert. *arrggg!!!!*
Since either your ISP, the government, or any number of other parties could be MITMing your connections, collecting the information, and using it or selling to third parties if you encrypting without authentication, I would maintain that the problems you cite are exactly part of why encryption without authentication is useless.
Protecting information isn't an all-or-nothing thing. Encrypting the traffic raises the bar for what one must do to listen in. No, it isn't perfect. But you're suggesting we should let "perfect" get in the way of "better", and I couldn't agree less.
There's no documentation in the article of either the results or the methodology - other than a vague description of a custom 1000 thread engine that was used for the probing.
There is mention of the number of domain names and SSL Certs issued - and some documentation of probing of ports 80 and 443, but no documentation of how many ports at 443 were scanned.
Bad article, not providing enough information to verify it's conclusions.