Fragen? Antworten! Siehe auch: Alternativlos
Ihr seid eine CA. Keine sonderlich seriöse CA; eine, die Kunden anbietet, auch den Private Key bei euch aufm Server zu generieren. Niemand, der klar bei Verstand ist, würde diese Option wählen. Wer sowas anbietet, nutzt damit also offensichtlich die Unkenntnis seiner Kunden aus.
Aber ihr seid eine CA, und ihr seid Reseller für Symantec. Symantec verkackt so dermaßen vollständig, dass sie bei Google rausfliegen. Ihr wollt also von der CA mit dem schlechtesten Ruf zur nächsten wechseln, zu Comodo. Comodo waren die, die Let's Encrypt über Markenrechtstricks vom Markt zu schummeln versucht haben. Die hier. Die hier. Die wurden mal nach einem Zertifikat für www.sb gefragt und haben ein Zertifikat für sb ausgestellt (ja, die TLD!). Die hier. Die Liste ist noch länger, ich breche mal aus Platzgründen ab. Um Comodo geht es ja hier auch gar nicht.
Ihr hängt jetzt also in einem Vertrag mit Symantec, und Symantec fliegt bei Google raus, verkauft ihr totes CA-"Business" an einen Laden namens DigiCert.
Ihr würdet jetzt gerne die Zertifikate alle zurückrufen, damit ihr den Kunden richtige Zertifikate verkaufen könnt. Ihr schickt also eine Mail an DigiCert. DigiCert antwortet: Nein, das könnt ihr nicht, das können nur eure Kunden.
Und ab hier wird es richtig geil. Die CA, die ihr euch vorstellt, heißt Trustico. DigiCert hat Trustico gesagt, sie würden die Zertifikate nur mass-revoken, wenn es Beweise für einen Security Incident gäbe. Und Trustico sagt daraufhin: Hold my beer! Und schickt (sagt DigiCert) eine Mail mit 23k Private Keys ihrer "generiert ihr mal den Key für mich"-Kunden an DigiCert. DigiCert muss daraufhin die ganzen Zertifikate zurückrufen.
Der Hammer ist, dass Trustico die Private Keys überhaupt hatte. Wie krass ist DAS denn!? Damit hat sich Trustico auch die restlichen Krusten ihres Rufes als CA gänzlich ruiniert. WTF?! Die haben die Keys aufgehoben!?!? OMFG!
Stellt euch mal vor, die hätten eine Command Injection irgendwo? Vielleicht gar noch als root?! Da wären ja alle Zertifikate weg!1!!
Was ist das Problem?
Abhängig von der gewählten Installation versagt der Browser oder der Bildschirm bleibt schwarz.Oh das klingt schlimm. Gucken wir doch mal genauer.
Die Fehlerursache für einen nicht startenden Browser kann eine Sicherheitssoftware von Comodo sein.Öh, ach? Doch nicht Windows Schuld, sondern Comodo-Schlangenöl? Na dann gucken wir doch mal weiter:
Die Comodo-Software kann außerdem dazu führen, dass sich Nutzer nicht mehr korrekt am System anmelden können.Auch am Monitor-Schwarz-Problem trägt also Comodo-Schlangenöl die Schuld.
Aber klar, im Titel bashen wir lieber auf Microsoft rum! Bringt mehr Klicks oder wie?
Update: Ein Kommentar unter der Meldung schreibt, dass das auch ohne Comodo passiert. Insofern ziehe ich meine Kritik an der Stelle zurück. Ein Einsender weist darauf hin, dass die Tastenkombination Strg+Win+Shift+B Abhilfe schafft (Resettet den Grafiktreiber). Das ist ja wie bei Emacs!!1! (Danke, Florian)
Hups.
Auf der einen Seite genau die Art von Scumbag-Aktion, die man im CA-Markt Comodo zutrauen würde. Auf der anderen Seite stellt sich die Frage, wieso die Spezialexperten bei Let's Encrypt kein Trademark darauf angemeldet haben. Einmal mit Profis arbeiten.
Wahrscheinlich hatten sie keine Zeit, weil sie alle Energie für das Ausbuddeln dieser Python-Grütz-Hölle gebraucht haben, mit der sie einen per Default zu beglücken versuchen.
Normalerweise braucht man für sowas echt Fantasie, ein Forschungsprojekt vielleicht. Oder man guckt einfach, was die für ihre exzeptionelle Sicherheit bekannten Spezialexperten von Comodo tun. Tavis Ormandy vom Google-Security-Team hat mal einen Blick gewagt.
I've found some memory corruption issues with the emulatorOK an der Stelle kann man eigentlich schon aufhören. Die Tatsache, dass der Bericht von Tavis weitermacht, nachdem er damit eröffnet hat, das ist echt beunruhigend.So geht es weiter:
but Comodo also implement hundreds of shims for Win32 API calls, so that things like CreateFile, LoadLibrary, and so on appear to work to the emulated code. Astonishingly, some of these shims simply extract the parameters from the emulated address space and pass them directly to the real API, while running as NT AUTHORITY\SYSTEM. The results are then poked back in to the emulator, and the code continues.OOOOH NEEEIIIIINNNN!!!Und das, meine Damen und Herren, ist der Grund, wieso ich mir bei schlechter Laune immer die Schlangenöl-Industrie angucke! *badumm-tsss*
When you install Comodo Internet Security, in the default configuration an application called "GeekBuddy" is also installed and added to HKLM\System\CurrentControlSet\Services. GeekBuddy is a tech support application, that uses a number of questionable and shady tactics to encourage users to pay for online tech support.Mit anderen Worten: Malware!
Das ergibt natürlich interessante Angriffsszenarien für so Freemailer-Domains wie gmx.net oder live.fi, wo man sich im Internet eine Mailadresse klicken kann. Wenn die TLS-Leute eine Admin-Adresse erlauben, die der Freemailer nicht reserviert hat, dann kann man sich so ein Zertifikat klicken.
Eine dieser historischen Admin-Adressen ist hostmaster@.
Ein erlebnisorientierter Jugendlicher hat sich mal hostmaster@live.fi geklickt und dann damit ein TLS-Zert von dem Taco Bell unter den TLS-Anbietern geklickt: Comodo. Comodo hat ihm das ausgestellt. Warum auch nicht, da sitzt ja kein Mensch und prüft. Das ist ein Perl-Skript. Woher soll das Perl-Skript wissen, dass live.fi reserviert ist?
Und hier wird die Story interessant. Der Mann hat das nämlich Microsoft gemeldet, und die haben ihn ignoriert und 4-6 Wochen lang das Problem ausgesessen.
Dann haben sie dem Mann den Microsoft-Account gesperrt, was das Mail-Konto, das Xbox-Konto und das Lumia-Handy mit einschloss.
Ausgesprochen unsportlich, Microsoft!
Update: Oh, ist sogar noch unsportlicher! Es gibt eine Richtlinie, wie CAs die Domains zu validieren haben. An denen hat Microsoft mitgearbeitet. So und jetzt guckt euch mal auf Seite 24 (17 nach Dokumenten-Zählung) Punkt 4 unter 11.1.1 an. Microsoft hat also den Standard mitgeschrieben, an den sich Comodo gehalten hat.
Update: Der Depp hatte die Domain anscheinend mit seinem live-Account verknüpft, also haben die den Live-Account zugemacht. Das klingt ja wiederum eher nach "User nicht schlau"-Fehler. Man kann natürlich immer noch die Frage stellen, wieso das sechs Wochen gedauert hat. Und ob sie da nicht mal hätten gucken können, ob man da weniger invasiv hätte vorgehen können.
Update: Oh das wird ja immer schöner. Die hatten das selbe Problem auch bei der belgischen Domain und da geht das sogar bis 2010 zurück. Und sie haben nichts daraus gelernt.
Update: Im Statement von Comodo heißt es, der Angriff kam aus dem Iran. Ich glaube ja nicht, dass die Amis sich da schlauer angestellt hätten, aber die hätten Comodo halt dazu bringen können, die Klappe zu halten. Usertrust scheint übrigens ein Label von Comodo zu sein, also kein externer Reseller. Jedenfalls legt deren Webseite das nahe.
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.