mailbox.org zeigt bereits bei der Eingabe des E-Mail-Empfängers dessen Sicherheitsverschlüsselung an
Das Thema Sicherheit bei E-Mail- und Messenger Diensten haben wir ja des Öfteren zum Thema gehabt. Vielleicht erinnert Ihr Euch an eine Meldung von vor wenigen Wochen, in der mehr oder weniger erstmals offiziell bekannt wurde, dass Google offenbar bei seinen Diensten nicht sonderlich viel von sicherer SSL-Verschlüsselung hält. Solche Meldungen sind es, die uns das Wort Sicherheit immer mehr ins Gehirn prägen und uns auf die Suche nach sicheren Alternativen umschauen lassen.
Der E-Mail Anbieter mailbox.org möchte ein leuchtendes Beispiel auf diesem Feld sein und gibt nun laut eigener Aussage noch vor dem Versand einer E-Mail Auskunft über das Sicherheitslevel der Empfänger. Bereits bei der Eingabe einer E-Mail-Adresse des Empfängers soll klar erkennbar sein, ob die E-Mail nach dem Versand über eine SSL-verschlüsselte Verbindung gesichert übertragen wird.
Um es dem Versender vereinfacht darzustellen, führt mailbox.org eine drei Stufen-Klassifizierung mit entsprechenden Symbolen ein. Ein rotes offenes Schloss-Icon soll davor warnen, dass das Zielsystem keine Verschlüsselung anbietet. Eine normale SSL-Verschlüsselung wird über einen grünen gesicherten Briefumschlag symbolisiert. Und wenn das Zielsystem schlussendlich den höchsten Sicherheitsstandards inklusive DANE und DNSSEC-gesicherter Verbindung entspricht, erscheint ein Briefumschlag mit Siegel.
mailbox.org selbst setzt beim Versand der E-Mails ausschließlich auf PGP-Verschlüsselung, die zwei unterschiedliche Sicherheitsschlüssel erzeugt. Der Public Key, dessen Zweck es ist, empfangene E-Mails so zu verschlüsseln, dass sie nicht mehr entschlüsselt werden können und der Private Key, mit dem ausschließlich der Empfänger entschlüsseln kann, was andere gesendet haben.
Wird geladen ...
@Knut:
Ich sehe den Nutzen weniger darin das ich weiß ob ich jetzt verschlüsselt schreibe oder nicht sondern darin das der Kommunikationspartner genervt wird weil bei ihm das Schloss „kaputt“ ist.
Mal so als Vergleich Google Chrome und Zertifikate mit SHA-1 Signatur. Vorher hat es niemanden interessiert ob die Zertifikate mit SHA-1 oder SHA-2 signiert wurden.
Inzwischen bekommen die Seitenanbieter die Information das ihre Verschlüsselung „kaputt“ ist weil der Chrome Browser „https“ durchgestrichen anzeigt. Die Nutzer verstehen zwar den Hintergrund nicht aber die gewünschte Wirkung wird erreicht. Das Ende von SHA-1 wurde deutlich beschleunigt, auch wenn es mich persönlich nervt weil ich der arme Tropf bin der den Kunden die Zertifikate austauschen darf weil sie das selber nicht hinbekommen.
@Knut
Ich sehe den Mehrwert darin das Anbieter die keine Verschlüsselung benutzen von ihre Kunden genervt werden weil der Kommunikationspartner ihnen sagt das das Schloss bei ihnen kaputt ist.
Das ist so ähnlich wie der Effekt wenn Google Chrome „https“ durchgestrichen anzeigt weil das Zertifikat noch mit SHA-1 signiert ist. Die Nutzer nerven den Anbieter und nervt mich weil er das Zertifikat so schnell wie möglich ausgetauscht haben will.
Nervt mich zwar aber dafür verschwindet SHA-1 schneller aus dem Internet als das der Fall gewesen wäre wenn einfach 2017 keine neuen Zertifikate mehr mit SHA-1 Signatur ausgestellt worden wären.
Kleines Update von mailbox.org: Ab Montag Nachmittag werden wir auch Details zum verwendeten TLS_Protokoll (TLS 1.0, 1.1, 1.2) und auch zu den jeweils ausgehandelten Ciphers einblenden.
Was bei meinem Server TLS 1.2 und ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) sein dürfte wenn mein Log stimmt 🙂
@Knut Ich sehe den Mehrwert darin das Nutzer von mailbox.org die Empfänger ihrer Emails darauf aufmerksam machen können das ihre Provider keine Verschlüsselung nutzen. Genauer gesagt wird die Mitteilung lauten „Dein Schloss ist kaputt“ oder so ähnlich.
Bei Google Chrome funktioniert die Methode recht gut wenn es darum geht SHA-1 signierte Zertifikat aus dem Verkehr zu ziehen.
Die Nutzer meckern die Seitenbetreiber an und die meckern mich an das ich ihre Zertifikate bei der CA gegen SHA-2 signierte Zertifikate austausche. Nervt zwar aber damit wurde der Abschied von SHA-1 deutlich beschleunigt.
Wir haben das Angebot heute Nachmittag noch etwas erweitert und zeigen ab sofort auch die von uns ausgehandelte TLS-Version sowie den verwendeten Cipher an.
Diese Angabe ist rein zu Informationszwecken; wir können nicht garantieren, dass die hier genannten Versionen/Ciphers nicht beim Versand unterschritten werden.
Schönen Gruß
Peer Heinlein
(mailbox.org)
@Peer Heinlein: Das komplett verschlüsselte Postfach ist also in Arbeit. Ist auch ein Zeitrahmen ersichtlich, ob das eventuell noch dieses Jahr online gehen wird? Wird es auch möglich sein, mit (mobilen) Mail-Clients darauf zuzugreifen? Wenn ja: Welche?
Code-Lieferung war zu Ende Mai abgesprochen. Wir rechnen jeden Tag damit und brauchen dann einige Zeit für Testing und Rollout.
„Dieses“ komplett verschlüsselte Postfach geht auch mit mobilen Clients, das ist dann voll transparent. „Das andere“ verschlüsselte Postfach geht auch zumindest über browser und Co.
Wartet mal kurz ab, gebt uns noch eine Runde. Wir haben hier ein halbes Dutzend heißer Sachen auf der Zielgeraden.
Besten Dank! 🙂
@Peer Heinlein
Ich werfe dann nochmal die 2-Faktor-Authentifizierung in den Pott.
Warum ist diese nicht kostenlos und grundlegendes Feature bei mailbox.org?
Das schafft sogar Gmail 😉
Steht seit Monaten und Anfang an auf der Agenda. Aber wir schaffen nicht alles gleichzeitig. Und darum müssen wir gewichten, was unserer Einschätzung nach unseren Usern und uns am meisten bringt und Sachen in dieser Reihenfolge abarbeiten. Die Tage sind endlich.
Das hat irgendwann mit „wollen“ nichts zu tun, sondern ist eine Frage der Prioritätensetzung. Und ich denke, daß das, was die nächsten 6 Wochen kommt, wichtiger ist/war, als eine generische 2F-Authentifizierung.
Ansonsten ist das in Arbeit — wir halten ja sogar Vorträge über U2F… Aber das, was wir hier betreiben, ist im Zusammenspiel eine hochkomplexe Infrastruktur wo jede Änderung zu *alle* passen muß. Es ist sehr einfach „mal eben“ einen Roundcube mit einem U2F o.ä. aufzusetzen, es ist wesentlich schwieriger das bei uns
a) in einem Dutzend verschiedener Programme gleichzeitig zu machen,
b) über all das auch noch konsequentes Sharing von Kalendern/Dateien/Mailfoldern etc. zu berücksichtigen (unsere Konkurrenz hat oft kein Sharing, da fallen viele Probleme weg!)
c) zu bedenken, was die Zukunft bringt, weil wir nicht heute ein Feature einführen und übermorgen wieder abkündigen können weil es anderen Produkten/Features im Weg steht (beispielsweise: Sharing. Verschlüsselte Kontakte/Kalender sind nett; aber Kontakte/Kalender-Freigaben an Dritte sind auch nett!). Was wir machen muß mit allem, was wir planen, kompatibel sein.
Insb. Sharings und Freigaben lassen hier vieles/alles anders wirken, als in anderen Lösungen. Es ist sehr, sehr leicht, die INBOX mit dem Passwort des Users zu verschlüsseln. Wir haben aber das Sharing von IMAP-Foldern an andere User. Das geht (eigentlich…) nicht, wenn die INBOX mit dem Passwort des (abwesenden) Haupt-Users verschlüsselt ist. Das sind halt Dinge, die haben andere nicht. Wir kriegen das aber hin, wir haben das gelöst… 🙂
Ja, wir brauchen manchmal länger; aber wir machen keine Schnellschüsse, sondern substanzielle Lösungen, die zukunftskompatibel sind, echte Lösungen und keine Quick-and-Dirty-Lösungen sind und eine lange Roadmap in die Zukunft verfolgen. Das dauert mal länger, aber dann kommt’s richtig.
P.S.: Wir suchen Admins, Programmierer und andere Kollegen… Bewerbungen an jobs@heinlein-support.de
Ja, sicherlich alles richtig aus der Entwicklersicht.
Mich, als einfacher 0-8-15-User, macht es dennoch nervös, wenn jemand mein Notebook klauen würde, dann geschmeidig die Passwörter meiner Mailaccounts ausliest (z.b. aus Outlook), sich anschließend auf der Webseite einloggen kann und mich durch Passwortänderung ausbootet.
Das wohl eine philosophische Frage. Als mailbox.org-Kunde ist mir die Gewichtung auf die Kernausrichtung (E-Mail-Verschlüsselung) und damit das verschlüsselte Postfach erheblich wichtiger als (U)2F – zumindest im Moment. Nicht zuletzt auch, weil das o. g. Szenario wohl auch nur einen äußerst geringen Teil der Benutzer treffen würde. Von diesem neuem Feature dürften wohl deutlich mehr profitieren. Insofern finde ich es gut und richtig wie die Prioritäten verteilt werden. Es ist ja schließlich keine generelle Absage.
@Andreas: Ja, das ist ja sicher (auch) richtig. Es sagt ja auch keiner, daß das unwichtig ist. Aber wir priorisieren beispielsweise höher daß wir zuallererst erstmal dafür sorgen, daß sich ** auf dem Smartphone/Laptop ** die fraglichen Daten nicht im Klartext befinden.
Was nützt U2F wenn auf dem Handy alles auf der SIM-Karte im Klartext rumfliegt?
Kommt ja alles noch. Geduld. 🙂
Als mailbox.org-Kunde bin ich hinten übergekippt als ich sah, dass so etwas Basales nicht von Beginn an vorhanden ist/erkauft werden muss. Aber jedem seine Sicherheitsparanoia 😀
Hier haben die das mal ausführlich getestet
https://www.dotcomsecurity.de/2015/07/kleiner-test-mit-krypto-verschluesselung-von-mailbox-org/