1, You are right in that the Foundstone’s certificate is not valid when the site is accessed without the “www” prefix. My software recognises that (third row in the Details section), but that flaw does not currently affect a site’s score.

2. That’s an interesting topic, but I don’t think it applies to SSL Labs at the moment — the database is not query-able, and I currently have no plans to make it one. Your argument is essentially about full-disclosure, which is a discussion I’d rather not go into. Feel free to call me out again if SSL Labs does become a source of sensitive information at some point in the future.

3. Yes, that’s right. The support for SSLv2 is getting less of a problem every day. The same is also true for several other issues for which sites are currently penalised. For example, a weak cipher suite might never be used in real life. However, SSL Labs is not trying to determine what level of SSL security is right for a web site. I couldn’t do that even if I wanted to. Some things are easy (e.g., you have to have a valid SSL certificate), but when it comes to cipher strength or key size — that’s a matter of risk assessment. A low score may still be perfectly adequate for a site. Still, a server that supports SSLv2 is worse configured than a server that does not, and that’s exactly what I want to show.

A big part of what I am trying to accomplish is get people to just think about the way they use SSL. If they start making conscientious and justifiable decisions — I’ll be happy.

@Ivan – 1. I think what your code was doing was correct – if I go to foundstone.com instead of http://www.foundstone.com I get a mismatched certificate, but it’s impossible to browse foundstone.com as you get a redirect straight away to http://www.foundstone.com – I think a number of sites will perform like this so you’ll have to be careful in this instance.

2. I said in the main post above that it’s “public” data, and can be queried with or without your tool/site. That’s not the thing that concerns me. What bothers me (not that it’s a big issue at all, but just the privacy nut in me screams out on this) is that a) it’s a query-able database which *could* be used to pick out weak servers and b) what if I don’t want my system in that database? Can I “opt-out”? I agree that anyone can do the same tests on whatever server, but let’s say we take it a step further – how about you do a nessus scan at the same time and publish those results to raise awareness of badly configured/patched systems – where do we draw the line here?

3. I wouldn’t want to see anything else – your scoring guide correctly peanlises against SSLv2. My point is that most browsers have SSLv2 turned off, so even though there is that flaw it’s very unlikley, with most users, for either SSLv2 flaws or the downgrade attack (and thus the available ciphers if there’s at least a strong one available) to be an issue. We have to report it, but I don’t think it’s as much of a risk as perhaps it once was.

Don’t get me wrong, I think this is great work and props to you for raising awareness – I just don’t like the existance of *any* public vuln database, even if it is for very simple config issues, and think it’s a very slippery slope we’re on here.

Let me address your three issues and add some of my comments:

1) There seems to be a certificate verification bug in the most recent JDK (actually, there’s more than one bug in this area, but that’s another story). The bug was causing some web sites to be marked as not trusted. I have turned revocation checking off until I find a workaround. Foundstone now gets a B (63).

2) On the topic of this sort of data being available publicly — the data is there, with or without SSL Labs. If people don’t like their sites being seen as poorly configured then they need to fix their configurations. In fact, the whole point of having a publicly available SSL server configuration database is to raise the awareness of widespread SSL server misconfiguration.

3) Regarding the SSLv2 weakness you mention, the rating guide already penalises the use of SSLv2 — would you rather see something else? What?