Bellow are 17 small suggestions how to improve ssllabs.com/ssltest. Hope some of them are useful... All tests were done against dev.ssllabs.com/ssltest/ server, so are not already implemented at the moment.
Having OCSP stapling is good, so "Yes" might be green, but "No" is not a security problem, so it is fine to have it black.
Lack of any intolerance is good, so "No" might be green. Currently, if a server is compatible with SSL 2 handshake, "Yes" is black, but I would make it red.
I would take a different approach to the color scheme suggestions.
I think we all agree that red text represents a security vulnerability -- something that clearly compromises the security of the information transiting the secure connection. Examples would be:
- Heartbleed (vulnerability)
- OpenSSL CCS vulnerability (CVE-2014-0224)
- POODLE attack / SSL3 enabled
- Insecure client-initiated renegotiation
- TLS compression / CRIME attack
- BEAST attack
- Secure client-initiated renegotiation
But to me, green text should be reserved for things that are security enhancements. These are things that definitely improve the security of the web server, but even without them, the data transiting the connection is still secure. Examples would be:
- Forward secrecy
- Strict Transport Security (HSTS)
- Secure renegotiation
- RC4 disabled
- Downgrade attack prevention
I think you probably should need some set/subset of these enabled to get the A+ grade, but even a web server that implements none of them can still be secure. (RC4 might be debatable).
If you start using green just to represent something that has been done to close a security vulnerability (e.g. SSL3 disabled), then you lose differentiation for these other items in green that don't represent vulnerabilities but instead represent the enhancements.
I don't think BEAST attack is a still security vulnerability, since it has been mitigated on client-side. Other than that, I agree with Dan Wilson.
there are still lots of clients out there without BEAST mitigated... old versions of IE, old versions of android, safari on OS X before 10.9... maybe it'd be a good idea to indicate that in red in the handshake simulation section.
But the problem here is that to mitigate beast, the server needs to either disable TLS 1.0-, or to use rc4 when TLS 1.0- is used. Disabling TLS 1.0 seems not practical for now and using rc4 is not recommended, since it is also weak. This is why I don't think being vulnerable to BEAST should be indicated in red.
the fact that there isn't really a great solution to the problem right now (I'd argue that disabling TLS 1.0 is a pretty good solution, with googlebot's lack of TLS 1.1+ support being the only really significant downside, but I know that for some people not supporting older browsers isn't an option) doesn't make it not a problem. it'd be good for people to be aware that the problem still exists, so their decision about server-side BEAST mitigation will be an informed one.
Interesting comment... what about adding additional subgroup for Advance Security to get A+ grade and move such a features into this subgroup. Now my suggestion applies: green OK and black not optimal. If all options are green and no other security problem then A+ grade. Something like:
Yes, a reorganization of the report format I agree with. I made a very similar suggestion to Ivan a few weeks ago:
Suggestion for Report Layout
Basically, making the report actionable (i.e. a listing of items that a system administrator can use as a checklist for improving the security of his web server(s)) is what we're talking about. The items, their grouping, and their order all go into making the report useful in this context.
#15 - "Server Hostname" frequently shows the physical hostname of the machine tested, i.e., if you test "www.example.com" it may show "vserver32.example.com", which is useful information and not redundant.
In general, it shows reverse DNS.
Here you can see a23-59-194-234.deploy.static.akamaitechnologies.com
It looks like I only tested servers that have the same hostname and a name at the top of the test. So:
15. SOLVED. NOT A BUG.
Please share how to hide server hostname.
Currently, I am using apache 2.4 server.
In Apache httpd 2.4 server at the end of the <apache dir>/conf/httpd.conf file add the following two settings and restart Apache httpd server:
If you need more details I suggest to read official documentation on this two directives: core - Apache HTTP Server Version 2.4
Just a reminder, hiding server signature should be one of the last thinks to do on http server, first you need to fix all security issues if not you fall into the Security through obscurity - Wikipedia, the free encyclopedia problem. Someone interested can still do the ssllabs.com test for your server and see the vulnerabilities.
Thanks for your reply...
I have already used this configuration by this I was hide HTTP server signature.
Now I want to hide server hostname?
Server hostname is based on the reverse ip lookup.
It have nothing todo with security and other than server signature it is an information you do not need to worry about.
Instead it is an good sign if it exists, since some mail server use this for positiv rating in the spam check.
Retrieving data ...