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!