TLS-Zertifikate: Symantec fällt auf falschen Key herein

Wenn ein privater Schlüssel von einem Webseitenzertifikat offen im Netz landet, sollten Zertifizierungsstellen das entsprechende Zertifikat zurückziehen. Symantec tat dies nun auch bei einem privaten Schlüssel, der überhaupt nicht echt war.

Artikel veröffentlicht am 21. Juli 2017, 9:51 Uhr, Hanno Böck

Symantec fiel auf einen falschen privaten Schlüssel herein. (Bild: Hanno Böck)

Immer wieder passiert es, dass Webmaster versehentlich die privaten Schlüssel ihrer Webseitenzertifikate veröffentlichen, ob auf Github, eingebettet in Applikationen oder, wie wir kürzlich herausfanden, einfach auf dem eigenen Webserver.

Die Sicherheit einer verschlüsselten HTTPS-Verbindung ist natürlich nicht mehr gewährleistet, wenn der dazugehörige Schlüssel öffentlich bekannt ist. Wird ein solcher kompromittierter Schlüssel an eine Zertifizierungsstelle gemeldet, dann muss diese das entsprechende Zertifikat zurückziehen (revoken). Dafür gibt es eine relativ knappe Frist: Laut den Baseline Requirements, einem Regelwerk, auf das sich Browser und Zertifizierungsstellen geeinigt haben, sollte das Zertifikat innerhalb von 24 Stunden zurückgezogen werden.

Wie fälscht man einen privaten Schlüssel?

Dabei stellt sich eine naheliegende Frage: Wie prüfen die Zertifizierungsstellen eigentlich, ob ein privater Schlüssel echt ist und wirklich zu einem Zertifikat gehört? Und würde es auffallen, wenn man mit einem falschen, aber echt aussehenden privaten Schlüssel eine Zertifikats-Revocation beantragt?

Der Autor dieses Texts registrierte sich für ein Experiment zwei Domains und beantragte bei Symantec und Comodo, den beiden größten kommerziellen Zertifizierungsstellen, kostenlose Testzertifikate. Die Domains waren mit anonymen Whois-Informationen registriert, bei der Zertifikatsbestellung wurde kein echter Name angegeben.

TLS-Zertifikate nutzen in aller Regel das RSA-Verfahren. Ein öffentlicher RSA-Schlüssel, der Teil des Zertifiakts ist, besteht aus zwei Zahlenwerten, dem Modulus (üblicherweise mit N bezeichnet) und dem Exponenten (e). Ein privater Schlüssel enthält zunächst ebenfalls die beiden Werte des öffentlichen Schlüssels und einige weitere, geheime Zahlenwerte.

Einen falschen Schlüssel kann man sich erstellen, indem man die beiden Zahlenwerte des öffentlichen Schlüssels nimmt und mit unsinnigen Daten aus einem beliebigen anderen privaten Schlüssel erstellt. Natürlich ist ein solcher Schlüssel fehlerhaft und funktioniert auch nicht korrekt. Doch wenn nur naiv geprüft wird, ob der öffentliche Teil des privaten Schlüssels zum Zertifikat passt, sieht es so aus, als ob beide zusammengehören.

Der Autor legte entsprechend präparierte falsche Schlüssel auf der Plattform Pastebin ab. Dort kann man anonym und ohne viel Aufwand Textdateien hochladen, die dann dort öffentlich einsehbar sind. Um das ganze unauffälliger zu gestalten, suchten wir noch eine Reihe von echten privaten Schlüsseln, die auf Pastebin zu finden waren und zu echten Zertifikaten gehörten. Comodo und Symantec wurden also mehrere tatsächlich kompromittierte Schlüssel zusammen mit dem falschen Schlüssel gemeldet.

Comodo fiel nicht auf den Trick herein - Symantec schon

Comodo durchschaute den Trick und zog nur die tatsächlich kompromittierten Zertifikate zurück. Symantec hingegen zog auch das Zertifikat mit dem gefälschen Schlüssel zurück. Die vermeintliche Besitzerin des Zertifikats informierte Symantec dabei nur mit verwirrenden Mails, aus denen nichts über einen veröffentlichten privaten Schlüssel hervorging.

Vermutlich hätte Symantec auch jedes andere Zertifikat zurückgezogen. Damit hätte man einigen Ärger verursachen können. Seiten, deren Zertifikat zurückgezogen ist, können in Browsern, die das entsprechend prüfen, nicht mehr oder nur nach dem Wegklicken einer Fehlermeldung aufgerufen werden.

Wer im Netz danach sucht, wie man am besten prüft, ob ein privater Schlüssel auch zu einem Zertifikat gehört, findet dazu kaum sinnvolle Informationen. Unzählige Anleitungen empfehlen, lediglich einen Hash des öffentlichen Modulus zu vergleichen - also genau das, was dazu führen würde, dass auch ein wie oben beschrieben gefälschter privater Schlüssel echt aussieht. Auch auf der Webseite von Symantec selbst findet man eine entsprechende Anleitung. Comodo hatte ebenfalls eine solche falsche Anleitung, hat sie jedoch inzwischen angepasst.

OpenSSL-Funktion würde ebenfalls auf den Trick hereinfallen

Auch an anderer Stelle findet man mißverständliche Hilfe. Eine OpenSSL-Funktion namens x509_check_private_key klingt laut ihrer Beschreibung so, als würde sie den privaten Schlüssel tatsächlich prüfen. Allerdings findet sich in der Dokumentation eine Sektion "BUGS", in der beschrieben ist, dass dies nicht wirklich geschieht und diese Funktion ebenfalls nur den öffentlichen Teil des Schlüssels vergleicht.

Diverse Online-Tools - eines davon bei Symantecs Marke RapidSSL - bieten ebenfalls an, zu prüfen, ob ein Zertifikat und ein Schlüssel zusammengehören. Kein einziges der Tools prüft korrekt. Dazu kommt, dass es generell äußerst fragwürdig erscheint, Nutzer darum zu bitten, ihren privaten Schlüssel in ein Webformular zu kopieren.

Es gibt verschiedene Möglichkeiten, tatsächlich die Korrektheit eines privaten Schlüssels zu prüfen. So kann man eine Testnachricht mit dem privaten Schlüssel signieren und anschließend mit den öffentlichen Schlüssel prüfen. Auch kann man die Werte des privaten Schlüssels auf ihre Konsistenz prüfen, OpenSSL hat dazu eine Kommandozeilenoption ("openssl rsa -check -in [key]").

Symantec hat inzwischen mit einem Blogpost auf den Vorfall reagiert. Demnach wurde bislang in solchen Fällen nur der öffentliche Modulus eines Keys verglichen, künftig soll der privaten Schlüssel korrekt geprüft werden. Weiterhin will Symantec seine Prozesse zur Information von Kunden in solchen Fällen überprüfen.

Symantec hatte mehrfach Zertifikate falsch ausgestellt

Für Symantec kommt dieser Vorfall zu einem ungünstigen Zeitpunkt. Die Zertifizierungsstelle steht in der Kritik, weil sie in der Vergangenheit mehrfach unberechtigt Zertifikate ausgestellt hatte.

Google hatte nach wiederholten Vorfällen drastische Maßnahmen angekündigt, die wohl letztendlich dazu führen werden, dass alle momentan gültigen Symantec-Zertifikate irgendwann nicht mehr akzeptiert werden. Wie genau diese Maßnahmen umgesetzt werden und welche Fristen dabei Symantec gewährt werden, wird nach wie vor diskutiert. Zuletzt hatte Reuters gemeldet, dass Symantec plant, sein Zertifikatsgeschäft zu verkaufen.

Eine ausführlichere Beschreibung des Vorfalls findet sich im Blog des Autors.