SSLLabs release two SSL related resources
July 24, 2009
SSLLabs have just released two quite interesting resources – their SSL Server Rating Guide and the Public SSL Server Database. As web server and application security are heavily tied to both the use of, and the strength of SSL, it’s nice to see these two things released and giving information on correct configuration.
Now my two issues (you knew they were coming 
)
First, I’m not sure I like the idea of a publically available database of SSL configurations, especially if I can’t control what data is in there about my own sites. It seems that anyone can institute a scan on any other site (which to be fair anyone can do with other tools), but that data is logged for all to see. Querying can be done only on domain name at the moment, but I would guess there’s nothing to stop the site being changed to “show me all the sites that use cipher XXXX”, which could be used maliciously, or doing a “name and shame”. Disclosure: Foundstone’s site is there with an ‘F’ after one of my esteemed colleagues put in “foundstone.com” (not “www.foundstone.com”, which is where the certificate points to). I believe this is a bit of a bug as it doesn’t take into consideration redirects, although I admit that there’s some risk (depending on the site configuration) and this is really splitting hairs.
In any case, although it’s clear to see that this info is being logged, and it’s “public” info, I’m sure that many people won’t like it being so prominently logged, especially without the site owner being notified of their data being added (which is where I see the “premium” site coming in – here sir, for this small fee…). For those that want to assess the SSL configuration of their servers without sending data to someone else, may I point you to Foundstone’s SSLDigger which has been around for ages.
Second, other than the cert mismatch issue, I have a small bug-bear with scoring of SSL ciphers. There’s a known flaw with SSLv2 known as the “downgrade attack” ([PDF] link to good doc explaining various SSL attacks). Basically, because there is no MAC on the SSL handshake in SSLv2 someone performing MITM can remove “strong” ciphers from the handshake leaving only weak one behind that the browser accepts, but can also be broken in a “reasonable time” by the attacker, thus leading to a break in confidentially.
The thing is, all modern browsers have SSLv2 turned off by default, so this flaw isn’t going to affect the average user. Sure, in an assessment we have to warn about it, but it’s a really low risk. I’ve not seen any released tools to perform this attack either (although some netsed foo should handle the job) which further limits the potential exposure to this attack.
In any case, I think it’s great to have the server rating guide out there, as well as another tool that people can use to simply audit their settings. I guess that the privacy nut in me doesn’t like having data out there that I potentially don’t know about.
Posted in Security
July 24th, 2009 at 1:04 pm
Marcin said:I think it’s time someone updates SSLDigger and the paper itself as well. The list of supported ciphers is a bit on the short side.
July 24th, 2009 at 1:49 pm
Ivan Ristic said:Mike,
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?
July 24th, 2009 at 1:52 pm
Ivan Ristic said:Oops, http://www.foundstone.com is actually rated B (73).
July 24th, 2009 at 3:48 pm
Mike said:@marcin – I thought that Rudy had updated SSLDigger, but I’ll check with him on what was changed. Updating the ciphers checked shouldn’t be at all difficult.
@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.
July 25th, 2009 at 1:31 am
Ivan Ristic said:Mike,
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.