The H: 'Just five pounds could help this Linux be more secure'?
IR: Yes, but then I was at a security conference last year and there were 150 security professionals in the room. When asked, hypothetically, only one person offered to spend $100 towards this fund raiser. That was a bit disappointing. However, when I asked them about the organisations they worked for, 15 people said their organisations might spend $1,000. So, clearly appealing to organsations might be an easier path to take.
The H: Maybe a Kickstarter project?
IR: Well, I'm talking with OWASP (the Open Web Application Security Project) and I'm hoping to do this with them as they have the charity infrastructure in the US to accept money and handle it. They are open to the idea, so maybe we will be organising it together.
The H: So if we're all on TLS 1.0... how insecure are we?
IR: I think we're pretty secure on TLS 1.0 but we do have to shut down SSL2, which, interestingly enough, is enabled on 60 per cent of the servers that are properly configured, so that's a big problem. I think the difficulty with TLS 1.0 is that the TLS protocol was designed to be extendable and so that you have choice. When you want to establish a secure channel with someone, you have these various bits and pieces, the cryptographic primitives, that you can choose, and you put them into a cipher suite and establish the secure channel. So at any point, if there is a danger that one of these primitives is compromised, because we've discovered it's flawed in some way, you want to be able to replace it; TLS 1.0 doesn't give us that capability, but 1.2 does. Let me give you an example. TLS 1.2 actually supports more recent hashing functions from the SHA-2 library, but if you look at TLS 1.0 and 1.1 they still support functions from SHA-1. So that is one case where people have been saying for some time that we should look to migrating away from SHA-1, because we are starting to see little problems, but because no one supports TLS 1.2 today you can't go that way. TLS 1.0 is not a problem today but it will be in three to five years time.
The H: Do you think that the recent problem with fake SSL certificates will hinder or help efforts??
IR: My view is that the certificate ecosystem – in the shape in which it exists today – worked well for us and made it possible for the web to grow with a reasonably secure foundation, but it is no longer fit for purpose (and hasn't been for some time now). We need to migrate to a better system in the near future. Of course, we've known this for some time now. The core group of people dedicated to SSL has been talking about this and trying to figure out what we can do better. The difference is that, today, many more people are also aware of the problem.
And it's good that this thing has come out the way it did, because otherwise things would never get better. After all, we know that reasonable arguments don't help – people only react to defend against direct threats. Did you know that the first CERT was created in the aftermath of the Morris worm in 1988?
We should assume that there are many rogue certificates in the wild. Comodo might have caught this one, but were there other attacks? There are hundreds of CAs with the power to issue certificates, and I would think that a few of them are compromised at any given time. It's just not possible to ensure 100 per cent security with so many parties involved, when a system is designed in such a way that it fails if the weakest link fails. In addition, many are speculating that there are some CAs that exist only to issue rogue certificates. What happens if a government agency asks a CA to issue them a rogue certificate for some random web site? Do they comply?
I am actually optimistic, because, after many years, last year I started to see the emergence of many separate efforts to fix security. My SSL Survey, the SSL Observatory from EFF, HTTP Strict Transport Security, Firefox 4 now supports Content Security Policies, DNSSEC is being implemented, there's a working group (DANE) to figure out how to put SSL certificates into DNSSEC, etc. It took us ages, but I try not to think about that too much.
The H: Thanks Ivan. We look forward to the feature complete IronBee and the results of the next SSL survey with particular interest