Posted
by
timothy
on Friday April 27, 2012 @10:23PM
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."

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 egt6th Post crap from ACs...but still better than reading a crappy 1st post.

Agreed, AC has a valid purpose in many cases and yes to the AC who posted earlier about ACs making more useful contributions than I have, both good and BAD. I could say the same for you too. I'm not here to argue and rant off like some others. Its not a pissing contest like some would want it to be.

The intention was not so much to absolutely censor AC, but more to prevent the silly and nonsensical AC posts like First Post silliness.The ACs are the ones who mostly post the nonsensical/offensive comments. Peo

So if AC can post from post -say- 3, a new trend will flourish on/. "3rd post", i.e. be the first AC to post something. Not sure it'll change much. Moreover, doing so, and even talking about it like we currently do, legitimizes the (poor) AC quest, i.e. get some (weak) recognition from the only posting operation those AC are able to produce (and of course the insulting AC post that will follow this very post).

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.

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

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.

The sort of "stealing" here isn't related to copyright as much as to credentials, which are more like trade secrets and in a way even like trademarks in that they assert that something has been produced by a particular party.

* 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

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

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.

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.

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.

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.

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.

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

What you're referencing has always been used as, at best, an ugly hack to accommodate mistakes and bad decisions when representing complete documents transmitted over HTTP(S). At worst (and this is how I view it), it simply serves to perpetuate the abysmal practice of serving data via both encrypted and plaintext channels over the network. This is a terrible idea for many reasons, and should be soundly discouraged at every possible turn.

The web page doesn't care whether it's being served over HTTP or HTTPS, that's only an issue for the web server. So, the web server configuration can have all the rules and redirections to enforce a particular policy, and the web page will work any time that gets updated, without having to have every link in every page rewritten.

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

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.

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.