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

[QuantumG]

So you want defense against snooping but don't care about defense against MITM attacks. Fair enough, I'm all for raising the bar, but don't be lured into thinking your communication is secure.

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

[LordKronos]

So you want defense against snooping but don't care about defense against MITM attacks.

Yes, that's exactly what I want as the minimum requirement. Snooping on traffic is incredibly simple to do, and can really be done easily by anyone at any point along connection path. You just start up a packet sniffer, grab random packets, and wait until you catch something interesting. You don't even have to catch an entire session. Successfully pulling off a MITM attack is MUCH more complicated...requiring something trickier, such as hijacking DNS. You can't just be at any random point along the chain and perform the attack on any random connection coming through.

It's like a lock on my front door. I don't delude myself into thinking that nobody can get into my house, but the lock is a safeguard against the easiest attack vector.

Re:Two reasons for SSL

[marcansoft]

The Certificate Patrol extension for Firefox will. It'll tell you when a certificate changes and whether it should (e.g. whether it was near its expiration, and whether the issuer has changed).

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

[izomiac]

Most people couldn't even tell you who the trusted certificate authorities were on their browser. From there, I'd say the number of users who personally trust all of them approaches zero. Knowing that you're connecting to the same entity on every connection would prevent most MITM attacks.

Of course, ideally, we'd verify the certificates over physical means. Until there's an easy way to do that you always run the risk of connecting to an impostor. OTOH, people are happy to give money to a random company (e.g. VeriSign) that promises security without requiring any change in behavior.

Re:Two reasons for SSL

[bunratty]

The last I checked, startcom certificates are not recognized as valid by Firefox. I purchased a five-year certificate from rapidssl.com for $60 a few years ago, and the certificate is recognized as valid by all major browsers. The cost is minimal.

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

[forkazoo]

Firefox allows you to make temporary exceptions; you're just not doing it. When you click on the "Add an exception" button, followed by the "Get Certificate" button, there's a checkbox with the text "Permanently store this exception". Guess what happens if you leave that box unchecked and click the "Confirm Exception" box? A temporary exception is made.

It is technically possible, but when it is hidden behind so much terrible UI, it barely matters that the feature technically exists. Most users would rather have their identity stolen than have to wade through that mess. Frankly, losing all of your money, and spending years sorting out the consequences of identity theft is a lot more convenient than the Firefox cert warning UI.

Re:Two reasons for SSL

[marcansoft]

If you connect to your bank through HTTP (and aren't redirected), nothing will save you from an attacker stealing your bank details unless you notice the lack of a lock icon indicating an SSL connection. This is exceedingly likely if, say, Joe Average user just types www.bank.com in his address bar and an attacker hijacks his connection and replaces the usual redirect to HTTPS with a man-in-the-middle attack on the bank.

Therefore, it makes zero sense to throw huge warnings for untrusted certs and yet do nothing for plain old unencrypted HTTP.

The only sane way to implement SSL warnings is to use memory. This gives you increased security (why did ChinaSSL suddenly start providing my bank's certificate? Right now, if that happens, you're 100% screwed) and avoids annoyances (no huge four-click warnings if you visit a site for the first time and its certificate is not verified by a CA).

Right now we're in the ridiculous situation where the least secure connection (HTTP) is given preferential treatment over the somewhat secure connection (unverified HTTPS), and yet the most secure connection (verified HTTPS) is both less secure than it could be (no sanity checks, if any CA signed it then it's good) and can be trivially downgraded to insecure HTTP, depending on the user's browsing habits.

This nonsense prevents widespread adoption of HTTPS for personal and noncritical sites. If browsers shipped with something like Certificate Patrol (tweaked for user usability instead of paranoia, avoiding dialogs during "normal" situations) and ditched the stupid warnings for untrusted SSL certificates (if they've never been seen using a trusted cert) it would go a long way towards encouraging the use of HTTPS and the Web would be a much safer place as a result.

Right now, if you go connect to www.mybank.com (which defaults to HTTP) and your connection is hijacked, unless you notice the lack of a lock icon, you're screwed. This is no worse than having an unverified SSL cert served and having the browser not display the lock icon as a result. It's definitely worse than the proper implementation, where the browser would warn you of an unencrypted connection that's usually encrypted, or having an unverified SSL connection that was previously seen as verified.

Re:Two reasons for SSL

[Lincolnshire Poacher]

> I purchased a five-year certificate from
> rapidssl.com for $60 a few years ago....
> The cost is minimal.

It's not just a cost issue, it's the principle.

You bought a "five-year" certificate. Why does it expire in five years? Does it spoil like milk? Do the bits wear with repeated use? No, it's a scam. RapidSSL don't have do do a single thing after generating the cert other than awaiting your next payment.

According to:

http://www.rapidssl.com/buy-ssl/index.html

they will sell us a "wildcard" cert for the low-low price of $796 for five years. So I correct myself; it's the cost AND the principle.

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

[amorsen]

the reason 5 years is a bad idea is, because the bits can get guessed (brute force). This usually takes a lot of time, but it doesn't have to be and you should use a new one pretty much every year.

That is ridiculous. If you're afraid of brute force, use longer keys.

As it is, people use the same private/public key pair for the next CSR anyway, so expiry doesn't protect you from brute force anyway.

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.

Re:Two reasons for SSL

[Klaruz]

'the army' isn't one big magical network, it's actually hundreds of separate AD domains, and there is more than one branch of the military, some fly planes, some sail ships, some get shot at, they all have different ways of finding people to manage those AD domains. Some suck, some don't. I can tell you those that don't suck do indeed install the correct certificate authorities.

Re:Two reasons for SSL

[arose]

I'm aware of the mess most SSL authorities are. Just amused by the notion that somehow the rubberstamping is worth $60 (cheap even!).

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.

Re:Duh

[Pharmboy]

Also, every dedicated server has SSL for logging in (Server Beach, etc.), and the certificate never matches the domain, typically localhost.localdomain or similar. If you aren't doing actual ecommerce, then there is no reason to buy a certificate if you can instead just create one or use the self generated one, and either ignore the warning on your client, or install the certificate on the client as trusted (one mouse click). So to this "poll", it would appear to be incorrect, although it is perfectly fine and secure for the purpose it is being used for.

i.e. 22 million virtual sites

[Culture20]

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).

Epistemology, bitches!

[zippthorne]

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....

Qualys = Security for Dummies

[Gothmolly]

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?

Re:Duh

[durdur]

It is not secure if you can't verify the host you are connecting to. Having a valid certificate that matches the host helps ensure that you haven't connected to some rogue site that is masquerading as or acting as a proxy to the site you think you are connecting to. That is not as unlikely to happen as you might think.

But it not only end users who decide not to care about this. As other posters have noted, it costs money to be compliant. It also costs some time and trouble to generate and set up a proper certificate chain. And the perceived cost of not doing this is small - it still works, just click on through the warnings. But there's still a cost - maybe a big cost if an successful attack is launched against the site.

Non-browser apps that are SSL clients also frequently fail to verify host certificates, because their developers are too lazy to implement it and/or not security conscious enough to consider it important.

Sounds like flawed assumptions to me

[scdeimos]

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?

Worthless article written by total idiots...

[Anonymous Coward]

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.

Re:Mod parent up

[Anonymous Coward]

Encryption without authentication is not pointless. Encryption stops passive third parties from listening in. Maybe you're not talking to the entity you thought you were talking to without verification, but at least only the party on the other end can read your message.

I don't think this kind of connection should be represented by the lock or the colored bar or anything like that, but it's foolish to say there are no advantages over totally unencrypted traffic in these days when our ISPs sell our personal data and governments are increasingly monitoring Internet traffic.

Why can't the browser just encrypt things and make no claims about identity verification? Whatever the reason, it smells really fishy.

Since encryption isn't actually affected....

[Tomsk70]

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.

Re:Mod parent up

[AusIV]

Maybe you're not talking to the entity you thought you were talking to without verification, but at least only the party on the other end can read your message.

Any party along the way can read your message if there's no identification. If I'm trying to talk to https://example.com/ without identification while any node between me and example.com is compromised, that node can establish an encrypted connection with example.com and an encrypted connection with me. I send the attacker encrypted data, the attacker decrypts it, logs it, re-encrypts it for example.com, and forwards it along. This does require an active role, but there's no reason to assume someone who wants to steal your data is going to assume a passive role. As I stated in my last post, you can take an active role simply by being on the same network (wireless or otherwise) as your victim.

it's foolish to say there are no advantages over totally unencrypted traffic in these days when our ISPs sell our personal data and governments are increasingly monitoring Internet traffic.

But encryption without identification offers little practical advantage in this case. Your ISP could man-in-the-middle your HTTPS connection, collect data, and continue selling your personal data.

Why can't the browser just encrypt things and make no claims about identity verification?

They tried this for years, and users kept giving up sensitive data to phishers. Most users don't check for the lock or identity information like they should. The current approach that browsers are taking puts more control in the hands of the destination website. If the web server is requiring an HTTPS connection, the browser assumes the connection needs to be secure. If the HTTPS connection doesn't provide identity information, it is susceptible to man-in-the-middle attacks and cannot be considered secure. Since the web server is effectively saying it requires a secure connection, and the browser cannot consider the connection to be secure, it tells the user that something is wrong and they should take extreme caution if the choose to proceed.