>b's weblog

Zurück zum Blogindex

Links

Über dieses Blog

Kontakt

Volker Birk – vb-ät-dingens.org
Oberer Graben 4, CH-8400 Winterthur

“Warum melden Firefox und Safari, dass Deiner Kommentarseite nicht vertraut wird?”

Das werde ich eben gefragt. Die Antwort könnte für viele wichtig sein, deshalb hier im Blog:

Das Netzwerkprotokoll für (angeblich) “sichere Webseiten” heisst Hypertext Transfer Protocol Secure, oder kurz HTTPS. Es ist das gewöhnliche Hypertext Transfer Protocol (HTTP) in einer verschlüsselten Verbindung. Dieselbe wird über das Protokoll mit dem schönen Namen Transport Layer Security (TLS) hergestellt, das hin und wieder noch unter seinem alten Namen SSL genannt wird. TLS authentisiert über X.509-Zertifikate. Was steckt hinter diesen Fremdwörtern und Abkürzungen?

Bei der Verschlüsselung über asymmetrische Kryptographie, und um eine solche geht es bei X.509 (und damit bei HTTPS), hat man immer Schlüsselpaare, nie einzelne Schlüssel. Dabei kann man das, was man mit dem einen Schlüssel des Paares verschlüsselt, mit demselben Schlüssel gar nicht mehr entschlüsseln. Sondern man braucht zum Entschlüsseln immer das Gegenstück. Wenn man also ein Schlüsselpaar K1, K2 hat, so ist das, was mit K1 verschlüsselt wird, nur mit K2 wieder aufzukriegen. Das nutzt man jetzt z.B. folgendermassen:

Nehmen wir mal an, Alice will verschlüsselte Nachrichten empfangen, die nur sie wieder lesen können soll. Dann erzeugt sie ein Schlüsselpaar K1, K2 mit entsprechender Software, und veröffentlicht für jeden lesbar ihren K1. Man nennt K1 dann ihren öffentlichen Schlüssel. K2 dagegen hält Alice geheim. So kann jeder an Alice verschlüsselte Nachrichten verschicken. Bob z.B. will das machen. Er verfasst eine Nachricht, die nur für Alice bestimmt ist. Dazu verschlüsselt er ihre Nachricht mit ihrem K1. Dann hat Bob die Gewissheit, dass wenn er diese Nachricht abschickt, dass sie nur Alice wieder lesen kann. So funktioniert das bei OpenPGP, aber eben auch bei X.509.

Und jetzt kommen wir zum Problem: die Sache hat einen Haken. Woher weiss Bob denn eigentlich, dass die Kopie von K1, die er veröffentlicht vorfindet, wirklich von Alice stammt? Sie könnte ja von jemandem veröffentlicht worden sein, der sich nur für Alice ausgibt. Da Alice vorher den echten K1 veröffentlicht hat, könnte derjenige diesen Schlüssel abfangen, und seinen eigenen K1* veröffentlichen, der mit dem K1 von Alice nichts zu tun hat, sondern einfach der öffentliche Schlüssel des Angreifers ist. Damit wäre Bob verleitet, statt dem echten K1 nun den falschen K1* zu verwenden, weil er ihn für den öffentlichen Schlüssel von Alice hält und darin getäuscht wird. Der Angreifer kann nun die Nachricht problemlos entschlüsseln und mitlesen – er ist ja im Besitz des passenden K2*, schliesslich ist das in Wirklichkeit sein Schlüsselpaar. Und er kann, noch schlimmer, die Nachricht auch manipulieren und verfälschen. Denn er besitzt ja den echten K1 von Alice, und kann die Nachricht ändern, bevor er sie mit dem echten K1 wieder verschlüsselt, und an Alice weiterleitet. Weder Alice noch Bob würden etwas merken. Man nennt so ein Angriffszenario “Man in the Middle”.

So etwas ist in der Kryptographie verständlicherweise unerwünscht. Es sollte eine Möglichkeit geben, damit Bob prüfen kann, ob der öffentliche Schlüssel, der angeblich von Alice ist, auch wirklich der von Alice ist. Klar gibt's die prinzipiell – Bob geht persönlich bei Alice vorbei, zeigt ihr den öffentlichen Schlüssel, den er aus dem Netz hat, und fragt sie, ob der wirklich von ihr ist. Für genau diesen Zweck veranstalten Leute übrigens Krypto-Parties, bei denen Schlüssel von den Anwesenden verglichen werden. Aber in der Praxis ist das oft umständlich. Deshalb wird und wurde seit langem diskutiert, ob man das nicht ein wenig praktischer kriegen kann. Dazu wurden zwei verschiedene Ideen umgesetzt:

1. Das Web of Trust. Dabei handelt es sich nicht um das WWW, sondern um die Idee, dass Leute, die Alice genau kennen, und von ihr persönlich ihren öffentlichen Schlüssel übergeben bekommen haben, sowie genau geprüft haben, dass das auch wirklich der öffentliche Schlüssel von Alice ist, dass solche Leute den öffentlichen Schlüssel von Alice digital signieren. Wenn Bob nun eine solche Person kennt, die Alice' K1 unterschrieben hat, so kann er darauf vertrauen, dass diese Person das auch genau geprüft hat, und sich eine eigene Prüfung sparen. Ja, weiter kann er den Schlüssel K1 von Alice dann selbst auch unterschreiben, so dass alle, die ihm vertrauen, indirekt jetzt auch sicher sein können, dass K1 wirklich von Alice ist. Das Web of Trust wird z.B. bei OpenPGP eingesetzt. Veröffentlicht werden auf Schlüsselservern also nicht nur Schlüssel, sondern auch Unterschriften.
2. Die Idee eines Zertifikates einer Autorität. Die Idee ist, dass es Organisationen geben muss, denen man vertrauen kann. Wenn es eine solche gibt, und die den Schlüssel K1 von Alice unterschrieben hat, dann wird das schon alles seine Ordnung haben. Eine solche Zertifizierungsstelle heisst bei X.509 eine Certificate Authority. Das sind Unternehmen, die die Dienstleistung verkaufen, geprüft zu haben, von wem ein Schlüssel in Wirklichkeit ist. Und deren Prüfzertifikate sind die, die Webbrowser wie Firefox oder Safari gleich mitliefern. Wer also zu einem solchen Prüfzertifikat passt, dessen Schlüssel wird ja hoffentlich auch echt sein.

Und jetzt kommen wir zum Problem: eine Reihe von CA-Firmen sind bereits geknackt worden. Wer sie geknackt hat, kann beliebig Zertifikate erstellen, die von allen Browsern dann als “sicher” betrachtet werden, und sich für jeden ausgeben. Natürlich haben die Browserhersteller da insofern vorgesorgt, dass sie CAs, bei denen das bekannt ist, sperren – oder wenigstens die Zertifikate, von denen bekannt ist, dass sie “entwischt” sind. Dumm ist dabei allerdings, dass es für ein CA-Unternehmen hochnotpeinlich ist, solche Dinge zuzugeben. Und dass man damit rechnen muss, dass da jede Menge vertuscht wird. Was über die bereits vorgekommenen Fälle von geknackten CAs bekannt geworden ist, lässt einem die Haare zu Berge stehen. Es schaut so aus, als sei es mit der Sicherheitstechnik in solchen Unternehmen nicht immer zum besten bestellt, um das wenigste zu sagen. Da geht's wohl eher um das Geldverdienen mit dem Verkauf von Zertifikaten, und der Rest ist bei manchen Showgeschäft. Wieviel Vertrauen hier verdient ist, sei dahin gestellt.

Ein weiteres Problem ist, dass viele der CAs ihren Sitz in den USA haben. Wie wir spätestens durch die Snowden-Veröffentlichungen wissen, bedeutet das wohl üblicherweise, dass die NSA Druck macht, um an Privates zu kommen. Wenn die NSA aber auch nur einen einziges Basiszertifikat einer einzigen beliebigen CA besitzt, der die Browser standardmässig vertrauen, so meckert kein Browser mehr, wenn die NSA oder von ihr beauftragte Unternehmen auf der Leitung sitzen. Die Verschlüsselung ist dann wertlos. Wer würde heute sagen, dass man davon nicht mindestens ausgehen muss?

Man kann also zusammenfassen: das Zertifikatssystem von X.509, TLS und damit von HTTPS ist vollständig im Eimer. Es hat sich nicht bewährt, sondern darf als Fehlschlag gewertet werden. Weshalb soll ich dann bitteschön ein Zertifikat einer CA kaufen? Nur um Sicherheit zu simulieren, damit der Browser nicht meckert? Da veröffentliche ich lieber ein selbsterstelltes (“self-signed”) Zertifikat, das wenigstens ehrlich ist. Wer will, kann ja mit mir sprechen, und ich erkläre gerne, wie man feststellen kann, dass das wirklich von mir ist.