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.
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
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/
It's true that if you restart Apache (via "apachectl restart") the web server will not be operational for a short period of time. Not only that, the users using Apache at the moment of restart will be cut-off (this is especially annoying if you are downloading a longer file).
But this is exactly why you are not supposed to use this way of restarting in production. Apache supports a so-called graceful restart mode ("apachectl graceful") where it re-reads the configuration and, essentially, starts creating new processes with new configuration but leaves the existing processes to complete their requests. Thus there is no downtime.
If you need scripts to run as different users then just use suEXEC (http://httpd.apache.org/docs/2.0/suexec.html), which is designed for that very purpose (and comes standard with Apache). One problem with this approach, however, is that you will experience a performance penalty because suEXEC only works for CGI scripts.
If you need to have the speed of a module together with the security of suEXEC then you need to install the FastCGI module too. FastCGI (http://www.fastcgi.com/ is a communication protocol that allows scripts to remain persistent and process more than one request from a single process. (And, yes, FastCGI is smart enough to only create processes when they are needed and to shut them down when they are not needed any more.) The thread-safety problem would also go away.
I am not aware of any stability problems with mod_security. It works very well for my production systems. Tegatai Systems may have different environment and it may be that there are problems. But if there are, you should inform me about them so that they are resolved.
If you are interested in detecting and preventing web attacks specifically then you should have a look at mod_security. It is an Apache module (both branches are supported) that allows for some very interesting HTTP-specific filtering. It even supports POST method analysis, and can reject an offending request. Since it works as part of the web server it makes it much easier to detect attackes carried out through an SSL channel.
Slashdot Mirror
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/
It's true that if you restart Apache (via "apachectl restart") the web server will not be operational for a short period of time. Not only that, the users using Apache at the moment of restart will be cut-off (this is especially annoying if you are downloading a longer file).
But this is exactly why you are not supposed to use this way of restarting in production. Apache supports a so-called graceful restart mode ("apachectl graceful") where it re-reads the configuration and, essentially, starts creating new processes with new configuration but leaves the existing processes to complete their requests. Thus there is no downtime.
If you need scripts to run as different users then just use suEXEC (http://httpd.apache.org/docs/2.0/suexec.html), which is designed for that very purpose (and comes standard with Apache). One problem with this approach, however, is that you will experience a performance penalty because suEXEC only works for CGI scripts.
If you need to have the speed of a module together with the security of suEXEC then you need to install the FastCGI module too. FastCGI (http://www.fastcgi.com/ is a communication protocol that allows scripts to remain persistent and process more than one request from a single process. (And, yes, FastCGI is smart enough to only create processes when they are needed and to shut them down when they are not needed any more.) The thread-safety problem would also go away.
If you're using mod_security on your Apache server then you only need to add one line to the configuration file:
SecServerSignature "MyServer/19.5.1"
I have recently written an article for SecurityFocus on how mod_security can be used as part of a Apache reverse proxy: Web Security Appliance With Apache and mod_security
I am not aware of any stability problems with mod_security. It works very well for my production systems. Tegatai Systems may have different environment and it may be that there are problems. But if there are, you should inform me about them so that they are resolved.
If you are interested in detecting and preventing web attacks specifically then you should have a look at mod_security. It is an Apache module (both branches are supported) that allows for some very interesting HTTP-specific filtering. It even supports POST method analysis, and can reject an offending request. Since it works as part of the web server it makes it much easier to detect attackes carried out through an SSL channel.
Or, you could add the mod_security module to your Apache server to take care of those common errors for you.