Slashdot Mirror
SSL Pulse Project Finds Just 10% of SSL Sites Actually Secure
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."
..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.
expandfairuse.org
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.
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.
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 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
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
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:/// for whatever archaic reason (or for us development).
http://www.youtube.com/watch?v=5WVOwRY_b-Q#t=58m11s
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?
Butthurt much?
No, he meant "//". http://paulirish.com/2010/the-protocol-relative-url/
Agreed.
Can we get /. to prevent the first, say 5, post replies from AC?
Let the first 5 or so posts be from registered users only. AC cannot reply to the OP until 5 or so replies to OP by registered users have been made.
5 can be tweaked...to an optimized value 3-5 i'd say.
Maybe this will stop the silly 1st post...from AC.....then again..maybe now we will egt
6th Post crap from ACs...but still better than reading a crappy 1st post.
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.
New things are always on the horizon
SSH doesn't use SSL, it has its own transport layer protocol (which is described in RFC 4253).
(To confuse things a bit, OpenSSH does use OpenSSL, but only the cryptography functions. The SSL part of OpenSSL is completely untouched by OpenSSH).
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.