Falsche Google-Zertifikate von Symantec

von Thomas Lange

Mitarbeiter von Google hatten Mitte September beim Auswerten von Logfiles ihres Certificate-Transparency-Systems entdeckt, dass das Sicherheitsunternehmen Symantec für die Google-Hauptdomains unberechtigterweise mehrere Extended-Validation-Zertifikate ausgestellt hat. Obwohl diese Zertifikate nur eine Gültigkeit von einem Tag hatten und nicht für Angriffe missbraucht wurden, zeigt diese Geschichte, dass im Prinzip jede von den Useragents akzeptierte Zertifizierungsstelle gültige Zertifikate für eine beliebige Domain ausstellen kann.

Wenn Geheimdienste zum Beispiel eine Zertifizierungsstelle wie StartCom aus Israel nicht zur Zusammenarbeit zwingen können, dann gehen die einfach zu einer beliebigen US-Zertifizierungsstelle und zwingen diese zum Ausstellen eines Zertifikats für den entsprechenden Hostnamen. Dann brauchen die nur noch die Verbindung des Benutzers so zu manipulieren, dass seine Anfragen an den entsprechenden Hostnamen über deren Server laufen und können so unbemerkt mitlesen. Das Einzige, das sich verändert, ist, dass die Verbindung auf einmal nicht mehr von StartCom aus Israel sondern von VeriSign aus den USA zertifiziert wurde.

Public-Key-Pinning

Auch für dieses Problem gibt es eine Lösung, die sich HTTP-Public-Key-Pinning nennt: Dabei kann ein Webserver im Response-Header einer sicheren Verbindung den Hashwert seines öffentlichen Schlüssels mitschicken. Der Useragent merkt sich dann den Hashwert des öffentlichen Schlüssels für eine bestimmte Zeitspanne und überprüft dann bei jedem Aufbau einer Verbindung zum entsprechenden Hostnamen, ob der Hashwert des öffentlichen Schlüssels vom Server noch mit dem aus der Datenbank übereinstimmt. Wenn das nicht der Fall ist, dann ist das ein Zeichen dafür, dass eine eigentlich vertrauenswürdige Zertifizierungsstelle unberechtigterweise ein Zertifikat für diesen Hostnamen ausgestellt hat, und der Useragent lehnt die Verbindung ab.

Der Hashwert des öffentlichen Schlüssels ändert sich deshalb, weil der Server des Angreifers (ein Geheimdienst oder Krimineller mit viel Glück) natürlich ein eigenes Schlüsselpaar hat. Wenn der Angreifer also die Verbindung zwischen dem Benutzer und dem eigentlichen Server belauschen und als Mittelsmann fungieren will, dann baut der Benutzer natürlich eine Verbindung zum Angreifer auf und dieser hat dann zwar ein gültiges Zertifikat, aber der Useragent des Benutzers bemerkt, dass der Hashwert des öffentlichen Schlüssels nicht mit dem aus seiner Datenbank übereinstimmt und schlägt Alarm.

Der Verfasser

Hi. Mein Name ist Thomas und ich bin nicht gut im Schreiben von Vorstellungen. Ich mag die IT und liebe es mit GNU\Linux zu arbeiten. Auf diesem Blog gibt es Beiträge über die verschiedensten Dinge, die mich beschäftigen oder interessieren (dieses Blogsystem ist eine Eigenentwicklung). Deine Fragen, Ergänzungen und Korrekturen zu Inhalten kannst du mir gerne per Mail mitteilen. 😊