Falsche Google-Zertifikate von Symantec

Mitarbeiter von Google haben 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 X.509-Zertifikate für beliebige Hostnamen 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 z.B. VeriSign aus den USA zertifiziert wurde.

Ein Lösungsansatz: Public-Key-Pinning

Auch für dieses Problem gibt es einen Lösungsansatz, der 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 X.509-Zertifikat für den entsprechenden Hostnamen, aber der Useragent des Benutzers bemerkt, dass der Hashwert des öffentlichen Schlüssels der aktuellen Verbindung nicht mit dem aus seiner lokalen Datenbank übereinstimmt und schlägt Alarm.

Der Autor

Hi. Ich bin Thomas. Hier veröffentliche ich in unregelmäßgen Abständen mehr oder weniger interessante Beiträge über Dies und Jenes, hauptsächlich über Computer und IT. Außerdem mag ich die Linux-Kommandozeile, vor allem wenn ich darauf mit (m)einer mechanischen Tastatur herumhacken kann. 😀