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.'"
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.
Invalid argument: Free SSL certificates: http://cert.startcom.org/.
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.
How we know is more important than what we know.
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.
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.
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.
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...
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.
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.
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...