Willkommen im User-Forum von mailbox.org
 

Guard Hinweis

Karsten hat dies geteilt, 3 Jahren her
vorgeschlagen

Bei der Einrichtung eines neuen Accounts erscheit ein recht penetranter Hinweis für die Einrichtung von Guard. Hinsichtlich des recht umstrittenen Nutzens von Guard und der für weniger informierte Nutzer auch missverständlichen Nutzung von PGP in Guard, die das eigentliche Ende zu Ende Prinzip von PGP ad absurdum führt, würde ich eine weniger aggressive "Werbung" für dieses Feature begrüßen.

Die Funktionalität von Guard ist von mailbox.org ausführlich beschrieben und auch die Tatsache, dass die PGP Verschlüsselung von Guard nicht ende zu ende ist wird erläutert. Jedoch habe ich bereits wiederholt erlebt, das Leute aus meinem Umfeld denen ich mailbox.org empfohlen habe, das Guard Feature nutzen und in anschließenden Gesprächen dann ganz geschockt feststellen müssen, das sie das Feature missverstanden haben und ihre geheimen PGP Schlüssel nun genau genommen nicht mehr geheim sind, bzw. das Guard eben im gegensatz zu Mailvelope keine Ende zu Ende Verschlüsselung bietet.


Das für und wieder der Guard Funktion wurde bereits vielfach auch bei Heise diskutiert und soll hier nicht Thema sein. Jedoch ist es sicherlich nicht im Sinne des Erfinders, Nutzern ein falsches Gefühl der Sicherheit zu vermitteln.


Auch wenn das Bewerben bzw. das Hinweisen auf aufwendig erstellte Funktionen seitens mailbox.org verständlich ist, so halte ich es für angebracht, diese Funktion nicht in dieser Art Nutzern "aufzudrängen" bzw. auch innerhalb der Weboberfläche und bei der Einrichtung eindringlicher darauf hinzuweisen, dass die Guard Funktion keine Ende zu Ende Verschlüsselung bietet und die geheimen Schlüssel bei mailbox.org gespeichert werden.

Beste Antwort
Foto

Man mag über die Guard Funktion ja durchaus geteilter Meinung sein, aber einen einfachen Hinweis für den Anwender halte ich auch für angebracht.


Im ersten Moment wusste ich auch nicht recht was dieses Feature bewirkt.

Kommentare (26)

Foto
1

Ich finde es gut, dass Mailbox Werbung für den Guard macht, das zeigt unbedarften Usern, dass es durchaus brauchbare Möglichkeiten für E-Mail Verschlüsselung gibt. Wer High-End-Security braucht, sollte nachlesen können und einen lokalen E-Mail Client nutzen - klar.

Zu Mailevelope wäre zu sagen, dass GMX & Co. das Feature ähnlich aggressiv bewerben, obwohl Security Experten grundsätzliche Bedenken gegen die Implementierung von PGP in Javascript im Browser haben. Kann man im Privacy-Handbuch an anderen Beispielen nachlesen.

Außerdem sind die Schlüssel im Browser Storage auch nicht sicher gespeichert. Der Hacker Rob Fuller hat schon vor Jahren in einem Video bei Youtube gezeigt, wie ein externer Angreifer die Mailevelop-Schlüssel abgreifen kann.

Leider werden diese Sicherheits-Schwächen von GMX & Co. nicht kommuniziert, im Gegensatz zu den Hinweisen bei Mailbox zur Speicherung der Schlüssel auf dem Server.

Ich würde die Version von Mailbox gegenüber Mailevelop klar bevorzugen, aber für hohe Sicherheit muss man sein PGP eben lokal selbst einrichten.

Foto
2

Mailvelope ist kompliziert, kann nicht mit Anhängen umgehen und setzt voraus das alle Empfänger bereits eigene PGP Schlüssel besitzen.


Guard ist einfach, kann mit Anhängen und Formatierungen umgehen und der Empfänger benötigt wegen des Gast Zugangs nicht zwingend einen eigenen PGP Key.


--> Für 99 % der Anwender ist OX Guard genau richtig, der Rest kann ja einfach Mailvelope oder einen Fatclient nutzen. Das schöne ist ja das es kompatibel ist.

Foto
3

Mailvelope geht auch bei uns. Es existiert derzeit nur ein Bug (!) der das verhindert hat(te). Ist bereits gelöst und im Release. In den kommenden Versionen wird auch die Zusammenarbeit von Guard und Mailvelope nochmal deutlich verbessert.

Das ändert nichts daran, daß ich die ganze Mailvelope-Choose für hahnebüchen und unsicher halte. Wir kennen Viren und Angriffe "in the wild", die gezielt den PGP-Private-Key aus dem Speicherverzeichnis von Mailvelope abgreifen. Diese GIBT es und PGP-Keys aus Mailvelope WERDEN ausgelesen. Das ist ja keine abstrakte theoretische Bedrohung. Das ist ja sichtbare Realität.

Jede Behauptung, der Key wäre mit Mailveope auf dem privaten Desktop-Rechner sicher, ist nachweisbarer Unsinn.

Mailvelope hat zahlreiche schwere Probleme:

  • JavaScript kann/darf man nicht für Kryptographie nutzen
  • der eigene Browser ist keine sichere Rechenumgebung
  • ein fremder Browser (Urlaub, Freunde) ist erst recht nicht sicher und hat kein Mailvelope
  • der Key wird durch Mailvelope schutzlos und für Dritte auslesbar auf der Platte gespeichert
  • sogare andere Webseiten/Plugins/etc. können über den Browser den Key auslesen, da er sich nun im Browser-Storage befindet (bei einem PGP-Plugin im Mailclient würde er wenigstens noch woanders liegen)

Ich halte die Diskussion daß Mailvelope die Sicherheit ganz toll macht und unsere serverseitige Speicherung angeblich völlig unverantwortlich ist, für absolut falsch und entglitten -- oder eben auch für gezielte Stimmungsmache derer, die das technisch nunmal nicht besser als mit Mailvelope anbieten können und unseren Weg jetzt diskreditieren und wegdiskutieren müssen.

Wer Mailvelope nutzen WILL, der kann das auch machen, das verhindert wir ja nicht. Wir bieten ein "Mehr", kein "Weniger". Mailvelope ist ja nix anderes als ein Browser-Plugin, das den PGP-Textblock abgreift und decodiert. Das kann man natürlich auch bei uns machen. Quasi überall, das hat ja nix mit dem Anbieter zu tun. Wir optimieren hier natürlich auch die Zusammenarbeit und Unterstützung von Mailvelope. Aber als "ausreichend sicher" werden wir das garantiert nicht empfehlen.


Und daß Mailvelope eben naturgemäß nicht mit Attachments & Co umgehen kann und auch nicht alle PGP-Standards implementiert hat, ist ja nochmal eine andere Sache.

Foto
3

Die Antworten gehen leider alle am Thema vorbei, es geht nicht um Mailvelope, das war nur ein Beispiel für Ende zu Ende im Browser.

Der Punkt ist einfach, dass viele die sich schon mal mit Emailssicherheit ein wenig beschäftigt haben PGP mit Ende zu Ende Verschlüsselung verbinden und somit bei der Einrichtung von Guard davon ausgehen, dass diese Ende zu Ende Sicherheit auch irgendwie umgesetzt wird. Gut, die versierteren Nutzer werden spätestens bei der Nachricht "Schlüssel wurde generiert" stutzen, aber wie gesagt, ich hatte jetzt schon zwei Fälle von Leuten die das missverstanden haben.

Darüber hinaus stimme ich grundsätzlich Herrn Heinlein zu, dass Mailvelope, bzw. JavaScript Crypto eine zweifelhafte Angelegenheit darstellt.

Das Konzept von Guard kann möglicherweise einen Sicherheitsgewinn darstellen, die Assoziation zu PGP halte ich jedoch für gefährlich, insbesondere hinsichtlich der potentiell missverständlichen Begrifflichkeiten.

Vorrausgesetzt die Clientsicherheit ist gegeben, ist PGP eine Sicherheitstechnologie die alles was serverseitig an Sicherheit passiert auf jeden Fall übertrifft.

Die Nutzung von PGP findet bisher vor allem viel Verwendung unter technisch versierteren Nutzern, die ihre Endsysteme in der Regel durchaus absichern können. Die Verbreitung von PGP unter einer breiteren Nutzerschicht bringt natürlich den Aspekt der Endgerätesicherheit ins Rampenlicht und die von ihnen Herr Heinlein in der Vergangenheit angesprochenen Aspekte bezüglich unsicherer Clients halte ich auch nicht für völlig flasch. Doch Guard ist eben nicht PGP. Guard bricht das PGP Ende zu Ende Prinzip, was aber sehr wesentlich ist. Die Verwendung von Guard bietet keine Sicherheit wie PGP, suggeriert durch die Verwendung von PGP Keys aber eine assoziation mit PGP Sicherheit, auch wenn dem aufmerksamen Leser dieser Akspekt durchaus klar sein sollte.

Daher halte ich es für zwingend erforderlich bei der Einrichtung von Guard darauf hinzuweisen was diese Funktion bietet und was nicht. Viele mögen eventuell einfach nur eine zusätzliche Sicherheitsfunktion sehen und das ist ja auch schön und gut. Aber diese Leute wundern sich dann später, wenn sie bei der Erklärung wie sie PGP jetzt nutzen, von technisch versierteren Leuten die PGP als Ende zu Ende verstehen, nur ein angewiedertes urg bekommen. Denn im Prinzip ist Guard eben ein "misshandeltes" PGP, das von sehr vielen technischeren Nutzern als "Broken by Design" abgelehnt wird, nicht weil es nichts bringen würde sondern weil es kein PGP im eigentlichen Sinne ist.

Das Guard Feature ist nicht per se schlecht, es hat aber eigentlich nichts mit PGP zu tun. Für manche mag das vielleicht ein Sicherheitsgewinn sein doch ganz unabhängig von dem individuellem Sicherheitsbedarf gibt es einige nachteilige Aspekte die Guard im gegensatz zu "richtigem" PGP eben nicht bietet:

- Die Kompromittierung der Server bricht ALLE Guard Sicherheit von ALLEN Nutzern, was also ein sehr lohnendes Zeil darstellt. Und ja das Passwort zur Entschlüsselung bringt da gar nichts, das lässt sich einfach aufzeichnen. Die Sicherheitsmaßnahmen von mailbox.org mögen verhindern das jeder dahergelaufene Informatik Student sämtliche Schlüssel und Passwörter mitnimmt, doch gegen derartige Angreifer reicht auch SSL.

- Eine gerichtliche Anweisung von Behörden würde ebenfalls die Serverseitige Guard Sicherheit unterlaufen.

- Eine gesicherte Mailinfrastruktur und gute SSL Transportverschlüsselung geben einen grundlegenden Schutz von Seiten des Providers. Ist diese überwunden bedeuten zusätzliche Maßnahmen wie Guard seitens des Providers nur noch einen kleinen zusätzlichen Schritt. Wenn ein versierter Angreifer ersteinmal so weit ist, interessiert die Guard funktion auch nicht mehr wirklich. Das verzögert höchstens ein wenig weil noch die Passwörter abgefangen werden müssen.

Daher halte ich Guard für ziemlich nutzlos und sogar gefährlich hinsichtlich missverständnlicher Assoziation mit Ende zu Ende (PGP) seitens der Nutzer.

Unter versierten PGP Nutzern wird ein von Guard generierter oder verwendeter Schlüssel als kompromittiert betrachtet, das habe ich mir inszwischen von einer zweistelligen Zahl langjähriger PGP Nutzer bestätigen lassen. Damit ist die "kompatibilität" mit "richtigem" PGP ebenfalls nicht mehr wirklich gegeben.

Unterm Strich:

Wenn ihr dieses Feature anbieten wollt ist das eure Sache. Mir ist nicht als einziger diese Funktion sauer aufgestoßen, gerade wegen der Assoziierung mit PGP. Aber bitte weißt deutlicher bei der Erstellung/Verwendung darauf hin was Guard ist und was nicht. Das wäre meiner Meinung nach das Mindeste um nicht dem möglichen Vorwurf ausgesetzt zu werden ein falsches Gefühl von Sicherheit zu vermitteln.

Die Intention von mailbox.org hinsichtlich Guard mag gut sein, doch wie auch das Medienecho gezeigt hat ist dieses Feature unter technischen Nutzern sehr umstritten und ob es überhaupt einen Sicherheitsgewinn gibt halte ich für fragwürdig.

Foto
3

Es gibt unterschiedliche Ansichten, wann PGP "sicher" ist. Ich persönlich halte PGP nur für sicher, wenn man seinen private Key nicht auf dem eigenen, mehr oder weniger unsicheren Computer speichert.

Meiner Meinung nach ist PGP nur "sicher" für hohe Ansprüche, wenn man eine OpenPGP-Smartcard verwenden. Ich halte also auch Ihre Ansicht von PGP mir dem privaten Schlüssell auf dem Computer oder Smartphone Schlüssel nur für "hinreichende" Sicherheit, die ein Kompromiss zwischen Benutzbarkeit und Sicherheit ist. (Es ist eben Ihr Kompromiss, nicht meine Ansicht von sicherem PGP.)

Ich möchte Ihnen damit nur sagen, dass auch Ihre Meinung nicht der Weisheit letzter Schluss ist und nur Ihr persönlicher Kompromiss zwischen Sicherheit und Benutzbarkeit. Andere Nutzer (und das ist meiner Meinung nach die Mehrheit) bevorzugen andere Kompromisse.

Falls Sie meinen, dass eine OpenPGP-Smartcard nur für Aluhut-Träger sinnvoll ist, dann kann ich Ihnen als Beispiel die Kompromittierung der Schlüssel von Cryptome nennen. (Sie kennen die Leak Plattform vielleicht?) Das hättte mit einer Smartcard vermieden werden können.

Sie sollten Ihre Meinung (was auch nur eine Meinung ist!) nicht als der Weisheit letzter Schluss sehen. Es ist nach oben und nach unten offen variierbar.

Bei mailbox.org möchten wir Lösungen für eine breite Nutzerbasis anbieten. Sie können Ihre Variante von PGP nutzen, ich nutze meine Smartcards und andrer Nutzer können den Guard verwenden.

Wer hohe Sicherheit benötigt, sollte sich entsprechend gründlich informieren.

Foto
2

Dem Post kann ich eigentlich voll zustimmen, wobei vielleicht in dieser Diskussion im allgemeinen darauf hingewiesen werden sollte das der Begriff "Sicherheit" nicht statisch ist.

Es geht immer um Kompromisse und absolute Sicherheit kann nicht existieren.

Die Frage bleibt jedoch welchen Sicherheitsgewinn Guard wirklich bietet.

Foto
1

Welchen Sicherheitsgewinn Gurad bietet?

Hmmm - Tante Emma könnte Ihrem Enkel mit richtigen IT-Kenntnissen eine verschlüsselte E-Mail schreiben, und der Provider des Enkels hat keine Möglichkeit, die Mail zu lesen.

Der Enkel könnte Tante Emma verschlüsselt antworten und die Lauscher vom BND, die eine möglicherweise nicht TLS-verschlüsselte SMTP-Verbindung zwischen den Mailservern abhören, könnten es nicht lesen.

Die E-Mails von Tante Emma werden PGP-verschlüsselt in der Inbox bzw. dem Sent-Folder gespeichert und können bei einer einfachen Bestandsdatenabfrage nicht dem Geheimdienst oder anderen Behörden übergeben werden.

Der Guard kann also durchaus der Massenüberwachung Steine in den Weg legen, wenn User nicht in der Lage sind, ihr PGP lokal selbst zu verwalten.

Welchen Sicherheitsgewinn bietet eine sichere PGP-Lösung, die keiner einsetzt?

Foto
2

"Tante Emma könnte Ihrem Enkel mit richtigen IT-Kenntnissen eine

verschlüsselte E-Mail schreiben, und der Provider des Enkels hat keine

Möglichkeit, die Mail zu lesen."

Stimmt, auch wenn der Provider von Tante Emma diese prinzipiell lesen könnte. Aber gut, ein Gewinn im Vergleich zu reinem SSL ist es.

"Der Enkel könnte Tante Emma verschlüsselt antworten und die Lauscher vom

BND, die eine möglicherweise nicht TLS-verschlüsselte SMTP-Verbindung

zwischen den Mailservern abhören, könnten es nicht lesen."

Stimmt. Aber...

"Die E-Mails von Tante Emma werden PGP-verschlüsselt in der Inbox bzw.

dem Sent-Folder gespeichert und können bei einer einfachen

Bestandsdatenabfrage nicht dem Geheimdienst oder anderen Behörden

übergeben werden. "

...wenn die den Inhalt wollen können die auch fordern die Schlüssel rauszurücken und die Passwörter abzufangen.

Oder die Fragen ihre Freunde bei der NSA ob die mal bei euch vorbeikommen und einfach die ganze Infrastruktur heimlich übernehmen. Also naja.

"Der Guard kann also durchaus der Massenüberwachung Steine in den Weg

legen, wenn User nicht in der Lage sind, ihr PGP lokal selbst zu

verwalten."

Ok können wir so stehen lassen.

"Welchen Sicherheitsgewinn bietet eine sichere PGP-Lösung, die keiner einsetzt?"

Wie schon weiter oben erläutert, ist es einfach falsch das es nicht eingesetzt wird. Es wird von Millionen verwendet wenn auch vor allem durch technisch versierte Nutzer. Trotzdem, wer es will kann es nutzen. Was es bringt? Eine echte Ende zu Ende Verschlüsselung. Und dafür ist Guard eben keine Alternative.

Aber gut haben wir das geklärt. Ein gewisser Sicherheitsgewinn von Guard lässt sich nachweisen. Bleibt nur noch eventuelle Missverständnisse bezüglich "Ende zu Ende Sicherheit" vorzubeugen, wobei wir wieder bei dem eigentlichem Thema sind.

Bitte einen Hinweis bei der Einrichtung von Guard einblenden, welcher das brechen des Ende zu Ende Prinzips von PGP thematisiert um Missverständnissen vorzubeugen.

Foto
Foto
1

Einige Punkte sehe ich ähnlich, andere sehe ich nicht so. Kommen wir doch mal zurück aus der Theorie in die Praxis:

Fast alle Nutzer und selbst IT Anwender tauschen in 2016 kritische Informationen in unverschlüsselten Emails aus. Warum denn, es gibt doch seit Jahrzehnten PGP und Ende zu Ende Verschlüsselung?

Eine Ende-Ende Verschlüsselung mit PGP verwendet auch nach Jahrzehnten niemand, weil es zu kompliziert ist. Theoretisch sicher, die User Experience ist eine Katastrophe. Das ist der status quo. Es funktioniert nicht und mit niemandem. Doof, müssen wir ITler ändern, oder? Was machen wir denn da?

Jetzt hat einer eine Idee und entwickelt ein System das in der Praxis fast genauso sicher ist, aber benutzbar. Und auch noch OpenSource! Und zeitgleich arbeitet der mit allen großen Providern zusammen und hat eine echte Chance was zu bewegen im bereich Email Sicherheit. Wollen wir das jetzt nutzen und fördern und verbreiten oder wollen wir das schlechtreden weil es nur 90 % sicher ist und theoretische Lücken bleiben?

Fakt ist doch:

Für 99,9 % der Anwender stellt die Nutzung von Guard einen massiven Zugewinn an Sicherheit dar. Und diejenigen die Ende-Ende verschlüsseln wollen können das auch tun, indem sie Guard mit eigenen lokalen Schlüsseln verwenden. Das ist der erste Ansatz der funktionieren könnte und Nutzer von plantext Emails webführt, das ist doch das entscheidende, den Nutzer überhaupt erstmal abzuholen anstatt ihn weiter im Regen stehen zu lassen!

Ein Stückchen sicherer machen um die letzten paar Prozent rauszuholen kann man es dann immer noch, Beispiele:

- 2nd Factor so das Angriffe auf das übertragene Passwort nicht mehr möglich sind

- Nativen Clients für die gängigen Betriebssystemplatformen die Guard dann mit lokalem Schlüssel betreiben können.

Dafür muss aber erstmal eine kritische Nutzerbasis her, es muss vorrangehen. Also müssen wir mithelfen, es nutzen, es verbessern, es fördern.

Daniel

P.S. Und mal ehrlich, liegt der Schlüssel auf einem lokalen Windows oder Android Device sicherer als auf einem Linux Cluster den Heinlein managed in Zeiten in denen man eine beliebige Malware in 15 Minuten so packt das kein Virenscanner anschlägt und man den Client übernimmt? Ganz ehrlich? Nein.

Foto
3

"Eine Ende-Ende Verschlüsselung mit PGP verwendet auch nach Jahrzehnten

niemand, weil es zu kompliziert ist. Theoretisch sicher, die User

Experience ist eine Katastrophe. Das ist der status quo. Es funktioniert

nicht und mit niemandem. "

Es ist weder richtig, dass niemand richtiges PGP verwendet, noch das es mit niemandem funktioniert. Ok ich weiß was du sagen willst, es verwenden nur sehr wenige und es funktioniert nur mit jenen die es verwenden. Ok.

Mag noch hinzugefügt werden, dass es gerade im OpenSource Entwicklungsbereich fast alle nutzen und auch unter IT-lern gibt es doch einige. Aber richtig es bleibt eine wenig verwendete Technik die fast ausschließlich von Technikern oder teilweise Leuten mit hohen Sicherheitsanforderungen verwendet wird (Journalisten etc.)

"Jetzt hat einer eine Idee und entwickelt ein System das in der Praxis fast genauso sicher ist, aber benutzbar."

Nein es ist nicht genauso sicher, nicht mal im Ansatz.

"Und zeitgleich arbeitet der mit allen großen Providern zusammen und hat eine

echte Chance was zu bewegen im bereich Email Sicherheit."

Guard wird von anderen großen Providern unterstützt? Ist mir neu.

"Wollen wir das jetzt nutzen und fördern und verbreiten oder wollen wir das

schlechtreden weil es nur 90 % sicher ist und theoretische Lücken bleiben?"

Es ist nicht 90% so sicher wie Ende zu Ende, es ist nicht mal 1% so sicher. Es suggeriert nur etwas das es nicht ist. Und das ist gefährlich.

"Fakt ist doch:

Für 99,9 % der Anwender stellt die Nutzung von Guard einen massiven Zugewinn an Sicherheit dar."

Nein, das ist sicher kein Fakt.

"Und diejenigen die Ende-Ende verschlüsseln wollen können das auch tun, indem sie Guard mit eigenen lokalen Schlüsseln verwenden."

Nein Guard hat mit Ende zu Ende NICHTS aber auch gar nichts zu tun.

"Das ist der erste Ansatz der funktionieren könnte und Nutzer von plantext Emails webführt, das ist doch das entscheidende, den Nutzer überhaupt erstmal abzuholen

anstatt ihn weiter im Regen stehen zu lassen!"

Plaintext auf dem Transportweg ist es heute schon nicht mehr dank konsequenter SSL Verschlüsselung. (Wobei unter Vorbehalt)

Guard ändert daran nur wenig. Wenn Alice eine Mail an Bob schickt, kann sowohl der Provider von Alice als auch der Provider von Bob potentiell den Inhalt lesen. Die versprechen natürlich es nicht zu tun aber sie können es.

Vorrausgesetzt Alice ist bei mailbox.org und verwendet Guard dann kann mailbox.org potentiell immernoch den Inhalt lesen, vorrausgesetzt sie ändern kurz etwas auf ihrem Server und fangen die Passworteingabe ab (oder ein Angreifer tut dies). Genauso kann der Provider von Bob den Inhalt lesen, denn da Bob kein PGP hat und sein Provider kein Guard anbietet, bekommt er ja einen Link und ein Passwort zu dem link. Den könnte sein Provider aber genauso nutzen.

Also unterm Strich ist genau nichts gewonnen. Man kann höchstens den leicht erhöhten Aufwand für die beiden Provider gutschreiben. Aber der Auffwand ist eigentlich nicht nennenswert wenn die Provider wirklich wollen.

Sollte Bob "richtiges" PGP (Ende zu Ende) auf seinem PC haben, kann ihm Alice zwar verschlüsselt schreiben, doch potentiell könnte der Provider von Alice der ja Guard verwendet immernoch die Schlüssel austauschen und Man in the Middle machen, sobald dieser einmal das Passwort abgefangen hat. Also ist wieder nichts gewonnen.

"- Nativen Clients für die gängigen Betriebssystemplatformen die Guard dann mit lokalem Schlüssel betreiben können."

Lokale PGP Programme verwenden kein Guard, ich vermute da liegt ein Missverständnis vor. Lokale Programme könnten höchstens den in Guard vorhanden Schlüssel verwenden, doch das macht das wie oben beschreiben auch nicht sicherer.

"Aber mal ehrlich, liegt der Schlüssel auf einem lokalen Windows oder Android Device sicherer als auf einem Linux Cluster den heinlein managed? Ich denke nein. "

Das kommt stark auf den Anwender an. Bei Tante Emma ist es mit der Client Sicherheit sicher nicht weit her und mit Smartphones sollte man im allgemeinen nichts sicherheitskritisches machen. So man ein ITler dürfte aber durchaus seine Endgeräte sicher halten können.

Die Frage ist aber sowieso eigentlich (fast) sinnfrei. Der potentiell unsichere Client wird immernoch verwendet um die Mails bei mailbox.org zu lesen und zu schreiben. Zwar hat der möglicherweise kompromittierte Browser keinen direkten Zugriff auf die Schlüssel, aber hat ein Angreifer erst einmal den Client unter Kontrolle, kann er die Mails trotzdem lesen. Und Ob dann nicht einfach noch einen Schritt weitergegangen werden kann und der Schlüssel heruntergeladen wird, naja lassen wir das.

Sicherheit setzt vorraus das die Endgeräte sicher sind. Ende zu Ende Verschlüsselung schützt den Inhalt vor den Augen des Providers und selbst wenn dieser kompromittiert wurde, ist der Inhalt nur für die Kommunikationspartner sichtbar.

Heißt also mit "echtem" PGP müssen hinsichtlich der Vertraulichkeit des Inhalts nur die Endgeräte sicher sein.

Bei Guard müssen die Endgeräte UND die Server von mailbox.org sicher sein. Also eine große Komponente die zur Rechnung hinzukommt und die Sicherheit verringert.

[edit]

Es sei erwähnt das die Sicherheit (wesentlich) verringert im Vergleich zu echtem PGP. Im Vergleich zu normalem Mailbetribe ohne Guard und ohne PGP ist einfach nur nichts dazugewonnen (oder wohlwollend vielleicht ein ganz kleines bisschen, gewürzt mit einer großen Chance für ein Gefühl falscher Sicherheit)

[edit ende]

Und wie ich weiter oben bereits erläutert habe, fügt Guard auch keine Sicherheit hinzu, da der Nutzer immernoch dem Provider vertrauen muss.

Davon abgesehen was ist denn wohl das lohnendere Ziel eines gezielten Angriffs:

Ein einzelner Server mit 10.000 Keys, deren Passwörter man nach der Komprommitierung bloß noch abfangen muss?

Oder 10.000 Einzelne Endgeräte?

PS: gibt es hier keine Zitierfunktion oder finde ich die einfach nicht?

Foto
2

Deine Argumente sind nur teilweise richtig, machen aber in Summe weiterhin keinen Sinn für mich im Gesamtkontext. Das ist eine Elfenbeinturm Argumentation:

Herr Müller, seien Sie doch nicht so bescheuert und ersetzen ihre aus Brettern bestehende Kellertür die festgerostet ist durch eine hochwertige Stahltür mit einem Schloss von Abus und einer Alarmanlage. Abus könnte kompromittiert werden, die sind ein lohnenswertes Ziel weil die viele 10.000 Schlösser handeln. Entweder Sie bauen eine richtige Tresortür an ihren Kellereingang und ersetzen die Scheiben durch Panzerglas, oder sie lassen die Brettertür wie sie ist. Im realen Leben würde niemand so argumentieren, und Email ist real, also lassen wir das doch besser.


OX Guard ist für mehr als 99 % der Anwender, so auch für mich, ein immenser Gewinn an Sicherheit, seit dem ich OX Guard nutze bekomme ich überhaupt mal verschlüsselte Emails und kann sensible Informationen so verschicken das nicht jeder Horst mitlesen kann. Oder hast Du deiner Personalabteilung Ende-Ende PGP beigebracht? ;-)

Man könnte mir übrigens auch Ende zu Ende verschlüsselte Mails schicken, ein zweiter Schlüssel dafür liebt auf dem Keyserver. Macht aber kaum einer, die letzten Jahre.


Also: Raus aus dem Elfenbeinturm, bessere Alternative nennen oder mitmachen statt den Kopf in den Sand zu stecken :)

Guard wird momentan bei diiversen Providern ausgerollt, ich schätze mal bis Ende des Jahres bei mehreren zehn Millionen Anwendern. Dann macht es noch viel mehr Sinn und dann kann man auch mal gucken wie man Technologien implementiert das der private Key ein Tolen gar nicht mehr

verlässt. Sobald ein Key auf einem Windows oder Android System liegt ist er als kompromittiert zu betrachten, das hat die 0day Schwemme der letzten Jahre eindrucksvoll bewiesen. Deswegen machern lokale Keys keinen Sinn, solange sie nicht auf Tokens liegen. Auch hier ist Yubico ein interessanter ansatz, auf die Neos kann man Keys schon draufpacken, wenn denn nur Apple die NFC Schnittstelle für 3rd Parties freigeben würde und Open-Xchange 2nd Factor implementieren würde, ja dann hätten wir das perfekte System oder? Ich halte meinenm Yubikey ans Handy / stecke ihn in die Hardware, der private Schlüssel bleibt drauf.


Aber der erste Schritt kommt vor dem zweiten, wie es nicht geht wissen wir ja schon, und das ist was Du beschreibst, das ist bewiesenermaßen tote Technologie die wir abschütteln sollten.


Daniel

Foto
1

Mir fehlt bis jetzt einfach eine Begründung an welcher Stelle Guard zusätzliche Sicherheit bietet.

Für den Transport von eMail gibt es SSL, was grundlegend erstmal einfache Beobachter ausschließt. Die Provider haben jedoch immernoch Zugriff auf die eMails der Nutzer. Um dem entgegen zu wirken kann man z.B. PGP (oder SMIME) einsetzen wodurch der Provider die Inhalte nicht mehr zu sehen bekommt.

Wie bereits erklärt bietet Guard nur eine Sicherheit die wieder beim Provider endet und somit prinzipiell keinen wesentlichen Sicherheitsgewinn im Vergleich zu dem bereits vorhandenem SSL bietet. Also warum sollte man es nutzen wenn es im Prinzip nichts bringt?


"Guard wird momentan bei diiversen Providern ausgerollt, ich schätze mal

bis Ende des Jahres bei mehreren zehn Millionen Anwendern."


Das ist interessant zu wissen. Hast du dazu weitere Informationen (link z.B.)?

Die Frage bleibt: Was ist durch Guard gewonnen?


"Sobald ein Key auf einem Windows oder Android System liegt ist er als

kompromittiert zu betrachten, das hat die 0day Schwemme der letzten

Jahre eindrucksvoll bewiesen."


Keine Ahnung wie ich das sensibel ausdrücken kann aber das ist einfach nur absoluter Unsinn.

Wie bereits in einem anderem Post erwähnt, Sicherheit ist niemals absolut. Wer so argumentiert hat ganz ofensichtlich keine Ahnung von diesem Thema.


Davon einmal abgesehen bleibt es bei dem Problem, dass die diener Meinung nach scheinbar prinzipiell kompromitierten Systeme auf die Emails zugreifen die durch Guard geschützt sind. Damit sind die Inhalte auch kompromittiert und nichts ist gewonnen.


Man kann sicher an irgendeinem Punkt argumentieren, dass Guard irgendeine Art von zusätzlicher Sicherheit bietet. Bisher habe ich bloß noch keine Erklärung gesehen wo das sein soll.

Foto
Foto
1

Zitat: "Bei Tante Emma ist es mit der Client Sicherheit sicher nicht weit her

und mit Smartphones sollte man im allgemeinen nichts

sicherheitskritisches machen. So man ein ITler dürfte aber durchaus

seine Endgeräte sicher halten können."


Also sollte Tante Emma den Guard nutzen und der ITler kann natürllich sein PGP auch lokal aufsetzen und braucht keinen Guard.


Zitat: "Nein Guard hat mit Ende zu Ende NICHTS aber auch gar nichts zu tun."


Das haben wir auch nirgends behautet. Wir behaupten nur, das der Guard kompatibel mit OpenPGP ist. Darf man keine Lösungen entwickeln, die mit OpenPGP kompatibel sind, nur weil Sie OpenPGP mit Ende-zu-Ende gleichsetzen?

Foto
1

Ja Tante Emma darf ruhig Guard einsetzen und es kann auch ruhig mit OpenPGP kompatible sein.

Mein ursprünglier Post thematisierte die Problematik, das Nutzer von Guard, die Verwendung von PGP durch Guard mit PGP und Ende zu Ende Verschlüsselung gleichsetzen könnten und somit ein falsches Gefühl der Sicherheit erzeugt wird. Solange darauf hingewiesen wird, dass Guard kein "klassisches" PGP darstellt ist das in der hinsicht nicht länger ein Problem.

Daher mein Vorschlag doch bitte einen eindeutigeren Hinweis bei der Einrichtung von Guard anzuzeigen.

Momentan werden nämlich nur dann Nutzer auf diese Umstände hingewiesen wenn die die FAQs lesen.

Vielleicht lässt sich diese kleine Verbesserung ja einrichten.


Es bleibt natürlich die Grundsatzfrage wieviel Sicherheit Guard überhaupt bietet aber das ist vielleicht nicht der richtige Ort dafür.

Foto
Foto
2

Man mag über die Guard Funktion ja durchaus geteilter Meinung sein, aber einen einfachen Hinweis für den Anwender halte ich auch für angebracht.


Im ersten Moment wusste ich auch nicht recht was dieses Feature bewirkt.

Foto
1

Also, soweit es um die Klarheit der Darstellung hinsichtlich des Nutzens geht: Das sollte natürlich klar gemacht werden.

Ansonsten war die Diskussion für mich nicht nachvollziehbar, weil die Bedrohungsszenarien völlig offen geblieben sind. Für die allermeisten Leute wird die NSA nie ein Problem darstellen. Realistischer sind Szenarien, in denen deutsche (oder europäische) Gefahrenabwehr- oder Strafverfolgungsbehörden ein E-Mail-Postfach beschlagnahmen wollen. Die stehen, wenn man Guard verwendet, blöd da und werden niemals in der Lage sein, das zu knacken. Eine Pflicht, seinen Schlüssel und/oder Passwort herauszugeben, gibt es - entgegen der Behauptung in einem Kommentar weiter oben - nicht. Mailbox.org müsste grds. herausgeben, was sie haben. Aber ohne Passwort hilft das auch nicht weiter. Ansonsten dürften Hacker nicht ohne massiv (!) gesteigerten Aufwand in der Lage sein, Postfächer mit Inhalt zu übernehmen. Darin sehe ich einen deutlichen Sicherheitsgewinn. Man möge mir erklären, wo da der Fehler liegt.

Vorab: Mir ist völlig egal, ob irgendwer der Auffassung ist, der Begriff PGP sollte nur im Fall von Ende-zu-Ende-Verschlüsselung verwendet werden.

Foto
1

"Eine Pflicht, seinen Schlüssel und/oder Passwort herauszugeben, gibt es -

entgegen der Behauptung in einem Kommentar weiter oben - nicht.

Mailbox.org müsste grds. herausgeben, was sie haben. Aber ohne Passwort

hilft das auch nicht weiter."

Es gibt aber die Möglichkeit das Behörden eine sogenannte Fangschaltung von mailbox.org fordern und damit dann das Guard Password bei der Eingabe abgefangen wird. Damit können die dann auch die auf dem Server vorhandenen Schlüssel verwenden.

Auch in dem Fall das mailbox.org gehackt wird ist alle Sicherheit dahin. (Und das ist auch jeden Fall weniger aufwendig als 10.000 Clients gezielt zu kompromittieren)

"Ansonsten dürften Hacker nicht ohne massiv (!) gesteigerten Aufwand in der Lage sein, Postfächer mit Inhalt zu übernehmen"

Sobald ein Client den du für die Verwendung von mailbox.org benutzt von einem Angreifer oder Virus komprommitiert wurde, kann dieser auch dein Guard und login Password abfangen und eben auch deine auf dem Server gespeicherten Schlüssel runterladen. Daher halte ich das Argument, Guard helfe gegen unsichere Clients, für ziemlichen Unsinn.

"Darin sehe ich einen deutlichen Sicherheitsgewinn. Man möge mir erklären, wo da der Fehler liegt."

In dem mangelnden Use Cases:

Wie bereits oben erwähnt kann Tante Emma ihrem Enkel, der ja richtiges PGP hat, verschlüsselte Mails schicken und der Provider von dem Enkel kann die nicht lesen (der von Tante Emma theoretisch schon).

Da aber ebenfalls erwähnt wird das PGP kaum verbreitet ist, ist dies ein seltener Use Case.

Der einzige Punkt in dem die Sicherheit durch Guard nachweislich erhört wird, ist das ein Beobachter im Netz den opportunistisch verschlüsselten smtp Traffic zwischen den Providern nicht mehr lesen kann (die Metadaten allerdings schon), was aber zumindest bei der Verwendung von DANE ebenfalls ausgeschlossen werden kann.

Daher bietet Guard eben nur einen sehr geringen zusätztlichen Schutz und auf keinen Fall irgendeinen Ersatz für richtiges Ende zu Ende PGP. (Diesen Eindruck kann man aber leicht erhalten)

So lange sich der Nutzer dieser Umstände bewusst ist, besteht natürlich kein Problem.

Daher halte is es auch für erforderlich die Nutzer klar darauf hinzuweisen was Guard bietet und was nicht.

Foto
1

Danke für die Antwort.

"Es gibt aber die Möglichkeit das Behörden eine sogenannte Fangschaltung von mailbox.org fordern und damit dann das Guard Password bei der Eingabe abgefangen wird. Damit können die dann auch die auf dem Server vorhandenen Schlüssel verwenden."

Zunächst eine technische Frage dazu: Ich meine gelesen zu haben, dass die Passwortübergabe so ausgestaltet ist, dass ein Abfangen technisch schon nicht möglich ist. Vielleicht könnte sich ja noch einmal jemand von mailbox.org dazu äußern.

Zur rechtlichen Seite: Dass einfach eine solche "Fangschaltung" gefordert werden kann, ist für mich aufgrund der strafprozessualen Befugnisse nicht ersichtlich. Die Zeugenpflicht bezieht sich auf vorhandene Daten, auf die ohne Weiteres zugegriffen werden kann. Eine weitergehende Inpflichtnahme ist nicht vorgesehen. Wenn das Passwort nicht praktisch völlig ungeschützt übertragen wird und deshalb ohne Weiteres von mailbox.org abgegriffen werden könnte, bedürfte es wohl umfangreicherer Eingriffe in das eigene System. Um so etwas zu fordern, bedürfte es einer sehr klaren und eng begrenzten Eingriffsermächtigung für die Strafverfolgungsbehörden. In der Tendenz geht das in Richtung einer Quellen-TKÜ, die im Strafprozess unzulässig und in sehr eng begrenzten Fällen lediglich bei Gefahrenabwehrmaßnahmen zulässig ist, wobei die Ermächtigung zur Quellen-TKÜ im hier diskutierten Fall nicht einschlägig sein dürfte.

Zu diesen Themen (nicht speziell zu einer Fangschaltung) kann man Weiteres lesen im Gutachten von Ulrich Sieber für den 69. Deutschen Juristentag, S. C116-C122.

Dass Guard nicht notwendig sicherer ist als mein Client sehe ich ein. Ich verstehe jedoch nicht, wie mailbox.org so gehackt werden könnte, dass alle Postfächer auf einmal kompromittiert wären, wenn nicht zugleich alle Passwörter erbeutet werden, die ja nicht dauerhaft gespeichert sind.

Einig sind wir uns in jedem Fall, dass klar kommuniziert werden sollte, was Guard leistet.

Entscheidend ist für mich jedoch, dass es zur Verbreitung von PGP beitragen kann.

Foto
1

Eine Verpflichtung zur Implementierung einer Fangschaltung zum Abgreifen von Passwörtern für Behörden gibt es nicht und wir haben sowas auch nicht. Wir können Eure Guard-Passwörter nicht abgreifen und wir haben keinen Zugriff darauf. Es besteht nur die Verpflichtung, evtl. im Klartext vorhandene Passwörter herauszugeben (erweiterte Bestandsdatenauskunft mit Richtervorbehalt).

TKÜ nach §100 a/b StGB: betrifft nur Daten, die dem Provider im normalen Betrieb im Verlaufe eines Kommunikationsvorgangs an beliebiger Stelle der Datenverarbeitung unverschlüsselt vorliegen. Es besteht keine Verpflichtung für den Provider, eine Verschlüsselung zu knacken.

(Ob man davon ausgehen muss, dass uns die Daten bei der Guard Verschlüsselung zwischenzeitlich unverschlüsselt vorliegen, oder ob man den Guard in Kombination von Webinterface und Server-Backend als geschlossenes System betrachten und wir als Provider nur Zugriff auf den den verschlüsselten Output haben, ist mir als Nicht-Jurist nicht ganz klar. Derzeit haben wir keinen Zugriff auf die unverschlüsselt Daten des Guard vor der Verschlüsselung oder nach der Entschlüsselung.)

Bestandsdatenabfrage: betrifft nur gespeicherte Daten, für die der Nutzer die Gelegenheit hatte, sie zu löschen (grob gesagt, also keine laufende Kommunikation). Es besteht für den Provider keine Verpflichtung, diese Daten zu entschlüsseln oder Keys zur Entschlüsselung vorzuhalten, wenn sie verschlüsselt sein sollten.

Soweit eine Zusammenfassung der juristischen Lage nach meinem Kenntnisstand. Vielleicht beantwortet es einige Fragen.

Die Frage, ob der Guard in einem konkreten Kontext und für ein konkretes Bedrohungsszenario geeignet ist, muss jeder für sich selbst beantworten und kritisch hinterfragen. Wir wollen mit dieser Lösung ein Angebot machen, das Vorteile und Nachteile hat, aber in jedem Fall die Palette der Möglichkeiten erweitert.

Disclaimer: Ich bin KEIN Jurist!

Foto
1

Danke für die Antwort. Das ist inzwischen natürlich deutlich off-topic, aber das hat jetzt mein professionelles Interesse geweckt. :-)


Rechtlich waren die Ausführungen zutreffend. Mich würden ergänzend noch ein paar Details interessieren.

In den FAQs zu Guard habe ich folgenden Absatz gefunden:

"Diese Schlüssel sind dabei weiterhin durch ein nur dem User bekanntes Passwort geschützt und dem Zugriff durch uns entzogen. Erst ein aktiver Login eines Nutzers entschlüsselt diese privaten Schlüssel. Zahlreiche weitere Schutzmechanismen verhindern weiter wirkungsvoll, dass wir Serverbetreiber selbst bei einem aktiven Login des Nutzers Zugriff auf die PGP-Schlüssel erhalten oder diese im Programmspeicher im Klartext gespeichert werden."


Der Schlüssel bleibt damit geschützt. Gilt das auch für die E-Mails, die ich entschlüssele oder können die in diesem Moment auch von Euch im Klartext mitgelesen werden?


Mich würde auch interessieren, ob ihr praktisch schon einmal mit entsprechenden Fragen konfrontiert wart.


PS.: Kleine Ergänzung zu oben. Ob eine Quellentelekommunikationsüberwachung im Ermittlungsverfahren zulässig ist, ist umstritten. Das nur zur Klarstellung, weil ich den Beitrag nicht mehr ändern kann, das aber nicht so definitiv stehen lassen wollte, wie ich es erst formuliert hatte. Soll hier aber auch keine weitere Rolle spielen.

Foto
1

Anmerkung zur Antwort von meinen Support-Kollegen weitet oben: Auch wenn mein Support-Kollege dort kein Jurist ist, so bin ICH (als "Chef" von mailbox.org) übrigens Jurist, habe übrigens Datenschutz beim damaligen Berliner Datenschutzbeauftragten Manfred Garstka studiert und beschäftige mich seit 25 Jahren Providertätigkeit mit all diesen Fragen rund um Datenherausgabe, TKÜV, polizeilichen Maßnahmen und Beschlagnahmungen. Die Ausführung meines Kollegen entsprechen unserer (=meiner) "offiziellen Hausmeinung" und auch ich stimme mich natürlich weiterhin und kontinuierlich mit aktuell darauf spezialisierten Anwälten ab.

Insofern maßen wir schon an, hier sehr sorgfältig, sehr abgewogen und sehr durchdacht zu handeln und vorzugehen und treffen insb. keine einfach dahergesagten Aussagen nach Gutdünken, Glauben und Küchentischwissenschaft.

Foto
1

@2812272: Die decodierten E-Mails liegen nur temporär im "RAM" des Computersystems vor und werden von dort an den User ausgeliefert. -Logisch, anders geht es nicht. Sie befinden sich aber zu keinem Zeitpunkt "decodiert" auf der Festplatte. Ein Zugriff durch uns wäre nur noch aktiven Eingriff in den Programmcode und Aushebelung der dort ausdrücklich hinterlegten Sicherheitsmechnismen möglich, die genau diesen Zugriff verhindern sollen. Insofern muß man sagen, daß wir diese Daten NICHT im Klartext auslesen können (nicht "einfach so" und nicht mit diesem laufenden Programmcode).

Das Guard-Modul ist maßgeblich auf unseren Wunsch und auch unsere Spezifikation eng mit uns zusammen entwickelt worden. Und wir von mailbox.org WOLLEN gar nicht in der Lage sein, Daten auszulesen und schaffen Mechanismen, daß man uns (soweit es geht) gar nicht erst trauen muß.

Foto
1

Vielen Dank für die ausführliche Rechtliche Darlegung.

Und auch für die Klarstellung bezüglich des Schutzmechanismus für die Guard Keys. Die angesprochene notwendige Änderung des Programmcodes zum auslesen von Passwörten, wäre eben auch etwas das ein versierter Angreifer machen könnte um die Schlüssel nutzen zu können.

Letztendlich basiert die sichere Aufbewahrung und Handhabung der Schlüssel auf der Absicherung einiger weniger Systeme. Und da sollte eben jeder selber wissen ob man das Risiko eingehen kann und ob es überhaupt Sinn macht dieses System zu verwenden.

Foto
2

Natürlich könnte ein versierter Angreifer hier ansetzen. Vom Risiko und Schutzniveau wird es jedoch wesentlich einfacher sein, eben diese Eingriffe auf den heimischen Desktop-PCs durchzuführen.

Natürlich gibt es immer ein Risiko und ein Ansatz. Aber in dieser ganzen Diskussion wird immer so getan, als ob der PC des Users plötzlich die unhackbare, unneinnehmbare Festung wäre, bei der jeder Fremdzugriff nicht ansatzweise möglich sei. Jede tägliche Praxis beweist das Gegenteil.

Insofern muß man fragen: Es ist denn die Alternative? Der Desktop-PC? Wohl kaum.

Foto
1

Danke für die Antwort!


Für mich sind die Fragen damit hinreichend geklärt. Ich habe mir auch noch einmal die FAQs durchgelesen und empfand sie als hinreichend deutlich. Daraus geht klar hervor, dass keine Ende-zu-Ende-Verschlüsselung gewährleistet wird.


Es obliegt nun jedem Einzelnen, für sich zu entscheiden, welche die relevantesten Bedrohungsszenarien sind und ob Guard einen Gewinn darstellt. Ich denke, wer ernsthaft Gefahren für sich sieht, wird sich so mit dem Thema befassen, dass er eine halbwegs informierte Entscheidung wird treffen können.

Foto
1

"Natürlich könnte ein versierter Angreifer hier ansetzen. Vom Risiko und Schutzniveau wird es jedoch wesentlich einfacher sein, eben diese Eingriffe auf den heimischen Desktop-PCs durchzuführen."

Das kommt zwar auch auf den Anwender an, aber insbesondere wenn man bedenkt das ein einzelner Angriff auf den Provider die selben Auswirkungen hat wie 10.000 Angriffe auf einzelne Clients, sieht das ganze schon anders aus.

"Natürlich gibt es immer ein Risiko und ein Ansatz. Aber in dieser ganzen Diskussion wird immer so getan, als ob der PC des Users plötzlich die unhackbare, unneinnehmbare Festung wäre, bei der jeder Fremdzugriff nicht ansatzweise möglich sei. Jede tägliche Praxis beweist das Gegenteil.

Insofern muß man fragen: Es ist denn die Alternative? Der Desktop-PC? Wohl kaum."

Die sichere Verwendung von Guard erfordert aber ebenfalls einen sicheren Client. Ein kompromittierter Client kann sowohl das Password abgreifen als auch Schlüssel herunterladen und an den Angreifer übertragen.


Es ist also in der Hinsicht überhaupt nichts gewonnen. Es wurde nur eine zusätzliche Komponente (Der Server) hinzugefügt, der einen zusätzlichen Angriffvektor hinzufügt.

Daher verstehe ich auch nicht warum man Guard als ein feature gegen unsichere Clients bewirbt. Dieses Feature macht die Handhabung der Schlüssel unsicherer, nicht sicherer.

Foto