SSL-(T)error hier und anderswo

W0011000101001enn ich auf die https-Version meines Blogs 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 – 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. 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 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 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, 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. FĂŒr den Firefox ist es deutschsprachig und bebildert beschrieben, wie man beide notwendigen Root-Zertifikate (Class 1 und Class 3) installiert. (Leider reicht bei neueren Firefox-Versionen nicht mehr das Add-On, das diesen Root-Zertifikat-Import mit einem Klick ĂŒbernimmt und unter einer kuriosen Lizenz daherkommt: der WTFPL – 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 ab. Auch wenn Fefe abkotzt ĂŒber deren Zertifikaterstellungs-Client. Hiermit gehts auch anders. Und hier eine deutschsprachige Anleitung 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, AnsĂ€tze fĂŒr feste Desktop-Installationen liefern Whonix und Qubes. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert