Warum ich S/MIME für E-Mail-Verschlüsselung am liebsten boykottieren würde

Die Art Zertifikate, die man beim S/MIME-Standard verwendet, und die Praktiken bei deren Vergabe scheinen mir nicht wirklich geeignet, um Vertrauen und Sicherheit für E-Mails herzustellen, und ich würde am liebsten einen grossen Bogen um diesen ganzen Unsinn machen.


Basis der Verschlüsselung und des Signierens von E-Mail nach dem S/MIME-Standard sind Zertifikate. Nur bestimmte sogenannte Zertifizierungsstellen, die als vertrauenswürdig angenommen werden, können Zertifikate so ausstellen, dass wiederum E-Mail-Programme die Zertifikate ohne weiteres Zutun gleich als vertrauenswürdig einstufen.

Rein technisch kann jeder sich relativ einfach seine eigene Zertifizierungsstelle basteln (z.B. mit easy-ca) und sich ein Zertifikat ausstellen, aber wenn man dieses dann verwendet, sieht das beim Empfangen einer Mail etwa so aus:

Selbst ausgestelltes Zertifikat, ungültig

Selbst ausgestelltes Zertifikat, ungültig

Dagegen ist im Prinzip nichts zu sagen: Natürlich ist ein Zertifikat, das ich mir selbst ausstellt habe, nicht alleine dadurch schon vertrauenswürdig, dass ich das technisch gesehen korrekt gemacht habe und z.B. nicht einfach ein Bild mit dem Text „Das ist mein Zertifikat“ drauf (in einem seriös aussehenden Font natürlich) an die Mail gehängt habe: Wie sollen Sie wissen, was Sie von der Zertifizierungsstelle Megos AG CA halten sollen?

Als ich mir für meine Tests mit S/MIME bei Comodo (einer dieser vertrauenswürdigen Zertifizierungsstellen) hier ein kostenloses Zertifikat für den Privatgebrauch ausstellte, war ich zunächst mal ziemlich verblüfft, dass der Prozess vollautomatisch ablief. Über mich als Person wurde da überhaupt nichts geprüft: ob die E-Mail-Adresse wirklich mir gehört, ob ich so heisse, wie ich behaupte, ob es mich überhaupt gibt und nicht einfach ein Roboter ein Zertifikat für sich ausstellt – nada.

Was dieser Prozess de facto zertifiziert bzw. sicherstellt, ist nach meinem Verständnis lediglich, dass es die E-Mail-Adresse gibt, dass später die verschlüsselten und/oder signierten Mails tatsächlich von der E-Mail-Adresse aus verschickt werden, die im Zertifikat steht, und dass unterwegs niemand daran herumpfuschen und heimlich etwas ganz anderes reinschreiben kann.

Im Wikipedia-Artikel zum Thema S/MIME hier und auch auf Angebots-Seiten von Zertifizierungsstellen wie z.B. von GlobalSign hier ist die Rede von 3 Klassen von Zertifikaten, wobei nur bei den (natürlich teureren) Klasse-2- und Klasse-3-Zertifikaten tatsächlich Dinge über Personen und Firmen überprüft werden, z.B. anhand von Scans von Ausweisdokumenten und Handelsregister-Auszügen.

Etwas naiv, wie ich halt manchmal bin, nahm ich an, diese Klassen-Geschichte sei Bestandteil der betreffenden Norm für Zertifikate, und versuchte herauszufinden, wie man sich in Thunderbird anzeigen lassen kann, von welcher Klasse ein bestimmtes Zertifikat ist, und dachte mir, schön wäre doch auch eine Option in jenem Programm, mit der ich sagen kann, dass mir persönlich Klasse-1-Zertifikate zuwenig sind und ich damit signierte Mails nicht als „vertrauenswürdig“ angezeigt haben möchte.

Als ich herausfand, dass das nicht so ist, war ich dann echt verblüfft: Klassen sind bei Zertikaten nur eine gewisse Konvention. Zertifizierungsstellen können ihre Zertifikate irgendwie nennen, z.B. Silver und Gold bei SwissSign (siehe hier), und nachschauen oder filtern kann man schon gar nichts auf einfache Weise in E-Mail-Programmen.

Wenn Sie wirklich wissen wollen, was vor dem Ausstellen eines SwissSign Silver-Zertifikats wie genau geprüft wird, müssen Sie z.B. in Thunderbird – halten Sie sich fest – folgendes tun: Sie klicken auf das vertrauenswürdig aussehende „Brief mit Siegel“-Icon, öffnen dann mit einem Klick auf einen Button die Anzeige der Zertifikats-Eigenschaften, kämpfen sich in den Details durch bis zur Anzeige der Vergabe-Politik, kopieren den da vorhandenen Namen eines PDF-Files in Ihren Browser, laden das PDF, und versuchen in den 64 Seiten die Stellen zu lesen, die festhalten, was genau geprüft wird – auf Englisch natürlich, denn sonst wäre es zu einfach!

Vergabe-Kriterien für SwissSign-Zertifikat

Vergabe-Kriterien für SwissSign-Zertifikat

Ach wie schön wäre es doch gewesen, eine „gescheite“ Norm zu definieren, und dann basierend darauf in Thunderbird zwei Icons, eines mit einem kleinen roten Siegel für minimalistische und nur mässig vertrauenswürdige Klasse-1-Zertifikate und eines mit einem fetten, dicken Siegel für Zertifikate, wo ein Mensch wenigstens kurz nachgeschaut hat, mit wem er es überhaupt zu tun hat.

Verstehen Sie nun, warum ich, anstatt Geld zu zahlen an irgendwelche Zertifizierungsstellen (und zwar jedes Jahr wieder neu), diesen ganzen Unsinn am liebsten boykottieren würde?

Es lebe OpenPGP!

Advertisements

Zwei Tricks für Software Restriction Policies

Werbung für den Einsatz von software restriction policies als zusätzlichen Schutz gegen Trojaner, und zwei vielleicht nützliche Tricks (für technisch etwas versiertere Leute), wie man schlecht programmierte Windows-Applikationen mit solchen Policies aktiv trotzdem zum Laufen kriegen kann


Windows macht es Trojanern nicht gerade schwer: Irgendein bösartiges Programm muss es nur irgendwie auf Ihr System schaffen, dann hat es schon fast gewonnen, denn Windows wird seine Ausführung nicht verbieten. Es gibt bei Windows im üblichen Grundzustand keinerlei Regeln, nach denen irgendeine „Installation“ nötig wäre, bevor ein Programm laufen darf, oder nach denen nur Programme starten dürfen, die Windows irgendwie „kennt“, nein, jedes File mit Code drin darf munter durchstarten.

Mehr oder weniger das schlimmste, was vorher noch passieren kann, ist eine UAC-Nachfrage von Windows, ob man diesem Programm erlauben möchte, das System zu verändern, aber wer nimmt schon solche Dialogboxen ernst und klickt sie nicht einfach nach 0.1 Sekunden reflexartig weg…

Natürlich hat Microsoft schon vor Jahren gemerkt, dass man professionellen Anwendern etwas bieten muss, womit man diese Freizügigkeit einschränken kann, und stellt hierfür den Mechanismus der sogenannten Softwareeinschränkungsrichtlinien bzw. Englisch software restriction policies (abgekürzt SRP) zur Verfügung.

Damit kann man z.B. regeln, in welchen Verzeichnissen im System Code überhaupt ausgeführt werden darf. Weil im momentanen Evolutions-Stand die meisten Trojaner stets im Windows-Temporär-Verzeichnis landen, wenn man z.B. leichtsinnigerweise den im Mail-Anhang enthaltenen Downloader angeklickt hat, und man dieses Verzeichnis darum natürlich gerade nicht in die Liste der erlaubten aufnimmt, kommt hier die Infektion bereits knirschend zum Stillstand, noch bevor überhaupt etwas Schlimmes passiert.

Ich möchte hier SRP nicht im Detail erklären, sondern hinweisen auf die momentan aktuelle c’t (Nr. 10 vom 29.04.2017), wo dies passiert in zwei ausführlichen Artikeln hier und hier. Sie können das Heft oder online die beiden Artikel für rund 5 Euro kaufen.

Das Tool dazu, den Restric’tor, gibt es gratis (Download-Link am Ende dieser Erläuterungen); bei einem Kurztest schien mir das Tool ordentlich gemacht und recht nützlich. Allerdings ist es wie mit den verschlüsselten Mails, über die ich kürzlich geschrieben habe: Wenn man die Sache auf konzeptioneller Ebene nicht versteht, wird man sich bei diesem Tool wahrscheinlich einen verwirrten Kopf holen.

Auch mit einem guten Tool bewaffnet wie diesem sind SRP leider nicht unbedingt pflegeleicht. Das liegt hauptsächlich daran, dass eine ganze Reihe von Windows-Applikationen Dinge tun, die gegen gängige Windows-Konventionen und „best practices“ der Programmierung verstossen, darunter leider auch weit verbreitete. Diese laufen dann mit SRP aktiv nicht ohne weiteres, und man muss ihnen Extrawürste braten.

Ich habe bei meinem Einsatz von SRP konkret mit 2 Programmen Mühe gehabt (dem Mail-Klassifizierer POPFile und der Bitcoin-Wallet Electrum), welche als Teil ihres ganz normalen Programmstarts irgendwelchen Code ausgerechnet in das Windows-Temporär-Verzeichnis schreiben und ihn dort ausführen wollen.

Und dabei bin ich auf folgende zwei Tricks gekommen, die ich hiermit weitergeben möchte an Leute, die auf ähnliche Probleme stossen:

Trick 1: Eine Pfad-Regel muss nicht zwangsweise ein Verzeichnis-Name enthalten. Es klappt auch, wenn man lediglich den reinen Namen einer DLL angibt, wie z.B. im Falle von POPFile UserInfo.dll. Diese kann dann geladen werden, egal wo sie liegt. (Der nächste Trojaner, der sich UserInfo.dll nennt, wird mich vielleicht erwischen, aber mit diesem Risiko kann ich leben.)

Trick 2: Wenn einzelne solche DLL-„Pfad“-Regeln nicht helfen, wie im Falle von Electrum, welches eine ganze Python-Laufzeitumgebung auszubreiten scheint in %TEMP%, bei jedem Programmstart wieder neu (krasses Software Engineering…), kommen Sie mit einem temporär geänderten Windows-Temporär-Verzeichnis trotzdem durch.

Also Programm nicht direkt starten, sondern ein kleines Batch-File schreiben, welches zuerst die Umgebungs-Variable TEMP umsetzt auf ein Verzeichnis, in dem Code-Ausführung mit Hilfe einer Pfad-Regel ausnahmsweise erlaubt ist, und dann mit einer zweiten Zeile im Batch-File das Programm starten.

Wenn es darum geht, herauszufinden, woran es überhaupt scheitert bei solchen Sorgenkindern, hat sich bei mir Process Monitor bewährt.

Alles ist zu kompliziert, wenn man nicht will

E-Mail-Verschlüsselung scheitert nicht an zu komplex, zu umständlich oder Programme nicht gut genug, sondern daran, dass die Leute sich überhaupt nicht dafür interessieren und darum unter anderem den Aufwand scheuen, sich in die Konzepte dahinter einzuarbeiten. Mit derselben Haltung wäre sogar die ganz normale E-Mail nie ein Erfolg geworden.


Es ist eine interessante intellektuelle Übung, etwas mit den Augen eines Unwissenden versuchen anzuschauen, das man selbst schon lange und gut kennt.

Versuchen Sie mal sich vorzustellen, Sie hätten noch nie etwas von E-Mail gehört und müssten jetzt von Grund auf lernen, per E-Mail zu kommunizieren. Oder, wenn Sie so wollen, versetzen Sie sich in Ihr jüngeres Ich zurück, das ja zu irgendeinem Zeitpunkt in der Vergangenheit tatsächlich noch nichts über E-Mails wusste.

Wenn ich das mache, staune ich vor allem darüber, was man da alles lernen muss, bis man „fliessend E-Mail spricht“. Dabei geht es mir nicht mal so sehr um die Bedienung irgendwelcher Mail-Programme oder Webmail-Websites im Detail, sondern um die ganzen Konzepte, um das Verständnis, worum es geht und wie die Dinge zusammenhängen bei E-Mail.

Solange man dieses Verständnis nicht hat, gibt es Unmengen möglicher Fragen, die verwirren und auf deren Antworten man nicht einfach so kommt.

Ich brauche also eine E-Mail-Adresse für mich. Wie komme ich zu einer solchen, wer vergibt mir eine? Kann ich mir selbst eine geben? Muss ich aufpassen, dass ich nicht eine nehme, die schon vergeben ist? Funktioniert meine E-Mail-Adresse weltweit oder nur in meinem Land?

Was passiert, wenn ich mich vertippe bei der Adresse eines Empfängers?

Werde ich wissen, ob und wann meine Mails gelesen werden? Muss ich aufpassen, Mails nicht zu lange liegenzulassen, weil sie sonst verfallen? Kosten Mails etwas? Wieviele darf ich schreiben pro Tag? Warum schreiben mir plötzlich Leute Mails, von denen ich noch nie etwas gehört habe? Kann ich das denen verbieten? Warum kann ich nicht sicher sein, von wem eine E-Mail wirklich kommt?

Das alles hat sehr wenig damit zu tun, ob ein bestimmtes E-Mail-Programm verständlich, benutzerfreundlich und mit den nötigen Funktionen ausgestattet ist oder nicht: Wenn ich erstmalig eine Mail an einen bestimmten Empfänger schreibe und auf dem Eingabefeld für die Empfänger-Adresse stehe, muss ich konzeptionell verstanden haben, dass mir das Programm nicht helfen kann, die Adresse zu ermitteln, sondern dass es mein Job ist, diese irgendwie in Erfahrung zu bringen, sonst geht es schon hier nicht weiter.

Warum erzähle ich Ihnen das alles?

Weil ich mich in den letzten Tagen in die Thematik Mail-Verschlüsselung eingearbeitet und mich dabei ziemlich genau beobachtet habe. Ich habe immer wieder davon gelesen, dass der Umgang mit verschlüsselten Mails schwierig und kompliziert sein soll, und ich wollte wissen, ob das so ist, und wenn ja warum.

Und genau das ist der Punkt: Der Hauptanteil meiner Einarbeitung bestand darin, gewisse Konzepte zu lernen. Was für Schlüssel brauche ich? Wie komme ich zu solchen? Was sind öffentliche und geheime Schlüssel? Wie komme ich zum öffentlichen Schlüssel meines Adressaten? Kann ich irgendwie falsche Schlüssel erwischen, und wenn ja, wie kann ich das möglichst verhindern? Muss ich aufpassen, dass Anhänge mit-verschlüsselt werden? Wozu ist das Signieren von Mails gut? Kann ich unabhängig voneinander verschlüsseln und/oder signieren? Macht eine nur signierte, aber nicht verschlüsselte Mail überhaupt Sinn? Und so weiter, und so fort.

Das Mail-Programm Thunderbird und dessen Erweiterung Enigmail, die ich für meine Versuche verwendet habe, funktionierten fast tadellos. Was hier schwierig und kompliziert sein soll, kann ich nicht nachvollziehen, ausser man macht sich nicht die Mühe, das ganze auf konzeptioneller Ebene zu verstehen und wundert sich dann, dass man nicht durchkommt.

Wie ich anfangs sorgfältig versucht habe zu erklären, ist selbst E-Mail alles andere als „einfach“. Versuchen Sie sich vorzustellen, E-Mail gäbe es noch nicht, jemand würde es erfinden und der Welt vorstellen: Dieser neue Dienst würde wohl umgehend als „viel zu kompliziert für eine breite Anwendung“ taxiert.

Ich bin für mich zum Schluss gekommen, dass auf der technischen Seite mehr oder weniger alles bereit ist für eine breite Einführung von Mail-Verschlüsselung, aber dass die Sache einfach nirgens hinkommt, weil sich die Leute nicht dafür interessieren. Würden sie es tun, würden sie den Aufwand einer Einarbeitung auf sich nehmen und es schaffen. Die paar Ecken und Kanten, die da noch sind in den jeweiligen Programmen, wären auch schnell ausgebügelt.

Wie der Titel dieses Eintrags schon sagt: Alles ist zu kompliziert, wenn man nicht will.