SSL Pulse Project Finds Just 10% of SSL Sites Actually Secure 62
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."
SSL can be kinda like a weight lifting belt.. (Score:5, Insightful)
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.
SSL just encrypts the channel. (Score:5, Insightful)
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.
Re:No SNI, thats very truth worthy of a study (Score:3, Insightful)
Re:SSL just encrypts the channel. (Score:5, Insightful)
Which is perfect, it prevents a Network Intrusion Detection System from preventing the attack. ;-)
Re:No SNI, thats very truth worthy of a study (Score:5, Insightful)
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.