Slashdot Mirror

← Back to Stories (view on slashdot.org)

22 Million SSL Certificates In Use Are Invalid

Posted by kdawson on from the netcraft-confirms-it dept.

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

33 of 269 comments (clear)

  1. Two reasons for SSL by EconomyGuy · · Score: 4, Insightful

    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?!
    1. Re:Two reasons for SSL by marcansoft · · Score: 4, Insightful

      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.

    2. Re:Two reasons for SSL by Deorus · · Score: 5, Insightful

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

    3. Re:Two reasons for SSL by marcansoft · · Score: 3, Interesting

      It's considerably secure if your browser caches the certificate and puts up a warning if it changes. Then you need to be MITMed on your first visit for it to be effective, and then it has to keep up or you'll notice.

      This is how SSH verification works, and I don't see many people getting MITMed, even if you don't usually check the fingerprints.

    4. Re:Two reasons for SSL by LordKronos · · Score: 3, Insightful

      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.

    5. Re:Two reasons for SSL by seifried · · Score: 5, Informative

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

    6. Re:Two reasons for SSL by QuantumG · · Score: 3, Informative

      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.
    7. Re:Two reasons for SSL by Anonymous Coward · · Score: 5, Informative

      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.

    8. Re:Two reasons for SSL by marcansoft · · Score: 3, Insightful

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

    9. Re:Two reasons for SSL by DragonWriter · · Score: 4, Insightful

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

    10. Re:Two reasons for SSL by apparently · · Score: 4, Informative

      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.

    11. Re:Two reasons for SSL by no-body · · Score: 4, Insightful

      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.

    12. Re:Two reasons for SSL by seifried · · Score: 3, Informative

      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.

    13. Re:Two reasons for SSL by forkazoo · · Score: 3, Insightful

      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.

    14. Re:Two reasons for SSL by mysidia · · Score: 5, Informative

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

    15. Re:Two reasons for SSL by mysidia · · Score: 3, Interesting

      Yes... it was a total disaster... fortunately, in the future DNSSEC should make SSL certificates obsolete.

      If we can publish digitally signed records in the DNS, which are verifiable with the registrar, it's not too farfetched to say define a signed TXT record which will contain public key information for the web server.

    16. Re:Two reasons for SSL by dwillden · · Score: 5, Interesting

      No the worst is trying to use a military computer (means only IE) to hit military sites, and having to approve half a dozen exceptions each time you visit a new page.

      They seem to be unable to use standard certificates or even attempt to register them with internet registries. The best is working on a classified network. And getting "WARNING!!! This page may be unsafe! WARNING!!!" notices on an entirely closed and encrypted network.

      --
      I'm too lazy to compose a creative sig.
    17. Re:Two reasons for SSL by marcansoft · · Score: 3, Insightful

      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.

    18. Re:Two reasons for SSL by Lincolnshire+Poacher · · Score: 3, Insightful

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

    19. Re:Two reasons for SSL by fyngyrz · · Score: 4, Insightful

      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.

      --
      I've fallen off your lawn, and I can't get up.
    20. Re:Two reasons for SSL by forkazoo · · Score: 4, Insightful

      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.

    21. Re:Two reasons for SSL by Anonymous Coward · · Score: 3, Informative

      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.

    22. Re:Two reasons for SSL by PowerKe · · Score: 4, Informative

      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.

    23. Re:Two reasons for SSL by ArsenneLupin · · Score: 3, Informative

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

  2. Duh by afidel · · Score: 5, Interesting

    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.
    1. Re:Duh by NNKK · · Score: 4, Interesting

      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.

      Wish I had mod points. I was about to post the exact same thing.

      Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ may point to the same IP address as https://secure.example.com/, but you're still going to get an SSL-secured response from https://example.com/, just not the one you might expect).

      One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

    2. Re:Duh by Pharmboy · · Score: 3, Insightful

      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.

      --
      Tequila: It's not just for breakfast anymore!
    3. Re:Duh by man_of_mr_e · · Score: 3, Interesting

      Indeed. I bet there is a very large percentage of these "misconfigured" SSL certs that are in the list for this very reason. Just because you can get to an IP by a given domain name doesn't mean that's the domain it's intended to use SSL with.

      Also, think about all the millions of firewalls and routers out there with enabled WAN access and a bogus ssl cert just to make it work. Think of all the development servers, think of all the self-signed certs (which whould show up as invalid to the researchers because they're not configured to accept the self-signed cert).

      I would highly doubt any mroe than 20% of those "misconfigured" servers are actually misconfigured ssl certs for real sites.

      --
      If you need web hosting, you could do worse than here
  3. Almost completely useless as a result. by Gavin+Scott · · Score: 4, Insightful

    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.

    1. Re:Almost completely useless as a result. by kimvette · · Score: 3, Interesting

      Why pay for a root-issued certificate when a self-signed one will do perfectly well when it's a known-safe server accessed only by a few authorised users? Just click through the "add exception" or "install certificate" dialog and be done with it.

      --
      The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
    2. Re:Almost completely useless as a result. by Alwin+Henseler · · Score: 5, Insightful

      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.

  4. Methodology? by dachshund · · Score: 4, Informative

    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.

  5. No Big Deal by harryjohnston · · Score: 4, Interesting

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