Version 1.0, 25.09.2014
Eine (nicht nur) bei Anfängern verbreitete – und berechtigte – Sorge ist: Wie kann man sicher sein, dass eine Mail verschlüsselt rausgeht? Dieses Problem bezieht sich sowohl auf mögliche Fehlbedienungen – Verständnisprobleme bei den Anfängern, Flüchtigkeitsfehler bei den anderen – als auch auf Fehler in der Software (vor kurzem gab es einen ziemlich peinlichen Vorfall mit Enigmail).
Das Bedürfnis des Anwenders mag noch einen Schritt weiter gehen. Es mag nicht ausreichen, dass Mails verschlüsselt werden, man mag auch fordern, dass sie nur für die richtigen Schlüssel verschlüsselt werden, wobei richtige
etwa heißen mag, dass sie verifiziert und signiert sein müssen, und immer auch für den eigenen Schlüssel verschlüsselt sind.
Man mag das als organisatorische Sicherheit bezeichnen: Ein Anwender (vor allem ein wenig IT-affiner) soll die Gewissheit haben, dass nichts mehr schiefgehen kann, wenn er eine klare und verständliche Regel (oder wenige) befolgt; eine Regel wie Benutze für solche Mails das andere Mailprogramm
oder Benutze für solche Mails den anderen Account (oder gar: Computer)
.
Die Sicherheit bei der Nutzung von Kryptografie wird nicht durch die Kryptografie begrenzt, sondern durch die Sicherheit des Systems, auf dem die Schlüssel liegen (bzw. benutzt werden), – und durch Fehlbedienungen. Die Kompliziertheit und Fehleranfälligkeit in der Nutzung von OpenPGP werden vielfach kritisiert; etliche neue Entwicklungen verweisen nicht nur auf Vorteile wie die Vermeidung von Metadaten, sondern auch auf eine einfachere Nutzung – auch weil die Kryptografie fest eingebaut und zwingend ist; es gibt keine Umschaltung mehr. Der Bedarf an dieser Sicherheit ist da, und er kann leicht bedient werden. Wenn es eine Option ist, auf eine Mailalternative auszuweichen, dann ist es erst recht eine Option, auf eine speziell eingerichtete, gesicherte OpenPGP-Installation auszuweichen.
Eine recht einfach umsetzbare Möglichkeit, die ein hohes Maß an Sicherheit gewährleistet, wäre die Entwicklung und Nutzung eines lokalen SMTP-Proxys (Smarthosts). Der Anwender würde für seine kritischen Mails idealerweise einen eigenen Account (und einen eigenen, nur in diesem Account verfügbaren Schlüssel) nutzen, auch zum Schutz der empfangenen Daten. Das Betriebssystem könnte dann verhindern, dass Mailprogramme, die unter diesem Account laufen, sich mit den Ports 25 und 587 verbinden.
Statt dessen würden die ausgehenden Mails an den lokalen Proxy zugestellt (im Fall mehrerer Accounts und mehrerer SMTP-Server an mehrere Instanzen des lokalen Proxys auf unterschiedlichen Ports), und der Proxy würde sie nach erfolgreicher Prüfung an den SMTP-Server weiterleiten, für den er konfiguriert ist.
Die Prüfung wäre auf die formalen Aspekte von OpenPGP-Mails beschränkt; es würde nicht versucht ein bösartiges Mailprogramm zu stoppen. Also:
PGP/MIME
Ist die Mail insgesamt verschlüsselt?
PGP/Inline
Ist der komplette Mailbody verschlüsselt, und sind alle Attachments verschlüsselt?
In einem zweiten Schritt mag dann geprüft werden, ob alle Empfängerschlüssel angegeben (kein --hidden-recipient bzw. --throw-keyids) und gültig sind. Gültig kann dabei heißen
gültig nach Meinung der GnuPG-Konfiguration des jeweiligen Accounts
gültig signiert mit einem dafür gegenüber dem Proxy autorisierten Schlüssel (Ausschaltung des WoT)
in einem Keyring oder in einer Fingerprint-Liste enthalten.
Der Proxy und seine Konfiguration können dabei unter einem anderen Account als der Mailclient laufen, so dass der Anwender ihn "auf keinen Fall" kaputt spielen kann.
Die Prüffunktion des Proxys wäre sehr einfach und würde sich kaum mal ändern. Es wäre also wenig wahrscheinlich, dass sich an dieser Front Fehler einschleichen. Crypto-Mailgateways sind dagegen komplexe Programme, die einiges an Logik und Konfiguration beinhalten. Man könnte sogar ein Crypto-Mailgateway als letzte Verteidigungslinie mit so einem Prüfproxy koppeln.
Es gibt schon MTAs mit Filterfunktion, in großer Menge Software zum Extrahieren von Mailbody und Attachments und sicherlich auch Software, die die syntaktische Korrektheit einer E-Mail prüft. Man bräuchte also nicht das Rad neu zu erfinden, sondern müsste lediglich vorhandene Software kombinieren und einen beinahe trivialen Teil selber schreiben.
Strenggenommen ist das Problem durch die Absicherung von SMTP nicht komplett gelöst: Der Mailclient schreibt möglicherweise im Anschluss eine Kopie der Mail in den gesendet-Ordner auf seinem IMAP-Server. Dass er dafür eine andere Mail nimmt als die gerade verschickte ist unwahrscheinlich – aber natürlich möchte man eigentlich nicht nur Wahrscheinlichkeit, sondern Sicherheit. Noch Problematischer ist das Speichern von Entwürfen; dabei ist viel weniger klar, dass sie verschlüsselt sind.
Um auch diese Probleme zu lösen, bräuchte man einen IMAP-Proxy, was aus einer Reihe von Gründen schwieriger erscheint als die Entwicklung eines SMTP-Proxys. Am einfachsten dürfte die Nutzung eines lokalen IMAP-Servers sein, der sich – nach erfolgreicher Prüfung der neuen lokalen Dateien (und kurzzeitiger Blockade neuer Dateien) – mit dem Internet-IMAP-Server synchronisiert.
Dieses Problem kriegt man aber weitgehend in den Griff, indem man für den Mailclient nur lokale Ordner für gesendete Nachrichten, Entwürfe usw. konfiguriert – auch wenn man sich damit für gesendete Nachrichten der Vorteile von IMAP beraubt.
Version 1.0, 25.09.2014 (diese Version, Permanentlink)