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.

It's not (skewing the data). In the data set cover by SSL Pulse, only 3 sites failed because of that problem.

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.

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.

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.

It's even worse than that. Many sites do not use SSL (e.g., for authentication), even when they have it properly configured. We actually did a study of how application-layer issues affect SSL. You can find more information here: http://blog.ivanristic.com/2011/08/so-what-really-breaks-ssl.html

Those of you in charge of maintaining SSL servers, you might be interested to know that there's a new online assessment service.

Free, no strings attached (not even ads).

https://www.ssllabs.com/ssldb/

Cheers, Ivan

Well, the problem is that you can't get connection encryption (confidentiality) without authentication. This is because, unless you authenticate with the server you wish to talk to, you can _never_ tell if there's someone in the middle snooping all your traffic (and possibly modifying it as well). It's the infamous man-in-the-middle (MITM) attack, and it's trivial to pull off if the attacker is in the right spot. The world is heading toward two classes of certificates anyway. The price for normal certificates (for which you only need to demonstrate that you control the domain name in question) is going to continue to go down. I hope that one day you'd get your certificate for free with a domain name purchase. Extended Validation (EV) certificates, where certificate authorities actually do some work to validate an organisation behind a certificate, are going to be what you call "full-mode" certificates. Speaking of SSL, just last week I launched a free online service where you can test the configuration of any SSL web site: https://www.ssllabs.com/ssldb/