Wie funktioniert das mit der E-Mailverschlüsselung?

[churchnerin]

Hallo,

ich hab bei uns im unternehmen die groupware "zimbra" eingerichtet.

läuft alles soweit ganz gut, nur ist mir hinsichtlich der verschlüsselung von emails einiges unklar.

ich nutze dem zimbradesktop um mich mit dem zimbraserver zu verbinden.

bei diesem kann man als sicherheit "ssl" wählen, also geh ich jetzt davon aus, dass alle daten und emails, die von meinem zimbradesktop zum server übertragen werden und umgekehrt verschlüsselt sind.

wenn dann die email vom server zum empfänger übertragen wird, ist sie ja eigentlich nicht verschlüsselt, wenn man keine verschlüsselungsvariante (zb s/mime oder openpgp) gewählt hat, außer man ist bei einem der anbieter (freenet, 1&1, telekom, strato usw.), die die emails seit ner weile automatisch verschlüsseln, vorausgesetzt man sendet die email an einen anbieter, der diese automatische verschlüsselung auch unterstützt.

ansonsten sind die emails ja weiterhin unverschlüsselt.

gibts da jetzt nur die möglichkeit, dass die nutzer selber ihre emails entweder per s/mime oder einem programm wie pgp verschlüsseln, oder gibts da auch ne variante, die der server selber ausführen kann?

weil das problem ist ja, dass der öffentliche schlüssel immer dem empfänger mitgeteilt werden muss, ergo müsste er ja dann auch das gleiche verschlüsselungsprogramm nutzen wie der versender oder?

wäre schön, wenn mich einer aufklären könnte

danke

[Thanks-and-Goodbye]

Du hast das Dilemma sehr schön erkannt.

Es ist zu unterscheiden zwischen einer Transportverschlüsselung (der Weg ist verschlüsselt, die Mail an sich nicht) und einer echten end-to-end-Verschlüsselung, bei der die Mail selber verschlüsselt ist, so dass es egal ist wie sie transportiert wird.

Man kann natürlich die öffentlichen PGP-Schlüssel des Unternehmens austauschen, dann übernimmt das Mailgateway im Haus die Verschlüsselung.

Bearbeitet 14. Juli 2014 von Chief Wiggum
Tippfehler.

[churchnerin]

du meinst mit den öffentlichen pgp-schlüsseln die einzelnen schlüssel jedes mitarbeiters?

[Thanks-and-Goodbye]

Nein, es gibt auch sogenannte Unternehmensschlüssel. Das sind sozusagen die öffentlichen Schlüssel, die auf *@domain.tld lauten statt auf user@domain.tld.

Es wird dann nicht zwischen Mailclient des Senders und des Empfängers verschlüsselt, sondern zwischen Mailgateway und Mailgateway.

[churchnerin]

ah ok.

können die schlüssel in der regel selber erstellt werden, oder müssen die kostenpflichtig bezogen werden?

[Thanks-and-Goodbye]

Bei PGP können die selbstverständlich selbst erstellt werden... nur: welches Vertrauen hat ein selbsterstellter nichtverfizierter Schlüssel?

Siehe auch hier: http://www.heise.de/security/meldung/Mail-Verschluesselung-Mittwochs-PGP-Schluessel-zertifizieren-bei-Heise-2077038.html

Somit können wir zum nächsten Problem einer Verschlüsselung: ist derjenige, der den Schlüssel hat auch wirklich derjenige, der er vorgibt zu sein?

Gerade diese Paranoia sollte zur Zeit (Snowden und NSA) meiner Meinung durchaus gepflegt werden.

[Guybrush Threepwood]

Dabei muss man dann aber auch Verschlüsselung und Signatur unterscheiden. Bei der Verschlüsselung geht es nur darum das ein dritter die Mail möglichst nicht lesen kann. Bei der Signatur geht es darum sicherzustellen das derjenige der die Mail geschrieben hat auch wirklich der ist der er vorgibt zu sein.

[SilentDemise]

Alternativ zu PGP könnte man sonst auch über S-MIME nachdenken.

[RipperFox]

Bei der Verschlüsselung geht es nur darum das ein dritter die Mail möglichst nicht lesen kann. Bei der Signatur geht es darum sicherzustellen das derjenige der die Mail geschrieben hat auch wirklich der ist der er vorgibt zu sein.

Stimmt, und bei asymetrischer Verschlüsselung ergibt sich netterweise auch noch das eine aus dem anderen. Praktisch, denn man will eigentlich beim Entschlüsseln auch sicher sein können, dass die Nachricht nicht durch einen Man-in-the-middle verändert wurde.

[Tempest]

Dabei muss man dann aber auch Verschlüsselung und Signatur unterscheiden. Bei der Verschlüsselung geht es nur darum das ein dritter die Mail möglichst nicht lesen kann. Bei der Signatur geht es darum sicherzustellen das derjenige der die Mail geschrieben hat auch wirklich der ist der er vorgibt zu sein.

Wobei: Eigentlich muss man das gar nicht unterscheiden, sind lediglich zwei Seiten derselben Medaille.

Beim Verschlüsseln nehm ich den öffentlichen Schlüssel des Empfängers her und dieser entschlüsselt mit seinem privaten.

Beim Signieren nehm ich meinen eigenen privaten Schlüssel und der Empfänger verwendet meinen öffentlichen.

Quasi das gleiche, nur umgekehrt. Was solche Vereine wie Verisign oder Thawte freilich nicht hindert, dafür doppelt zu kassieren...

[SilentDemise]

Das sind ja auch völlig unterschiedliche Zertifikate.

[Tempest]

Das sind ja auch völlig unterschiedliche Zertifikate.

Genau das meine ich. Technisch gesehen gibts überhaupt keinen Grund dafür, warum das "völlig unterschiedliche" Zertifikate sein sollen.

In beiden Fällen muss nur die Zugehörigkeit eines Öffentlichen Schlüssels zu seinem "rechtmäßigen" Besitzer nachgewiesen werden.

Ist reine Geldschneiderei, das einem zweimal zu verkaufen, nur weil das Anwendungsszenario ein anderes ist.

[SilentDemise]

RFC 5280 und EKU

in der EKU und der KU ist klar definiert, wofür ein Zertifikat da ist. Mit einem S-Mime Zertifikat kann ich entsprechend signieren und verschlüsseln. Wo genau ist denn das Problem?

Bearbeitet 28. Juli 2014 von SilentDemise

[cortexneo]

ist das auch für offline programme auf dem pc ??? bzw outlook also nicht lokal auf dem pc sonder per webbrowser

[Thanks-and-Goodbye]

@ cortexneo: kannst du bitte vor dem Verfassen eines Beitrages nicht nur den Neocortex sondern auch den Rest des Gehirnes in Betrieb versetzen?

Hier geht es nicht um lokale Verschlüsselung, sondern um Mailverschlüsselung zwischen Sender und Empfänger.

Outlook ist ein lokal installierter Mailclient, via Webbrowser wird von Outlook.com gesprochen.

[cortexneo]

jetzt sind wir alle schlauer^^

[Thanks-and-Goodbye]

jetzt sind wir alle schlauer^^

du hoffentlich auch.