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

Re:I don't need to confirm my own idenity.

[quenda]

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.

Methodology?

[dachshund]

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.

Re:Two reasons for SSL

[seifried]

Invalid argument: Free SSL certificates: http://cert.startcom.org/ [startcom.org].

Re:Two reasons for SSL

[QuantumG]

Your view of both sniffing and TCP hijacking seems to come from the mid-90s. I recommend reading up on both the improvements of switched networking and on the active techniques developed to defeat them. But yes, MITM is harder to get right, just as these techniques were harder to develop than just turning the network adapter to promiscuous mode.. but once they're developed, it's just a tool that anyone (or bot) can wield.. and they have been already.

Re:Two reasons for SSL

[Anonymous Coward]

Even better when (yes, Firefox again!) the exception you are required to add ALSO changes the security mode used for Javascript! Sites you add exceptions for run as a Trusted Site and have elevated privileges.

Re:Two reasons for SSL

[apparently]

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

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.

Re:Two reasons for SSL

[seifried]

You need to install the intermediate Startcom SSL certificate on your web server but that is easy and extensively covered in the documents. Again, there is NO excuse.

Re:I don't need to confirm my own idenity.

[TooMuchToDo]

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.

Mod parent up

[AusIV]

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.

Re:Two reasons for SSL

[mysidia]

Actually it's checked by default, when you click 'get certificate'

And many times i've found after unchecking the box and going to hit the 'Confirm' button... it rechecks just after hitting confirm, and closes the window with a permanent exception added, despite my attempt to only add a temporary one.... very annoying Firefox...

Exactly

[Frosty-B-Bad]

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.

Not certificates, the Browsers are invalid

[roman_mir]

Just discussed that here a little while ago. [slashdot.org]

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!

Re:Two reasons for SSL

[Anonymous Coward]

The proper way to do this is by IT adding a custom CA root certificate into every deployed computer, and signing all of the individual private site certs with that cert.

Re:Two reasons for SSL

[PowerKe]

Don't click the 'Get certificate' button. Once you click 'Add exception' and the pop-up is shown, Firefox is already retrieving the certificate. When it has retrieved the certificate, the 'Permanently store this exception' box is checked. If you click, 'Get certificate', the process starts over again. So what happens is that you uncheck the 'Permanently' checkbox and the 'Get certificate' process will re-check it again just before your click on the 'Confirm' button is processed. Indeed, very annoying.

Re:Two reasons for SSL

[Securityemo]

The techniques behind ARP spoofing and DNS spoofing are quite simple, if you understand the protocols involved. And the automated tools (Ettercap et al) are so good and easy to use that people use them for office pranks.

Re:Two reasons for SSL

[bunratty]

CAcert withdrew their request [mozilla.org] for their root cert to be included in Firefox. Talk to CAcert about it.

StartCom free SSL certificates [startcom.org] now seem to work in Internet Explorer, Firefox, and Outlook out of the box. It looks like they're the best bet for free certs that won't display warnings in popular products.

Re:Two reasons for SSL

[ArsenneLupin]

That's why telnet is better than SSH.

On first connection to a given server does provide the server key's fingerprint, which you can (and should) verify against a reference obtained out of band.

And if ever the server's key changes later on, the client will warn you very loudly about it.

So ssh does give you some assurance that you are talking to the server you think you should be talking to.

Of course, somebody could still have rooted the server, or the server admin himself could be shady, but to protect against these is not the purpose of the certificate (even though it is frequently misunderstood as such).

Re:Two reasons for SSL

[ArsenneLupin]

That's why browsers are starting to add things like ForceTLS, which will add an interface so you can tell the browser to only visit a site with SSL

Those users most likely not to notice the lock icon will not know about this, and not know for which site they'd need to set this.

and for the website to the tell the browser (for a fixed time) to visit the site only with SSL.

Many big sites use SSL only on certain pages. So either the protocol's granularity is the domain, and those sites are screwed (either can't use the feature, or incur the SSL overhead even on those pages that don't need it), or the granularity is finer (precise URL within site) and the man-in-the-middle will just set up a fake login on a URL in the domain that is not marked "SSL only".

And many large sites (Facebook, I'm looking at you) don't care about making it obvious to users that they use SSL: the default login form is on a plain HTTP page, and even though the submission URL is actually SSL, there is no easy way (short of view source) for the user to check that this is (still) the case.

Case in point: a while back, a friend of mine asked me to help him find out his estranged wife's Facebook password. He still had control over her Internet router. We set up a man-in-the-middle which just patched the Facebook login form to submit over plain HTTP rather than HTTPS, and she didn't notice anything...

Re:Two reasons for SSL

[Anonymous Coward]

You need to upload the Certificate Authority for the Military pages to IE. I had to go through the same thing.... check here:

http://www.dtic.mil/dtic/announcements/dodrootcertificates.html