Fragen? Antworten! Siehe auch: Alternativlos
Nachschlag zur Debian-Sache: ich hatte ja erzählt, dass whitehouse.gov betroffen war. Nun, stellt sich raus, auch Akamai ist betroffen. Akamai, das sagt vielleicht dem einen oder anderen nichts, das ist ein Content Distribution System. Das wird von allen möglichen Sites benutzt, u.a. von ATI für den Treiber-Download, und, besonders pikant, ELSTER zum Formular-Download für die Steuern:
DownloadWas heißt das jetzt konkret? Deren X.509-Zertifikat ist ja public, wurde von deren Webserver ausgeliefert. Inzwischen haben sie den natürlich ersetzt. Aber wer schnell genug war (und jemand war schnell genug und hat mir das gemailt), der hat jetzt ein Zertifikat mit dazugehörigem Private Key von "a248.e.akamai.net".Der Download erfolgt von einem externen Server des Anbieters Akamai "a248.e.akamai.net" der von der Finanzverwaltung für die Bereitstellung der ElsterFormular-Dateien genutzt wird.
Was heißt das? Nun, dieses Zertifikat ist ja signiert. Von einer CA, der die Browser der Welt vertrauen. Ich kann mich jetzt also mit diesem Zertifikat hinstellen und Browsern gegenüber erfolgreich behaupten, ich sei Akamai. Konkret: wenn jemand neben mir auf einer LAN-Party einen ATI-Treiber runterläd, oder sein Steuer-Formular zieht, kann ich mich in die TCP-Verbindung einklinken, und dann ist der SSL-Schutz ausgehebelt.
Um den Schaden von sowas zu minimieren haben SSL-Zertifikate eine Verfallsdauer von einem Jahr (naja, einstellbar, aber üblicherweise ist es ein Jahr). Dieses Akamai-Zertifikat läuft im Oktober aus. Ich habe das Zertifikat lokal geprüft und es funktioniert. Also, mal unter uns: das ist eine echt große Katastrophe. Nicht nur für Akamai. Es gibt auch nichts, was Akamai tun kann. SSL hat für solche Fälle die Idee einer Revocation List, aber das skaliert nicht und daher haben die Browser das alle abgeschaltet oder gar nicht erst implementiert. PKI funktioniert schlicht nicht in der Breite. SSL ist überhaupt ein Kapitel für sich. Habt ihr mal in eurem Browser die Liste der CAs angeschaut, denen euer Browser vertraut? Kennt ihr auch nur bei einer davon nähere Informationen, die Vertrauen rechtfertigen würden? Seht ihr? Ich auch nicht.
Ich möchte noch eine Sache bestonen: Akamai hat sich hier nichts vorzuwerfen. Die haben alles richtig gemacht. Wir bauen unser Kryptographie-Fundament auf Sand, da kann man noch so tolle Best Practices haben und einhalten. Im Übrigen gelten diese Überlegungen auch für alle anderen Varianten, wie jemand an einen Private Key kommen kann, z.B. Einbruchsdiebstahl. Und es gilt analog für alle anderen Public Key Systeme und PKIs im Moment, z.B. bei e-Government und der Gesundheitskarte. Skalierender Schlüsselrückruf ist ein ungelöstes Problem.
Update: Noch ein Nachschlag zu ELSTER. Stellt sich raus, dass die Elster-Leute auch noch ein Cross Site Scripting Problem haben, und man gar nicht SSL spoofen muss, um denen den Bundestrojaner unterzujubeln. Danke an Thomas für den Hinweis.
Update: Alexander Klink hat offenbar auch eine große deutsche Bank mit dem Problem gefunden, und, besonders hart: deren Zertifikat läuft erst in drei Jahren ab.
In the wake of the Debian weak key issue it was revealed that whitehouse.gov had a weak key. It turns out that the Akamai SSL key is also weak. Akamai, in case you never heard of them, is a major content distribution network. They have tens of thousands of servers distributed over the world. If you have a high traffic web site, you can contract with them, and they will host it and redirect visitors to the site closest to them. Their customer list includes Microsoft, the New York Times, and — particularly interesting for this — ATI's driver downloads.
Akamai obviously replaced their keys immediately. BUT. If you were quick enough, you could get their old public key (it is sent as part of the SSL handshake), and since the private key is weak (there are only 32k possible keys), you can generate the private key to it. Someone did (who wishes to remain anonymous) and sent the key to the CCC. I verified it. The key works. The part that has not sunk in yet for most people is: the public key is signed by a CA that browsers trust. I have a public key and a private key. I can now impersonate Akamai. If I can manipulate your TCP connection (which is easy, for example, if you are using Wifi or are on the same LAN with me), I can send you malware instead of the ATI driver.
SSL has two defenses for this. First: keys expire. This particular key expires October 2008. Second: Certificate Revocation Lists. SSL originally had the idea that CAs would publish a list of compromised keys, and as part of the SSL handshake, the browser would check if the key is on the list. The problem is: that does not scale. At all. There are billions of SSL connections being established per second, Verisign can not possibly pay for the traffic to send their list to everyone. So — noone checks the CRLs. This is the main reason why PKI does not work in practice.
One more thing: I'd like to stress that Akamai did nothing wrong here. They did everything right and still have a problem. The same problem occurs if someone gets the private key by some other means, for example breaking and entering. The foundation upon which we build our infrastructure is less stable than most people realize.