Black Hat 2009 SSL Review: Black Ops of PKI (Dan Kaminsky)

SSL was again in the centre of attention at Black Hat USA this year (2009). I say SSL, as do many others, but most of the discussion wasn't about SSL but, rather, about the technologies on which it relies. I will cover the Black Hat SSL talks in a series of blog posts, the first of which I publish today.

Dan Kaminsky's talk (get it here as a QuickTime movie) has several very interesting points, but it fails on delivery. When you take the interesting bits out, the rest is a strange mixture of ranting, sarcasm, irrelevant detours and unproductive technology bashing, which I didn't enjoy. Here's my summary of what Dan said:

1. Humans are imperfect.
2. We generally care first about getting things done, with security always an afterthought (if we're lucky).

If you want to be more specific, that translates to:

1. We don't know how to write secure code.
2. We are using tools and languages that are inherently insecure (e.g., the C programming language, with its buffer overflows and NUL-terminated strings).
3. Specifications are often ambiguous.

It's hardly news. My biggest complaint to Dan's talk (his attitude aside) is that he doesn't tell us how to improve things. He mentions DNSSEC as a possible improvement, but how do we guarantee that DNSSEC and its implementations do not suffer from the same problems that plague our software today?

The very interesting new points (what Dan really said), are as follows:

1. MD2 is insecure, yet we are slow in retiring it. There's even one commonly deployed root certificate signed with it. This one MD2 signature could be abused through an preimage attack. Such an attack is not practical today, but it may become practical soon enough for us to be worried. Dan apparently orchestrated a synchronised removal of MD2 from the popular programs and libraries, which is great.
2. CAs, programs and libraries all have issues with input validation, the result of which is that it's possible to get a certificate with a NUL byte in the common name. This is the issue that was independently discovered by Moxie Marlinspike, who also spoke at Black Hat. (I will discuss his talk in a subsequent post.) The differences in the interpretation of such common names allow such certificates to be abused so that you get a certificate that works for the domains you do not own. It's even possible to get a wildcard certificate that works for all domain names (in some browsers). This problem is being fixed. (As an aside, Dan doesn't mention the alternative names field, so we don't know if it's vulnerable too. It would be very ironic if everyone would fix the problems in the common name field, yet leave the alternative names vulnerable. Perhaps that's an opportunity for a talk next year.)
3. It is possible for certificates to have more than one common name (e.g., the domain name, in the context of SSL servers), but its implementation-specific which one will be used.
4. Ambiguities in ASN.1 (which is used to encode certificates) and flaws in ASN.1 implementations can be used to insert OIDs that some consumers interpret as common names, but others don't.

Tags