In association with heise online

SSL surveying

The H: That, rather neatly, brings us on to your SSL research. What's happening there currently?

IR: We're still committed to it. The way I went into SSL was because no one else did. That's sort of what I do, I get this spark of interest in various bits and pieces and I go looking for answers, and if I don't find them, then I can't resist it, I have to figure it out myself. So last year we did a survey, where we used the SSL Labs assessment engine against maybe 60 per cent of the internet to uncover many SSL sites to see how they were configured. That was a real eye opener, because no one had done that before. We're repeating the survey this year as well; however there will be slight changes in the way we are going to do it. This year we are going to focus on the top one million web sites in the world. We think this will make the survey more relevant; if you take a look at all domain names you'll find a lot of them are not really used. For example, in the sample that we had, about a quarter of domain names were inactive; you couldn't find them in DNS or they wouldn't respond. During the survey we only looked at sites which did have SSL certificates that were properly configured, and even there it was hard to tell how many of those sites were abandoned; the certificate is fine but no one is using the site. So, by looking at the top one million sites we are hoping that those are sites that people are using, and that should make the results more relevant.

The other change is that we are updating the rating guide. In the survey we used the SSL rating guide; this is a way to look at a site and its configuration and assign a grade to it to reflect how good the configuration is. Since I wrote the previous guide we had the renegotiation vulnerability and a couple of other changes. The first version was my own work, and since then I have tried to get in touch with other people and the community to get their opinion on it, as well as to shift it towards a consensus. So the 2011 version is going to make some changes which will result in grades being more accurate.

A second change is that we will now be crawling the web sites. In the first survey there were three things we couldn't really cover. There are three ways to break SSL. One is to use an insecure session cookie; if you do, then an attacker can steal the cookies so a man in the middle can hijack the session, SSL or not. Another is that you can have mixed content within individual sites' pages; a man in the middle can hijack the unencrypted bits and pieces and piggy-back on them, say, to inject malicious JavaScript and hijack the browser. The third is mixed content at the site level; where you have a site that is partly in HTTP and partly in HTTPS; depending on how secure the users' browsers are, an attacker could prevent them from reaching the HTTPS area completely and if users forget to check for the padlock, they may be in an emulated secure area where an attacker sees all their traffic and just essentially decrypts it and presents it to them.

Because we will be crawling these web sites we will be able to uncover these three problems on those sites, and this should be very interesting. We should have the results soon and then we are going to have the same survey, maybe quarterly. It'll be interesting to see how things change and we'll be adjusting the frequency of the survey, not to do it too much.

The H: So you'll be emphasising that there's more than just turning on SSL to be secure on the web?

IR: Well, there's a lot. There's a presentation that I give called "Stop complaining and fix a security problem instead", which says that we need to identify the root causes and then figure out the path that will enable us to fix it. Because it's not as simple as identifying something as a cause; it's not enough, because there are often complex interdependencies that prevent people from doing better. I often use SSL as an example. So in SSL there were six things which aren't that much on their own but as a whole they are slowing us down. For example, things such as performance; there isn't much of a performance overhead today, but there is a latency issue. There are all these issues and I've been trying to address them with SSL Labs – this is about raising awareness. You have to do your bit, you have to have actual metrics and show them to people and get them to think about the problems; it'll probably take them a year or two to deal with it, but we have to start somewhere.

In the same context, we realised from our studies that almost no one was using TLS 1.1 or TLS 1.2. So I went to look into why that might be the case and found that Microsoft was the only company that actually supports TLS 1.2, but even they do not have it enabled by default because of interoperability. So if you look at OpenSSL, which is by far the widely deployed library on the server side, they don't support TLS 1.1 or 1.2. I've looked into how we can get them to do it and it comes down to the OpenSSL project not having the funds to implement them. One idea that I have is to organise a fund raiser. I think this could be an important test case for the community; the community must identify critical problems with infrastructure and pay for them to be fixed. If you think about all the open source projects that are out there, they are all individuals spending their own time but at the end of the day we all have to pay our bills. Funding these critical pieces of infrastructure means the community taking responsibility; the buck stops here. Now, you can either commit your own resources, time or whatever you have, or you should give some money to the project.

For example, the OpenSSL project needs $27,500 to implement TLS 1.2 and I want to kick off a fund raiser in the second half of this year so we could pay OpenSSL to implement it. But that's only going to be a start, because then we'll need to get all the distributions to adopt this new version of OpenSSL, so it's going to be two or three years until we get TLS 1.2, but we have to start.

Next: Securing the future of SSL

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit