W
[1]enn ich auf die https-Version meines Blogs [2] verlinke, kriege ich oft Beschwerden von Leuten, die auf solche Links hin von den Terrorpanik-Warndialogen ihres Browsers erschlagen wurden. Daher dazu mal ein paar Anmerkungen (ich stütze mich dabei auf den hervorragenden Beitrag in Fefes Blog [3] – vielen Dank für die klare und pointierte Schilderung!) zum gleichen Thema, übernehme weite Passagen von dort und passe sie auf meine Verhältnisse an.
Erstmal grundsätzliches zum Verständnis von https/SSL: Wenn ich eine https-Webseite einrichten will, brauche ich ein SSL-Zertifikat. Wenn sich der Webbrowser einer Person, die diese Seite betrachten will, zu meinem https-Server verbindet, auf dem die Seite liegt, zeigt ihm der Server dieses Zertifikat. Der Browser guckt dann, ob das aktuelle Systemdatum innerhalb des im Zertifikat stehenden Gültigkeitsdatumsbereichs ist (aktuell ist das bei mir 5.8.2015 bis 4.8.2017), und ob das Zertifikat von jemandem unterschrieben ist, der im Browser als vertrauenswürdig eingetragen ist. Browser kommen mit einer mehr oder weniger langen Liste von vorinstallierten, als „vertrauenswürdig“ deklarierten Zertifikaten, den sog. Root-Certs.
Mit dieser von den Browserherstellern vorinstallierten Liste kommen wir in den problematischen Bereich: Da sind lauter suuuper vertrauenswürdige Zertifikats-Aussteller drin wie z.B. Verisign (und deren Tochterunternehmen Comodo, Thawte, GeoTrust, …), der bekannteste. Verisign ist so nahe an der US-Regierung dran, dass sie u.a. auch die DNS Top Level Domains .com und .net betreiben dürfen. Jeder sollte sich mal die Zeit nehmen, in seinem Browser die Liste der Zertifikate anzugucken: Bei Firefox guckt man in die Preferences, das Advanced Tab, dann das Certificates Unter-Tab, dann den View Certificates Knopf drücken, und in dem neuen Fenster das Tab „Authorities“ öffnen. Da mal durchscrollen. Jeder von denen ist für den Browser vertrauenswürdig. Da ist z.B. auch die Deutsche Telekom dabei. Wenn jetzt z.B. die Bundesregierung gerne eure verschlüsselte Kommunikation abhören wollte, würden sie der Telekom einfach sagen, hey, macht uns mal ein Zertifikat für den Banking-Webserver der Sparkasse oder wo auch immer ihr euch so hinverbindet, auch Email und Jabber benutzen SSL. Und euer Browser würde sehen, dass deren Zertifikat von der Deutschen Telekom unterschrieben ist, und würde es kommentarlos akzeptieren.
Neben der US-Regierung und der Bundesregierung sind da auch noch diverse weitere Internet-Totalüberwachungs-Staaten drin, auch die chinesischen („CNNIC“), sowie die Contentmafia („AOL Time Warner Inc.“), America Online (nein, wirklich!), Türktrust, die Bankenmafia (VISA, Wells Fargo, …), schweizer Schnüffler dürfen nicht fehlen („Swisscom“), auch nicht Geert Wilders („Staat der Nederlanden“), schwedische, finnische („Sonera“), japanische, und selbstverständlich große Konzerne, Intel und Microsoft. Das hängt auch von der Browserversion ab. Aber es ist wichtig, dass ihr versteht, dass jeder von denen, wenn er wollte, alles mitlesen und aufzeichnen könnte, was ihr im Browser macht, indem er euch ein ungültiges (also ein von einer dieser „Autoritäten“ generiertes, von ihnen unterschriebenes, und daher vom Browser akzeptiertes) Zertifikat vor die Nase hält.
Wenn ich jetzt selbst einen SSL-Dienst einrichte und möchte, dass das in eurem Browser ohne Terrorpanikmeldung funktioniert, dann kann ich einem der Kommerzanbieter ein paar Euro in die Hand drücken, und der gibt mir dann ein Zertifikat, das ein Jahr gültig ist. Das ganze kostet dann pro Jahr pro Domain sowas wie $30. Ein kostenloses Einstiegsangebot für ein solches „vertrauenswürdiges“ Zertifikat bietet die israelische Firma StartSSL [4]. Wer das noch nie gemacht hat: das geht so: Man geht dahin, gibt Daten in ein Webformular ein, gibt denen die Kreditkartennummer, und bei denen wirft sich dann i.d.R. ein Perl-Skript an, das das Zertifikat generiert. Die haben genau Null Arbeit. Zum Validieren schickt das Skript eine Mail an eine Mailadresse bei der künftigen SSL-Domain, üblicherweise sowas wie postmaster@ oder root@ oder webmaster@, in der Mail ist ein Link drin, den klickt man dann, und dann glaubt einem der Anbieter, dass man berechtigt ist, für die Domain ein SSL-Zertifikat zu haben. Mehr ist da nicht dabei. Ein Perl-Skript. Nun habe ich aus grundsätzlichen Erwägungen heraus ein Problem damit, Leuten Geld für so eine Schutzgeldnummer zu geben, bei der die Gegenseite nichts tut, was ich mit ein bisschen Autodidaktik nicht auch selber hätte machen können. Die einzige Sache, die die von mir trennt, ist dass die mit entsprechender Lobby ausgestattet und früh genug eine Mail an Mozilla und Microsoft und Opera geschickt haben, um in die Liste der vertrauenswürdigen Aussteller aufgenommen zu werden. Mittlerweile hat die Mozilla Foundation, die über Firefox bestimmt, die Kriterien für die Aufnahme [5] neuer Root-Certs verschärft, wobei alte Certs aber aus praktischen Erwägungen erhalten bleiben.
Wenn ich nun nicht einsehe, so einer Firma für das Aufrufen eines Perl-Skripts mein Geld und meine Daten zu geben, dann bleiben zwei Optionen, um eine SSL-Site zu kriegen. Ich kann mir selber ein Zertifikat machen und selbst unterschreiben. Oder ich kann zu cacert.org gehen, einer nicht-kommerziellen, community-basierten Organisation, die bieten kostenlose Zertifikate an. In beiden Fällen gibt es von den Browsern einen großen roten Terrorpanikdialog. Der bei Firefox involviert inzwischen ein halbes Dutzend Interaktionen, bevor Firefox ein ihm unbekanntes Zertifikat erlaubt.
Aus meiner Sicht ist es egal, wie ich es mache. So rein fundamentalistisch betrachtet sind selbst-signierte Zertifikate die ehrlichste Variante. Je nach dem, wie man es betrachtet, gebe ich dann niemandem zusätzlich die Möglichkeit, sich eurem Browser gegenüber als meine Webseite auszugeben. CAcert ist der Kompromiss. Auf der einen Seite kostet das nichts, und ein User muss nur einmal CAcert trauen mit ihrem Browser [6] und kommt dann auf alle https-Seiten mit deren Unterschrift drauf. Auf der anderen Seite prüfen die auch nicht weniger als kommerzielle CAs. Ich habe keine Ahnung, wieso die nicht bei den Browsern drin sind als vertrauenswürdig [7], ich finde CAcert persönlich vertrauenswürdiger als sagen wie Equifax, die Telekom oder CNNIC. Denn bei CAcert kann man den GPL-Quellcode runterladen. Und die Mailinglistenarchive sind öffentlich einsehbar. Wenn ihr keinen Bock habt, bei meinem Blog jedesmal rote Terrorpanikdialoge wegzuklicken, dann könnt ihr euch hier deren Root-Zertifikate holen, Fingerprints prüfen und in eure Browser importieren. Wie das genau geht, hängt vom Browser ab. CAcerts Wiki beschreibt, wie man das macht [8]. Für den Firefox ist es deutschsprachig und bebildert beschrieben, wie man beide notwendigen Root-Zertifikate (Class 1 und Class 3) installiert [9]. (Leider reicht bei neueren Firefox-Versionen nicht mehr das Add-On, das diesen Root-Zertifikat-Import mit einem Klick [10] übernimmt und unter einer kuriosen Lizenz daherkommt: der WTFPL [11] – Do What the Fuck You Want to Public License.) Achtung: wenn ihr diese Zertifikate importiert, kann zusätzlich zu den anderen unvertrauenswürdigen CAs auch CAcert euch gefälschte Webseiten vorspielen.
Update Dezember 2015: Als weiterer akzeptabler Kompromiss zeichnet sich die Initiative Let’s encrypt [12] ab. Auch wenn Fefe abkotzt [13] über deren Zertifikaterstellungs-Client. Hiermit [14] gehts auch anders. Und hier eine deutschsprachige Anleitung [15] zur Erstellung der notwendigen CSR-Dateien („Certificate Signing Request“). (Update Ende)
Disclaimer, bzw. was ich an der Stelle nochmal ganz deutlich sagen will: Nur weil ihr SSL benutzt, heißt das noch lange nicht, dass die Kommunikation sicher ist und nicht abgehört oder manipuliert werden kann. Im Zweifelsfall sollte man immer zusätzlich zu SSL noch eine Ende-zu-Ende-Verschlüsselung fahren. Bei Email und Jabber kann man z.B. openpgp haben, bei diversen Chatprotokollen gibt es OTR. Wenn ihr eine Wahl habt: immer das zusätzlich einschalten. Und wenn ihr mal jemanden im realen Leben trefft, nutzt die Chance, deren Schlüssel zu vergleichen, damit ihr sicher sein könnt, dass euch da keiner verarscht. Sowas nennt sich dann PGP Keysigning Party.
Vielleicht sollte ich noch klarer sagen: Ich habe die CAcert root key in meinen Trusted Root im Browser eingetragen. Fundamentalistisch gesehen müsst man einmal durch seinen Cert Store laufen und alles als unvertrauenswürdig markieren, und dann alle Zertifikate im Web manuell prüfen. Aber in den meisten Fällen geht das ja gar nicht. Wenn ich jetzt hier z.B. die Fingerprints für mein Zertifikat angebe:
SHA1-Fingerprint
D4:DC:D5:5B:19:91:B7:5C:D5:A7:06:CE:AE:ED:B3:D1:F2:21:F1:8D
SHA-256-Fingerprint
3A:1A:F1:F5:C6:00:9C:8A:E3:6F:7A:AC:D2:C9:F1:5F:0A:1C:F8:9C:07:B2:A8:88:4F:4F:0B:7D:DF:B7:C5:DA
Damit seid ihr auch nicht weiter als vorher. Wenn jemand die SSL-Verbindung zwischen euch und meinem Server manipulieren kann, um euch ein anderes Zertifikat unterzujubeln, dann kann der natürlich auch diese Fingerprintangabe fälschen. Wir müssten uns also zum Fingerprintvergleich persönlich treffen oder sie end-to-end-verschlüsselt vergleichen, wenigstens aber einen alternativen Kommunikationskanal (z.B. Telefonat) zum Vergleich wählen. Objektiv gesehen müsste man an der Situation mit den SSL-Zertifikaten zur „Sicherung“ des alltäglichen Webbrowsens verzweifeln. Daher plädiere ich dafür, lieber die Leute zu informieren, wie viel Sicherheit ihnen das wirklich bietet, damit sie mit einer angemessenen Erwartungshaltung an SSL herangehen. Oh und: SSL hilft auch nicht gegen Trafficanalyse. Wenn jemand wissen will, welche Seiten ihr hier aufruft, dann kann er das anhand der Größe der Antworten rekonstruieren. Die Daten sind ja immerhin öffentlich. Eine höhere Hürde für so eine personalisierte Trafficanalyse bietet das auf Anonymität optimierte Live-Betriebssystem Tails [16], Ansätze für feste Desktop-Installationen liefern Whonix [17] und Qubes [18]. Trotzdem halte ich es für gut und wichtig, Verschlüsselung auch ohne Not und in niedrigschwelligeren Varianten wie SSL einzusetzen, denn je höher der Anteil an verschlüsselten Daten im Netz ist, desto weniger macht man sich verdächtig, wenn man seine Daten verschlüsselt. Dabei erschweren niedrigschwellige Verschlüsselungen die automatische Massenüberwachung und -profilierung erheblich.