The fallout of the Debian OpenSSL security problem

May 24, 2008

Today I don’t want to write about how the Debian security problem occurred, if it was the fault of the Debian maintainer or the OpenSSL guys. We’re all human so errors can occur, but this shows a much bigger problem we have. Our SSL infrastructure!!

I’m quit sure you read about the weak SSL whitehouse.gov had and that the white house does not handle their SSL stuff by them self, instead the use Akamai for this. If you don’t know Akamai, it is a major content distribution network. They have tens of thousands servers distributed all over the world and the content is served by the closest server to provide higher download speeds for the customs and make a DDOS attack much harder if not impossible. Their customer list includes Microsoft, the New York Times and so on.

So basically the SSL keys of the Akamai servers where weak, and it was possible to get their public keys (it is sent as part of the SSL handshake), and calculate the private ones out of it (there are only 32k possible keys). I know that at least one did it and sent the keys to the CCC, which verify the authenticity of the keys. Sure Akamai replaced their keys immediately. BUT. There is no way to revoke the SSL keys!!

What most people don’t seem to understand so far is that these keys are signed by a CA which is in any browser. This means that a man in the middle attack can easily performed with this. As ATI is also a customer of Akamai, someone could send you a Trojan horse instead of the newest ATI you wanted. SSL has in theory two defenses against this:

Keys expire, the Akamai key in October 2008
Originally SSL had the idea that CAs publish a list of compromised keys (revoke list) and as part of the SSL handshake the browser should check if a key is on the list. The problem with it was that this does not scale and is a privacy problem too. Browsers don’t implement this or have not activated it by default.

So we’re out in the open for this key until this fall, but that won’t be the end, as e.g. godaddy at least allows to the sign keys for a longer period of time. e.g. 3 years. And the same problem occurs if a private key is leak by other means. The whole foundation of our web security infraction is build on sand. We need something new!!

PS: I want to stress that Akamai did nothing wrong here. They did everything right and still have a problem!

In IT Security, Linux | 4 Comments

4 Comments »

RSS feed for comments on this post. TrackBack URI

[…] just thought about the scaling problem of the SSL revoke lists, I wrote in my last blog post. The first two solutions that came into mind where peer-to-peer or DNS based ones. Peer-to-peer […]

Pingback by Robert Penz Blog » DNS based revoke lists — May 24, 2008 #
[…] which hash functions they use. And there is still the revoke list problem, I’ve written previously (and also here). In IT Security […]

Pingback by All SSL Sites are fake-able with new real world MD5 collision attack | Robert Penz Blog — December 30, 2008 #
[…] report which hash functions they use. And there is still the revoke list problem, I’ve written previously (and also […]

Pingback by All SSL Sites are fake-able with new real world MD5 collision attack [Update] | Roy Firestein — January 1, 2009 #
[…] are 100% identical even the links to my previous posts are there. “…. .I’ve written previously (and also here)“. But he is not only copying from me. I copies from many other security […]

Pingback by Roy Firestein steals blog posts | Robert Penz Blog — January 1, 2009 #

The fallout of the Debian OpenSSL security problem

4 Comments »

Leave a comment