Fragen? Antworten! Siehe auch: Alternativlos
Sehr geehrter Herr von Leitner,(Ein faszinierender Gastbeitrag von Prof. Dr. rer. nat. Dipl.-Math. Rüdiger Weis)vielen Dank fuer Ihre freundliche Anfrage. Ich überlege in der Tat, Ihr Angebot annehmen, zum Anlass des 10 jährigen Jubiläums für Ihren in der Bloggerszene ja recht bekannten Onlinedienst einen Kurzbeitrag zu schreiben.
Dies umsomehr, da ich es als wichtig halte, dass bei allem Respekt für Ihre Beiträge im Bereich der praktischen Analyse von Angriffsmöglichkeiten auf sogenannte Internetanwendungen, auch wissenschaftlich etwas anspruchsvollere Fragestellungen in Ihrem (bisweilen etwas multimedialastigen (s.a. /logo-gross.jpg)) Blog, einmal eine angemessene Würdigung finden sollten.
Hören Sie in Ihrem Blog vielleicht ein bisschen weniger auf diese Hackeszene, die Sie für Ihre Arbeiten im Bereich von in C geschriebenen Betriebssystemen nicht zu Unrecht hochschätzt. Sie vergeuden Ihr Talent ein wenig für eine Sprache, die selbst von Ihren Entwicklern inzwischen auch offen als einer der nicht immer gelungenen Hackerscherze (wie TCP/IP, THC, HTTP, SSL, SSH, OTR, gpg, git, GPL, ACID, WWW usw) aufgedeckt wurde. Da hilft es auch nicht viel, lustige Sonderzeichen wie ++ und # anzuhängen. Ich schreibe Ihnen gerade auf einem Emacs-LISP Betriebssystem, welches trotz des oftmals zurecht kritisierten Editierprogrammes bisher recht selten aus diesem Internet attackiert wurde.
Nicht zu Unrecht fragen sich sicherlich zahlreiche Ihrer Leserinnen und Leser, insbesondere angesichts Ihrer in Ihren Blogbeiträgen oftmals durchschimmernden positiven Haltung zu Elliptischen-Kurven-Kryptosystemen, beispielsweise, wieso das Diskreter-Logarithmus-Problem auf der durch Punktaddition gebildeten zyklischen Gruppe eines Generatorpunktes auf einer elliptischen Kurve über einem endlichen Körper, wegen der bisher nicht gelungene Anpassungen der subexponetiellen Index-Calculus Angriffsmethode auf derartige Gruppen, wirklich nur generisch, beispielsweise durch superpolynominale Pollard-Rho-artige Methoden, angreifbar ist, welche ich in meinem Vortrag auf dem 31C3 vielleicht etwas zuspitzend, wenn auch sicherlich nicht ganz ungerechtfertigt, als Geburtstagsparadoxonfolklore bezeichnet habe, und Sie bisweilen selbst für aufmerksame Leserinnen und Leser, insbesondere wegen ihre Länge, schwer lesbare Sätze bilden, in denen Sie bisweilen sogar ein Komma vergessen oder falsch setzen.
(Anm.d.Red.: Es ist dieser Absatz, den ich als "von Krypto hat der ja keine Ahnung" interpretiert habe)
Lassen Sie mich diesen Gedanken aufgreifen und vielleicht etwas polemisch kurz schliessen:
"Was das Geburtstagsparadox für ECC ist, ist Fefe für in C geschriebene Software."
Mit freundlichen Grüßen
Update: Boah ich Depp hab in der Eile das PS nicht mit kopiert, dabei war das doch das Highlight der ganzen Einsendung! Hier ist es:
PS
Ihr SSL Zertifikat wird nicht mal von CNNIC anerkannt.
MCS Holdings hat dann mit dem Zertifikat ein paar gültige Zertifikate für ein paar Google-Domains erstellt. Das ist aufgeflogen, weil Chrome und Firefox inzwischen Certificate Pinning betreiben, d.h. die haben hart einprogrammiert: Wenn für diese Domain (die Liste umfasst eine handvoll "wichtige Domains" wie halt u.a. die von Google) irgendwo ein falsches Zertifikat auftaucht, dann telefonieren die nach Hause und petzen. Und so konnte Google das sehen und hat dann CNNIC zur Rede gestellt. Und die haben gesagt:
they had contracted with MCS Holdings on the basis that MCS would only issue certificates for domains that they had registered.
Klar haben wir diesem Kind eine geladene Schusswaffe verkauft, Euer Ehren! Aber wir haben ihm ganz deutlich gesagt, dass es damit keinen Scheiß machen darf!1!!Diese Art von Versagen ist übrigens kein Alleinstellungsmerkmal der Chinesen.
Auf der einen Seite ist es natürlich schön, dass sowas heutzutage auffliegt. Certificate Pinning ist keine doofe Idee. Microsoft macht das auch, und die eine oder andere ranzige App tut das inzwischen auch. Damit hat so eine App dann einen handfesten Vorteil gegenüber dem Webbrowser, außer es handelt sich um eine Google-Domain oder so.
Aber, der Punkt, über den ihr an der Stelle mal nachdenken solltet: Was ist denn, wenn CNNIC/MCS nicht für eine Google-Domain so ein Zertifikat ausgestellt hätte, sondern für banking.postbank.de oder so? Das würde doch keine Sau merken! Euer Browser würde jedenfalls nicht meckern. Dabei wäre das eigentlich kein Ding, allgemeines Certificate Pinning zu implementieren. Ich hab sowas 2009 schon mal vorgeschlagen. Aber auf mich hört ja immer keiner, und dann sind danach alle ganz furchtbar betroffen, wie es soweit kommen konnte. Wobei, es gibt inzwischen Browser-Addons, die sowas machen (googelt mal Certificate Patrol). Immerhin. Aber eigentlich will man das im Browser selbst implementiert haben, finde ich.
Update: Es gibt da übrigens ein allgemeines Certificate Pinning, aber da muss die Webseite aktiv mitmachen und (in meinen Augen sinnlos) redundante Informationen im HTTP-Header übertragen.
Daher erkläre ich mal. Wenn man eine https-Webseite einrichtet, braucht man ein Zertifikat. Wenn sich der Webbrowser zum https-Server verbindet, 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 28.8.2010 bis 24.2.2011), 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 vertrauenswürdigen Zertifikaten. Ich hatte das auch kurz bei Alternativlos Folge 5 erklärt. 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. Wie bei Alternativlos empfohlen, sollte sich jeder mal die Zeit nehmen, in seinem Browser die Liste der Zertifikate anzugucken. Bei Firefox guckt man in die Preferences, das Advanced Tab, dann das Encryption 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 die Chinesen am Start ("CNNIC"), die Contentmafia ("AOL Time Warner Inc."), America Online (nein, wirklich!), TÜRKTRUST, die Bankenmafia (VISA, Wells Fargo, …), die Schweizer ("Swisscom"), Geert Wilders ("Staat der Nederlanden"), die Schweden und Finnen ("Sonera"), die Japaner, 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, eure Email mitlesen könnte, indem er euch ein ungültiges (also ein von ihnen generiertes, von ihnen unterschriebenes, und daher vom Browser akzeptiertes) Zertifikat vor die Nase hält.
So, wenn ich jetzt einen SSL-Dienst einrichte, und ich 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. Marktführer ist Godaddy, da zahlt man pro Jahr pro Domain sowas wie $30.
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 ein Perl-Skript an, das das Zertifikat generiert. Die haben genau Null Arbeit. Zum Validieren schicken sie eine Mail an eine Mailadresse bei der 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, das ich nicht auch mal schnell selber hätte machen können. Die einzige Sache, die die von mir trennt, ist dass die eine Mail an Mozilla und Microsoft und Opera geschickt haben, um in die Liste der vertrauenswürdigen Aussteller aufgenommen zu werden. Ich habe mal herauszufinden versucht, was für Anforderungen die Browserhersteller an einen stellen, wenn man auf die Liste will. Die Details hängen vom Browser ab, aber ich will das mal so zusammenfassen: keine erwähnenswerten.
Wenn ich nun nicht einsehe, so einer Firma für das Aufrufen eines Perl-Skripts Geld 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, 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-Schlüssel holen und in eure Browser importieren. Wie das genau geht, hängt vom Browser ab. Deren Wiki beschreibt, wie man das macht. Achtung: wenn ihr das tut, kann zusätzlich zu den anderen unvertrauenswürdigen CAs auch CAcert euch gefälschte Webseiten vorspielen.
Aber, 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.
Update: 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. hinschreibe, dass der SHA1-Fingerprint für mein aktuelles Zertifikat
12:2F:49:D9:86:8D:29:40:38:FF:7D:85:48:FD:0A:89:CA:70:67:E8ist, dann 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. Objektiv gesehen müsste man an der Situation mit den SSL-Zertifikaten 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. Trotzdem halte ich es für gut und wichtig, Verschlüsselung auch ohne Not 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.
Update: Die sind auch in den Root-Zertifikaten von OS X, mailt mir gerade jemand.
Update: Und angeblich sind die auch bei Windows im Certificate Store.