Forgot your password?
typodupeerror
Encryption Networking Security The Internet IT

SSL Pulse Project Finds Just 10% of SSL Sites Actually Secure 62

Posted by timothy
from the decimation-of-another-kind dept.
Trailrunner7 writes "A new project that was setup to monitor the quality and strength of the SSL implementations on top sites across the Internet found that 75 percent of them are vulnerable to the BEAST SSL attack and that just 10 percent of the sites surveyed should be considered secure. The SSL Pulse project, set up by the Trustworthy Internet Movement, looks at several components of each site's SSL implementation to determine how secure the site actually is. The project looks at how each site is configured, which versions of the TLS and SSL protocols the site supports, whether the site is vulnerable to the BEAST or insecure renegotiation attacks and other factors. The data that the SSL Pulse project has gathered thus far shows that the vast majority of the 200,000 sites the project is surveying need some serious help in fixing their SSL implementations."
This discussion has been archived. No new comments can be posted.

SSL Pulse Project Finds Just 10% of SSL Sites Actually Secure

Comments Filter:
  • by rastoboy29 (807168) on Friday April 27, 2012 @11:32PM (#39829649) Homepage
    ..giving a false sense of security.

    For example, I've personally discovered hundreds of servers with compromised PHP scripts that worked merrily along via HTTPS, looking very secure.  Unfortunately, attackers can attack a poorly written script over HTTPS exactly as easily as via HTTP, compromise it, and steal information (or whatever) just fine.
    • by khasim (1285) <brandioch.conner@gmail.com> on Friday April 27, 2012 @11:46PM (#39829691)

      SSL just encrypts the channel.
      SSL does not fix anything else.
      How could it?

      Crap code on a website is still crap code on a website whether you have an encrypted channel or clear text channel.

      • by Mysteray (713473) on Friday April 27, 2012 @11:52PM (#39829711) Homepage
        But at least the attacker's data is secure in transit.
        • by Lennie (16154) on Saturday April 28, 2012 @04:58AM (#39830711) Homepage

          Which is perfect, it prevents a Network Intrusion Detection System from preventing the attack. ;-)

          • by Anonymous Coward

            OR you could do what anyone who actually does SSL at any sort of scale does, and run your IDS between your frontend (load balancers, accelerators, F5s, nginx boxes, whatever) and your actual backend servers that serve the PHP (perl/ruby/fastcgi/whatever) request......

          • by Anonymous Coward

            Except if the target is using the IPS behind a TLS concentrator.

            If the target is big enough to have an IPS, there is a relatively good chance that they've also got a TLS concentrator.

            CAPTCHA: "possible"

          • OK. I guess you don't quite understand how SSL works. Think of SSL as a really long pipe between your house and a water processing plant that nobody can penetrate outside your house and the water processing plant. It doesn't stop the processing plant from detecting if the water is bad. It keeps people located outside the water plant from tapping into the pipe and testing the waters quality. In fact they can't even tell if there is water in it.
  • by Anonymous Coward on Friday April 27, 2012 @11:35PM (#39829661)

    If you can inject JS into a secure site, BEAST is the least of your concerns.

    This is them trying to gain awarness of an XSS assisted attack.

    XSS can be more dangerous than the actual traffic.

    They are just checking if servers support backwards complience for older users who would not be able to use SSL othewise.

    This is like saying all sites that have custom rules to make older IE play nice are insecure.

  • by kangsterizer (1698322) on Friday April 27, 2012 @11:50PM (#39829705)

    So I tried my SNI enabled domain, which redirects to a dummy domain if you don't support SNI.

    And https://www.ssllabs.com/ssltest [ssllabs.com] doesn't work with the SNI domain, thinking my certificate is invalid.

    So a few things:

    * It's sponsored by Qualis, I don't see how that's trustworthy. You see that only once you do the actual validation. They're here to make money like any other corporation. Nonprofit stuff? Bitch please.
    * It doesn't work with SNI so there's million domains wrongly counted as invalid
    * Their cert isn't even an EV cert

    • by Qzukk (229616)

      You see that only once you do the actual validation

      You mean the "Qualys SSL Labs" site title and logo and (c) Qualys inc wasn't enough to tip you off?

      Did anyone ever figure out how the fuck beast worked in the first place? Last I heard it's some javascript that apparently magically appears in the browser and does some stuff which lets a sniffer figure out some of the cookies. If they're running arbitrary code on the server or the client (the PoC used a java bug to violate same-origin [theregister.co.uk] and rather than just

    • Re: (Score:3, Insightful)

      by ivan.ristic (631774)
      It would definitely be nice if the test supported SNI (it will soon), but, in our test, SNI is not very important for public SSL. If you are running a public web site you want people to see it, and, across the global audience, too many people cannot use it, which is why public sites don't use it either. The fact that our test does not support SNI has no effect on SSL Pulse, because it uses the results only from the sites with certificates we could validate.
      • by pjt33 (739471)

        If you are running a public web site you want people to see it, and, across the global audience, too many people cannot use it, which is why public sites don't use it either.

        Doesn't the same argument explain why many sites still use old versions of SSL?

        • Yes, to some extent. But it does not explain why about 33% of the servers surveyed support SSL v2.0, which virtually no client wants to use, and which is also insecure. I think it's a combination of 1) using the defaults, 2) not caring, and 3) being afraid that something will break.
          • by julesh (229690) on Saturday April 28, 2012 @11:05AM (#39831815)

            But it does not explain why about 33% of the servers surveyed support SSL v2.0, which virtually no client wants to use, and which is also insecure.

            Because, as a server operator, I don't especially care if clients are spoofed. I don't perform any authentication of their identities anyway, so my security doesn't decrease.

            If the client wants to use an insecure protocol (or is incorrectly configured to use an insecure protocol in preference to a new one), then that is the client's concern. I'm not going to stop them if they don't want to -- they can turn off SSL2 in their browser options (most modern browsers ship this way anyway) if they care that much. A properly configured browser will use SSL3 or TLS in preference to SSL2 anyway if the server supports it, which mine does, so most people will never notice.

            Speaking purely from a commercial standpoint, denying customers access to my services because they are using an out of date or badly configured system makes no sense.

            • by tepples (727027)

              denying customers access to my services because they are using an out of date or badly configured system makes no sense

              Unless you are in a sector where you can be held responsible when your users' authentication is compromised, such as banking.

              • by julesh (229690)

                denying customers access to my services because they are using an out of date or badly configured system makes no sense

                Unless you are in a sector where you can be held responsible when your users' authentication is compromised, such as banking.

                Yes, which probably account for 1% of all SSL enabled servers, so is statistically insignificant.

        • Doesn't the same argument explain why many sites still use old versions of SSL?

          Not especially. The vast, vast majority of browsers still in use support SSL 3 or later. The same cannot be said of SNI because a lot of people are still running Internet Explorer for Windows XP or Android Browser for Android 2. I don't think the operator of a public web site can rely on SNI being widely deployed until about 24 months from now, when Internet Explorer for Windows XP leaves extended support.

          • by Anonymous Coward

            Much longer than that. It's not like millions of pirate copies of XP out there in China, Japan and South Korea [ie6countdown.com] ever get support from MS.
            Businesses with legal copies, holding on for dear life to IE6's activeX is probably not as large a number anyway.

            • Much longer than that. It's not like millions of pirate copies of XP out there in China, Japan and South Korea [running Internet Explorer 6] ever get support from MS.

              It's also not like they'd be both 1. interested in primarily English-language or otherwise Latin-alphabet sites and 2. unable to install a competing browser or the Google Chrome Frame browser helper object on their own machine.

    • by Lennie (16154)

      Any version of IE and Safari (and very old Chrome) on Windows XP and the Android browser on any Android 2.x do not support SNI.

      So that doesn't make SNI very useful on the public Internet right now. :-(

  • by gQuigs (913879) on Saturday April 28, 2012 @12:14AM (#39829799) Homepage

    It's even worse when you consider the sites using mixed content, which passed with flying colors on the analysis. To do a proper test you really need to check every page that uses SSL.

    More about mixed content: https://www.eff.org/https-everywhere/deploying-https [eff.org]

    Fixing Mixed content is not always so difficult, we replaced image links to use "//" instead of "http://", which allows it to use whatever protocol you are already using. This also works if you still might need to fall back to http:/// [http] for whatever archaic reason (or for us development).

  • by Anonymous Coward
    ...is the fact that when I open the site that hosts the article, my browser puts a red, diagonal line over the "https" part of the address field, and claims that it contains "resources which are not secure". Sure, it's probably insignificant, but I have to enjoy the irony, given the topic of the article. :)
    • by Lennie (16154)

      And it isn't just because of the ads, it is also their own content. Some jpg's are loaded from the same hostname over http.

  • by loxosceles (580563) on Saturday April 28, 2012 @01:40AM (#39830097)
    Is this testing for the absence of BEAST workarounds which are present in all current respectable ssl libraries?  Or does it just look for sites using TLS 1.0/SSL3 with block mode ciphers?
    • Re: (Score:3, Informative)

      by ivan.ristic (631774)
      It just looks for sites negotiating vulnerable cipher suites with SSL v3 or TLS v1.0. BEAST workarounds have to be implemented client-side, and IIRC they are in most/all modern browsers. The issue, however, is that there is still a large number of users still using older browser versions, which are still vulnerable.
  • "is that a third of the sites still support SSL 2.0, a protocol that is considered insecure."

    I hope there is no relation between ssl 2.0 and ssh 2.0, what i use to protect my shell sessions...

  • by Anonymous Coward

    The Qualys SSL Labs SSL Server Test application seems to be a well written web application and a not-so-well written analysis tool.

    I tried it with server names that resolved to multiple IP addresses and the behaviour of the SSL Server Test UI changed and showed that someone had put some thought into how the application should work.

    The report itself though leaves something to be desired. The Summary section provides a nice clear way for managers to evaluate their systems and provide targets for improvement.

    • You are right that the score does not always correspond to the findings. This is because the rating methodology was designed back in 2009, whereas the assessment tool continued to evolve. I need to go back and update the methodology knowing what I know now. As for the score, 85% is a great score. Having a better score is of course, possible, but usually comes at performance cost.

The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"

Working...