„die Installation von OpenPGP auf seinem Dienst-PC [...] beantragen“

[Spaghetticode]

Hä? Kann man das nicht einfach standardmäßig mitinstallieren, sodass das jeder einfach so nutzen kann?

[honk]

Könnte man, tut man aber nicht.

[tingelchen]

Aus gutem Grund. Muss man leider sagen. Würde man es machen, gäbe es nur ein großes Chaos bzgl. der Nutzung. Der eine ja, der andere nein, der nächste weiß nicht wie usw. Am Ende werden Haufen eMails verschickt und die Hälfte davon kann der Empfänger nicht lesen.

EtE Verschlüsselung ist Sinnvoll, ja. Aber solange das System nicht selbst entscheiden kann, ob es eine eMail Verschlüsseln kann, ohne Gefahr zu laufen das der Empfänger diese nicht entschlüsseln kann, bringt es einem genau NULL.

Es gibt noch andere Elemente welche die Kommunikation sicherer machen würde. Darunter z.B. SPF bzw. DKIM. Beide Systeme sind reine Server Side Services. sie laufen aus Benutzersicht Out of the Box und helfen dabei sicher zu gehen das Sendende Server für die Domain überhaupt zuständig sind und die Mails auf dem Weg nicht manipuliert wurden. Unter Postfix kinderleicht ein zu richten. Es nutzen dennoch nur wenige, so das man die Systeme nicht so nutzen kann, wie man sie eigentlich nutzen sollte.



1 mal bearbeitet, zuletzt am 04.05.16 15:30 durch tingelchen.

[ikhaya]

Wenn auf der Empfängerseite keine verschlüsselte Kommunikation unterstützt wird, bekommt er Klartext. Das mit dem nicht lesbar kann ich nicht nachvollziehen.

[tingelchen]

Und wie soll der Empfänger die Mail im Klartext erhalten, wenn sie verschlüsselt ist? Wie entscheidet der Sender ob verschlüsselt werden kann, oder nicht? Soll dass der Benutzer machen? Warum sollte er das? Warum sollte er mehr Aufwand betreiben als vorher?

Benutzerfreundlichkeit ist das Stichwort.

[ikhaya]

tingelchen schrieb:
--------------------------------------------------------------------------------
> Und wie soll der Empfänger die Mail im Klartext erhalten, wenn sie
> verschlüsselt ist?

Wenn du keinen öffentlichen Schlüssel des Empfängers hast und keinen im DNS und auf Schlüsselservern findest, dann geht man davon aus dass er es nicht unterstützt bis das Gegenteil bewiesen ist. Ausserdem hat man kein Schlüsselmaterial um ihm eine verschlüsselte Mail zu schicken. Es folgt daraus -> er kriegt Klartext.

>Wie entscheidet der Sender ob verschlüsselt werden kann,
> oder nicht? Soll dass der Benutzer machen? Warum sollte er das? Warum
> sollte er mehr Aufwand betreiben als vorher?

Siehe oben: Habe ich einen öffentlichen Schlüssel vom Gegenüber irgendwoher, dann nutze ich ihn, wenn nicht , nicht. Das lässt sich automatisieren ohne Probleme.

[tingelchen]

Ja? Wie lässt sich das automatisieren? Ich habe da schon einige Ideen wie das gehen könnte. Aber ohne das SMTP Protokoll dabei um zu krämpeln sehe ich keine Adäquate Möglichkeit dass dies auch Out-of-the-Box funktioniert.

Alles andere ist dran geheftet und mit externen Diensten bestückt. So schafft man mehrere Ökosysteme. Der eine nutzt S/MIME, der andere PGP, der nächste irgendwas anderes und der letzte gar nichts. Für welches System soll ich mich jetzt entscheiden? Soll ich alle nehmen? Was wenn meine Software nicht alles kann? Was wenn die eine Integration kacke ist? Am Ende kann man bei den meisten Kontakten keine Verschlüsselung aktivieren und nutzt am Ende gar keine. Genau daran ist die eMail Verschlüsselung am Ende gestorben.

Hausintern, kann man das alles entscheiden. Man bestimmt die genutzte Client Software, die Server Software und die Protokolle sowie Addons. Aber eine solche Lösung endet an den Grenzen des LAN's.

PS:
Die Idee über die DNS Schiene hab ich wieder verworfen. Auch wenn sie in erster Instanz wie prädestiniert dafür erscheint, gibt es gleich mehrere Probleme.

[ikhaya]

tingelchen schrieb:
--------------------------------------------------------------------------------
> Ja? Wie lässt sich das automatisieren? Ich habe da schon einige Ideen wie
> das gehen könnte. Aber ohne das SMTP Protokoll dabei um zu krämpeln sehe
> ich keine Adäquate Möglichkeit dass dies auch Out-of-the-Box funktioniert.

Na alle E-Mails werden auf angehängte Schlüssel geprüft.
Sind welche vorhanden werden sie in den Schlüsselbund importiert.
Schreibe ich eine neue E-Mail an jemand, schaut mein Mailprogramm nach
ob der Schlüsselbund einen öffentlichen Schlüssel des Empfängers vorrätig hat.
Wenn nicht, frage ich einen öffentlichen KeyServer.
Habe ich danach was passendes, wird er verwendet und die E-Mail
verschlüsselt.

> Alles andere ist dran geheftet und mit externen Diensten bestückt. So
> schafft man mehrere Ökosysteme. Der eine nutzt S/MIME, der andere PGP, der
> nächste irgendwas anderes und der letzte gar nichts. Für welches System
> soll ich mich jetzt entscheiden? Soll ich alle nehmen? Was wenn meine
> Software nicht alles kann? Was wenn die eine Integration kacke ist? Am Ende
> kann man bei den meisten Kontakten keine Verschlüsselung aktivieren und
> nutzt am Ende gar keine. Genau daran ist die eMail Verschlüsselung am Ende
> gestorben.

Dann kannst du doch zwischen paranoid und best-effort entscheiden, letzeres als
Standard um die Verbreitung nicht zu bremsen.
Du verschlüsselst mit dem was dein Gegenüber und du können.
S/Mime ist weiter verbreitet als PGP , zumindest nativ.
Wer S/Mime hat, bekommt eine S/Mime verschlüsselte E-Mail.
Wer PGP hat, bekommt eine PGP-Mail.
Wenn man paranoid unterwegs ist weil der Inhalt wichtig, werden Leute die beides nicht haben, ausgelassen.
Wenn man best-effort machen möchte, kriegt derjenige seine Mail halt im Klartext.
Damit stellt man sicher dass so viel wie möglich verschlüsselt wird.


> Hausintern, kann man das alles entscheiden. Man bestimmt die genutzte
> Client Software, die Server Software und die Protokolle sowie Addons. Aber
> eine solche Lösung endet an den Grenzen des LAN's.

Dafür hat man gemeinsame Standards die auch woanders unabhängig implementiert werden können
mit eventuell anderer Software.
TLS, IMAP,SMTP, POP3, PGP, S/Mime, alles schön in RFCs standardisiert.

> PS:
> Die Idee über die DNS Schiene hab ich wieder verworfen. Auch wenn sie in
> erster Instanz wie prädestiniert dafür erscheint, gibt es gleich mehrere
> Probleme.

Es ist noch nicht mal als Experimental verabschiedet, man muss sehen wie groß die Probleme in der Praxis
sein werden und wo man gegebenenfalls nachbessern muss.
Aber dazu muss man es mal ausprobieren.

[tingelchen]

> Na alle E-Mails werden auf angehängte Schlüssel geprüft.
> Sind welche vorhanden werden sie in den Schlüsselbund importiert.
> Schreibe ich eine neue E-Mail an jemand, schaut mein Mailprogramm nach
> ob der Schlüsselbund einen öffentlichen Schlüssel des Empfängers vorrätig
> hat.
>
Keine besonders Adäquate Lösung. Dann gammeln im Postfach am Ende mehrere hundert gleiche Schlüssel herum. Mal ganz davon abgesehen das man seinen eigenen Schlüssel dann auf n Geräte kopieren muss. Bei mir wären das alleine 6 Kopien. Und jedes mal wenn man ein neues Gerät hat, wieder Schlüssel kopieren. Also landen die Dinger am Ende in irgend einem Shared Medium in Netzwerk. Wo sie dank Mobile Devices wahrscheinlich eh gleich landen werden. Weil da keine USB Sticks funktionieren.

> Wenn nicht, frage ich einen öffentlichen KeyServer.
> Habe ich danach was passendes, wird er verwendet und die E-Mail
> verschlüsselt.
>
Und welchen? Nach welchem Standard?

> Dann kannst du doch zwischen paranoid und best-effort entscheiden, letzeres
> als
> Standard um die Verbreitung nicht zu bremsen.
> Du verschlüsselst mit dem was dein Gegenüber und du können.
> S/Mime ist weiter verbreitet als PGP , zumindest nativ.
> Wer S/Mime hat, bekommt eine S/Mime verschlüsselte E-Mail.
> Wer PGP hat, bekommt eine PGP-Mail.
> Wenn man paranoid unterwegs ist weil der Inhalt wichtig, werden Leute die
> beides nicht haben, ausgelassen.
> Wenn man best-effort machen möchte, kriegt derjenige seine Mail halt im
> Klartext.
> Damit stellt man sicher dass so viel wie möglich verschlüsselt wird.
>
Du schlägst also genau das vor, was zum Tot der eMail Verschlüsselung geführt hat? Oder besser gesagt, dessen Verbreitung. Unpraktische Insellösungen. Die am Ende nur dazu führen, das man gar nicht mehr verschlüsselt.

> Dafür hat man gemeinsame Standards die auch woanders unabhängig
> implementiert werden können
> mit eventuell anderer Software.
> TLS, IMAP,SMTP, POP3, PGP, S/Mime, alles schön in RFCs standardisiert.
>
Sie sind aber nicht Teil des Mail Systems. Vor allem gibt es für die Kommunikation mit der Gegenstelle nur ein einziges Protokoll. Nämlich SMTP.

> > PS:
> > Die Idee über die DNS Schiene hab ich wieder verworfen. Auch wenn sie in
> > erster Instanz wie prädestiniert dafür erscheint, gibt es gleich mehrere
> > Probleme.
>
> Es ist noch nicht mal als Experimental verabschiedet, man muss sehen wie
> groß die Probleme in der Praxis
> sein werden und wo man gegebenenfalls nachbessern muss.
> Aber dazu muss man es mal ausprobieren.
>
Man brauch keinen experimentellen Code für eine Lösung schreiben, die offensichtliche Probleme hat. Dabei stechen 3 Probleme hervor. Erstens, bietet DNS keine Authorisierung und auch keine ACL's um auf die DNS Datenbank zugreifen zu können. Und zweitens, steht es in den Sternen wann die anderen DNS Server ihre Einträge aktualisieren. Denn ein DNS Server hat nicht alle anderen in seiner Notification List und es ist auch nicht zwingend vorgeschrieben das die anderen DNS Server nach der eingetragenen TTL gehen. Und zu guter Letzt, das dritte Problem. Die Schlüssellänge. Das gibt schon bei DKIM Probleme. Denn die Textlänge im DNS ist beschränkt und erlaubt daher keine langen Schlüssel. Welche aber für eine sichere Verschlüsselung nötig ist.

Mal ganz davon abgesehen das sich DNSSEC nicht durchgesetzt hat.

[ikhaya]

tingelchen schrieb:
--------------------------------------------------------------------------------

> Keine besonders Adäquate Lösung. Dann gammeln im Postfach am Ende mehrere
> hundert gleiche Schlüssel herum.

Ich sehe da keinen Unterschied zu Signaturen epischer Länge und angehängten Logos
und Mails mit Bildern als Newsletter im HTML-Format, so sie nicht extern geladen werden.
Das ist simpler Text der nur unwesentlich mehr Speicherplatz beansprucht.
Wenn ich von jemand schon verschlüsselte E-Mails erhalten habe, braucht mein
Mailprogramm den Schlüssel nicht mehr anzuhängen.
Wenn ich den Schlüssel meines Gegenübers importiert habe kann mein Mailprogramm
den Anhang natürlich auch entfernen, da er seine Schuldigkeit getan hat.

> Und welchen? Nach welchem Standard?

Hast du ein S/Mime Zertifikat gesehen und importiert, S/Mime
Hast du einen PGP Schlüssel bekommen und gefunden PGP.
Hast du beides, PGP denn es ist unabhängig von CAs.




> Du schlägst also genau das vor, was zum Tot der eMail Verschlüsselung
> geführt hat? Oder besser gesagt, dessen Verbreitung. Unpraktische
> Insellösungen. Die am Ende nur dazu führen, das man gar nicht mehr
> verschlüsselt.

Solange nur wenige Verschlüsseln hast du logisch Inseln.
Ist es unpraktisch wenn man Versand,Import und Verwendung der Schlüssel
automatisch macht?


> Sie sind aber nicht Teil des Mail Systems. Vor allem gibt es für die
> Kommunikation mit der Gegenstelle nur ein einziges Protokoll. Nämlich
> SMTP.

Mag sein aber sie gehören zum Thema verschlüsselte E-Mails definitiv dazu.


> Dabei stechen 3 Probleme hervor.

>Erstens,
> bietet DNS keine Authorisierung und auch keine ACL's um auf die DNS
> Datenbank zugreifen zu können.

Du willst doch das dir jeder verschlüsselte Mails schreiben kann.
Wozu also Zugriffsrechte?

> Und zweitens, steht es in den Sternen wann
> die anderen DNS Server ihre Einträge aktualisieren. Denn ein DNS Server hat
> nicht alle anderen in seiner Notification List und es ist auch nicht
> zwingend vorgeschrieben das die anderen DNS Server nach der eingetragenen
> TTL gehen.

Wenn mein System beim Versand veraltete Daten bekommt, wo noch kein Schlüssel eingetragen ist
verzögert das den Schlüsselaustausch halt um eine Mail. Das wäre auch kein Drama.

>Und zu guter Letzt, das dritte Problem. Die Schlüssellänge. Das
> gibt schon bei DKIM Probleme. Denn die Textlänge im DNS ist beschränkt und
> erlaubt daher keine langen Schlüssel. Welche aber für eine sichere
> Verschlüsselung nötig ist.

Wenn ich mir https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-12#page-10
ansehe scheint das lösbar zu sein.
TCP und Schlüssel ohne Schnickschnack wie Bilder scheinen da eine brauchbare Lösung zu sein
um Ressourcen zu sparen.
Von einer maximalen Länge für DNS die sich negativ auf nutzbare Schlüssellängen auswirkt hab ich noch
nichts gefunden.
Elliptische Kurven würden in Zukunft auch da helfen, sollte das ein ernsthaftes Problem werden.

> Mal ganz davon abgesehen das sich DNSSEC nicht durchgesetzt hat.
Noch nicht.

http://www.heise.de/newsticker/meldung/Abhoersicherheit-Web-de-sichert-Mail-Transport-zusaetzlich-per-DANE-ab-3175333.html

Das geht zwar langsam voran, aber vor allem große Unternehmen machen da viel aus.