Was macht Windows, wenn es auf ein Verschlüsselungszertifikat trifft, dessen Echtheit es nicht überprüfen kann? Es schlägt nicht etwa Alarm, sondern fragt bei Microsoft nach, ob man dort zufällig jemanden kennt, der das Zertifikat für echt erklären möchte.
Auf die Verschlüsselung von Windows kann man sich nicht wirklich verlassen. Denn über eine weitgehend unbekannte Funktion kann Microsoft – etwa im Auftrag der NSA – dem System jederzeit und unsichtbar für den Anwender neue Zertifikate unterschieben. Zertifikate kommen beispielsweise zum Einsatz, um bei https-Verbindungen die Übertragung wichtiger Daten zu verschlüsseln und so vor Lauschern zu schützen. Damit Ihr Browser auch sicher sein kann, dass er am anderen Ende einer solchen SSL-Verbindung tatsächlich mit Ihrer Bank spricht, muss das von der Bank beim Aufruf der Webseite präsentierte Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt worden sein. Um das zu checken, hat jeder Browser eine Liste von vertrauenswürdigen Stammzertifikaten; Internet Explorer verwendet die von Windows.
Doch kaum jemand weiß, dass das CryptoAPI von Windows einen Mechanismus enthält, der die Liste der Stammzertifikate dynamisch aktualisiert, wenn das gerade benötigte nicht auf dem System vorgefunden wird. Microsoft hat dieses „Automatic Root Certificates Update“ ohne großes Aufsehen bereits vor Jahren eingeführt und bei allen Windows-Versionen standardmäßig aktiviert [1].
Behauptet das Zertifikat eines Servers wie https://www.correo.com.uy, dass es von einer Zertifizierungsstelle beglaubigt wurde, die der Browser nicht kennt, lädt Windows über den Windows-Update-Server die Datei „authrootstl.cab“ herunter. Sie enthält digital signierte Informationen zu weiteren Stammzertifizierungsstellen; findet sich die gesuchte – also für obigen Server die „Correo Urugayo – Root CA“ – in der Liste, wird deren Zertifikat heruntergeladen und im Zertifikatsspeicher des Systems als vertrauenswürdiger Herausgeber installiert.
Windows informiert den Benutzer über diesen Vorgang nicht. Der Import geschieht unsichtbar im Hintergrund durch einen Systemprozess für das ganze System. Selbst auf einem Windows Server 2008 kann also ein Nutzer ohne besondere Privilegien durch den Aufruf einer URL eine neue Root-CA im System verankern; er kann diese dann auch nicht mehr aus dem System entfernen.
Wer jetzt denkt, das beträfe nur den Internet Explorer und er sei mit Chrome oder Safari auf der sicheren Seite, der irrt. Beide Browser nutzen die Krypto-Infrastruktur des Betriebssystems – unter Windows also ebenfalls das KryptoAPI – und zeigen somit genau das gleiche Verhalten wie der Internet Explorer. Einzig Mozilla pflegt seine eigenen Krypto-Bibliotheken. Diese Network Security Services (NSS) enthalten weder die CA aus Uruguay noch einen vergleichbaren, dynamischen Update-Mechanismus. Folglich zeigt Firefox beim Aufruf der oben aufgeführten URL wie erwartet eine Sicherheitswarnung an.
Das Problem mit den dynamisch nachgeladenen CA-Zertifikaten ist, dass sich damit die TLS/SSL-Verschlüsselung einfach aushebeln lässt. Prinzipiell ist es damit möglich, bestimmten Personen oder Gruppen jederzeit zusätzliche Zertifikate unterzuschieben, die ein Aufbrechen der Verschlüsselung als Man-In-The-Middle erlauben. Mit einem heimlich nachinstallierten CA-Zertifikat könnte etwa die NSA den kompletten SSL-verschlüsselten Netzwerkverkehr einer Zielperson mitlesen. Selbstverständlich kann eine solche CA dann auch S/MIME-verschlüsselte Mails kompromittieren oder Trojaner so signieren, dass sie als legitime Treiber-Software durchgehen.
Es geht hier wohlgemerkt um CAs, die selektiv und quasi unsichtbar auf einzelnen PCs nachinstalliert werden, die bestimmte Zertifikate überprüfen. Das ist etwas ganz anderes als dokumentierte, öffentlich einsehbare Updates der Vertrauensbasis der Krypto-Infrastruktur etwa über den globalen Windows-Update-Mechanismus. Auf unsere Fragen, warum man zusätzlich einen dynamischen Nachlade-Mechanismus implementiert hat, antwortete Microsoft nicht.
Welche CAs auf diesem Weg nachinstallliert werden, weiß man nicht so genau. Es gibt zwar ein Wiki mit einer Liste der für Windows 8 zertifizierten CAs [2] ; ob diese wirklich vollständig ist, kann man jedoch bestenfalls hoffen. Derzeit enthält die in Deutschland ausgelieferte dynamische Liste authsrootstl.cab etwa 350 Zertifizierungsstellen. Doch selbst wenn diese mit der Liste im Microsoft-Wiki übereinstimmen sollte, weiß man nicht, ob sich diese Liste bei Bedarf ändert.
Schon jetzt werden die Zertifikatslisten über das Content Distribution Network von Akamai ausgeliefert, sodass es auch kein Problem wäre, etwa Anwendern in China oder Deutschland eine andere Liste zu präsentieren als US-Bürgern. Angesichts der im Rahmen von PRISM bereits dokumentierten Zusammenarbeit zwischen Microsoft und der NSA muss man annehmen, dass auch solche Hintertüren in Verschlüsselungsfunktionen für das Sammeln von Informationen genutzt werden.
Literatur
[1] Automatic Root Certificates Update Configuration http://technet.microsoft.com/en-us/library/cc733922(v=ws.10).aspx
[2] Windows and Windows Phone 8 SSL Root Certificate Program (Member CAs): http://social.technet.microsoft.com/wiki/contents/articles/14215.windows-and-windows-phone-8-ssl-root-certificate-program-member-cas.aspx
