Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem werden, oder? https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4...
LG Jochen
Am 14.05.2018 um 17:46 schrieb J. Fahrner:
Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem werden, oder? https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4...
LG Jochen
hm grad erst eingelesen.. ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle", ich stell mir das erstmal so vor, der Boese will doch nicht entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation feststellen koennen.
Der wesentliche Punkt ist also erstmal die Uebermittlung und Speicherung der Mail muss moeglichst sicher sein. Das immer sicherzustellen ist per se schon gar nicht so einfach. Beim Transport sollte dann dane state of the art sein, aber bei den Mail clients wird dann schon haarig. Thunderbird und die neueste Enigmailversion mit gpg "sollen" halbwegs gepatched sein.
In jedem Fall keine guten Nachrichten, aber wenn man genau nachliest nun auch nicht wirklich so ueberraschend. Zufrieden mit smime/gpg usw konnte man schon frueher nicht sein aber auf den anderen Seite ich sehe keine grundsaetzlich bessere Idee/Verfahren. Die Berichterstattung empfinde ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach nicht mehr zu retten"
Best Regards MfG Robert Schetterer
On 14.05.2018 18:32, Robert Schetterer wrote:
Am 14.05.2018 um 17:46 schrieb J. Fahrner:
Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem werden, oder? https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4...
LG Jochen
hm grad erst eingelesen.. ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle", ich stell mir das erstmal so vor, der Boese will doch nicht entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation feststellen koennen.
das Einfügen der beiden Teile vor und nach dem BASE64 Datenstrom? wobei ich hier mir die Frage stelle, wieso soll ein Mailer hier ein HTML rendering anwerfen, wo es doch darum geht den BASE64 Datenstom unverschlüsselt darzustellen? zumindest das sagt der MIME-Type im Header aus(!)
Die Berichterstattung empfinde ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach nicht mehr zu retten"
das ist Heise mittlerweile auf Bild-Niveau ...
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
On 14.05.2018 21:59, J. Fahrner wrote:
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
soferne die DKIM-Signatur dies erfasst, weil anscheinend ja nur im Mail-Body etwas hinzugefügt wird;
schlimmer finde ich ein ganz anderes Szenario, da er ja die verschlüsselte Mail im Original hat, hat er auch den Public Key des Empfängers, und damit kann er dann den kompletten verschlüsselten Inhalt durch was anderes ersetzen - Malware z.B. - und das hebelt dann sämtliche Mechanismen am Transport aus - da ja verschlüsselt; und der Client kann - schlampig wie sie alle implementiert sind - macht weiß Gott was damit ...
DKIM-Signatur hin oder her, ein Mail Client der hier irgendwas anderes macht als einen Fehler auszugeben ist kompletter Pfusch;
Am 2018-05-15 05:23, schrieb Walter H.:
schlimmer finde ich ein ganz anderes Szenario, da er ja die verschlüsselte Mail im Original hat, hat er auch den Public Key des Empfängers, und damit kann er dann den kompletten verschlüsselten Inhalt durch was anderes ersetzen
Nur, wenn der Empfänger seinen Key auf einen Keyserver hochgeladen hat. In der Mail ist der nicht enthalten. Keys von Keyservern holen kann aber jeder, dazu muss er nicht als man-in-the-middle eine Mail abfangen und manipulieren. Und Mail signieren kann er überhaupt nicht, dazu bräuchte er den private key des Senders.
On Tue, May 15, 2018 08:06, J. Fahrner wrote:
Am 2018-05-15 05:23, schrieb Walter H.:
schlimmer finde ich ein ganz anderes Szenario, da er ja die verschlüsselte Mail im Original hat, hat er auch den Public Key des Empfängers, und damit kann er dann den kompletten verschlüsselten Inhalt durch was anderes ersetzen
Nur, wenn der Empfänger seinen Key auf einen Keyserver hochgeladen hat. In der Mail ist der nicht enthalten. Keys von Keyservern holen kann aber jeder, dazu muss er nicht als man-in-the-middle eine Mail abfangen und manipulieren. Und Mail signieren kann er überhaupt nicht, dazu bräuchte er den private key des Senders.
das ist ja das schöne, wenn der Böse als Man-in-the-Middle das veranstaltet, dann kommt die Mail eben bei Dir so an, wie wenn ich sie verschickt hätte ... (er beschädigt in 90% der Fälle die DKIM Signatur eben nicht) und signieren braucht er die Mail auch nicht ...
Zitat von "J. Fahrner" jf@fahrner.name:
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
Jede Form der Integritätssicherung die auch sinnvoll verwendet wird umgeht das Problem. Der eigentliche Fail liegt aber im verwenden von HTML und dem nachladen externer Inhalte. Wer sowas macht braucht sich auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
On Tue, May 15, 2018 09:03, lst_hoe02@kwsoft.de wrote:
Zitat von "J. Fahrner" jf@fahrner.name:
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
Jede Form der Integritätssicherung die auch sinnvoll verwendet wird umgeht das Problem.
leider nicht;
Der eigentliche Fail liegt aber im verwenden von HTML und dem nachladen externer Inhalte.
Nein, sondern in der schlampigen Implementierung; wie kommt ein Mail client auch nur annähernd auf die Idee, obwohl im Header eindeutig im MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an statt einen Fehler auszugeben ...
Wer sowas macht braucht sich auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
nicht wirklich;
Zitat von "Walter H." walter.h@mathemainzel.info:
On Tue, May 15, 2018 09:03, lst_hoe02@kwsoft.de wrote:
Zitat von "J. Fahrner" jf@fahrner.name:
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
Jede Form der Integritätssicherung die auch sinnvoll verwendet wird umgeht das Problem.
leider nicht;
Der eigentliche Fail liegt aber im verwenden von HTML und dem nachladen externer Inhalte.
Nein, sondern in der schlampigen Implementierung; wie kommt ein Mail client auch nur annähernd auf die Idee, obwohl im Header eindeutig im MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an statt einen Fehler auszugeben ...
Wer sowas macht braucht sich auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
nicht wirklich;
Multipart MIME erlaubt alles mögliche. Der Angreifer kann auch ohne Problem die ganze E-Mail nochmal verschlüsseln, das kann JEDER der den öffentlichen Schlüssel hat. Das Problem besteht darin das externe Inhalte nachgeladen werden obwohl eine verschlüsselte E-Mail nicht vertrauenswürdiger ist als eine beliebige Spam E-Mail. Erst eine gültige Signatur wäre ein Grund für zusätzliches Vertrauen. Jeder der keine externen Inhalte zulässt ist von diesem Problem NICHT betroffen.
On Tue, May 15, 2018 11:57, lst_hoe02@kwsoft.de wrote:
Zitat von "Walter H." walter.h@mathemainzel.info:
On Tue, May 15, 2018 09:03, lst_hoe02@kwsoft.de wrote:
Zitat von "J. Fahrner" jf@fahrner.name:
Am 2018-05-14 18:32, schrieb Robert Schetterer:
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the middle",
Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
Jede Form der Integritätssicherung die auch sinnvoll verwendet wird umgeht das Problem.
leider nicht;
Der eigentliche Fail liegt aber im verwenden von HTML und dem nachladen externer Inhalte.
Nein, sondern in der schlampigen Implementierung; wie kommt ein Mail client auch nur annähernd auf die Idee, obwohl im Header eindeutig im MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an statt einen Fehler auszugeben ...
Wer sowas macht braucht sich auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
nicht wirklich;
Multipart MIME erlaubt alles mögliche.
stimmt, im Mail-Header steht aber das
MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64
Zitat von "Walter H." walter.h@mathemainzel.info:
stimmt, im Mail-Header steht aber das
MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64
https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-ma...
Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
On Tue, May 15, 2018 12:34, lst_hoe02@kwsoft.de wrote:
Zitat von "Walter H." walter.h@mathemainzel.info:
stimmt, im Mail-Header steht aber das
MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64
https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-ma...
Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;
Zitat von "Walter H." walter.h@mathemainzel.info:
On Tue, May 15, 2018 12:34, lst_hoe02@kwsoft.de wrote:
Zitat von "Walter H." walter.h@mathemainzel.info:
stimmt, im Mail-Header steht aber das
MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64
https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-ma...
Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;
Es geht darum das man entweder die MIME Struktur ändert wenn der Mailclient das toleriert oder das man direkt den verschlüsselten Teil "ergänzt", was durch CBC wohl möglich ist *ohne* das die Struktur ungültig wird. D.h. das Argument das es *nur* ein Fehler im Mailclient ist der die kaputte MIME Struktur akzeptiert ist falsch. Es ist ein Fehler das man extern (HTML) Inhalte zulässt, aber das war schon immer ein Fehler.
On Tue, May 15, 2018 15:06, lst_hoe02@kwsoft.de wrote:
Zitat von "Walter H." walter.h@mathemainzel.info:
On Tue, May 15, 2018 12:34, lst_hoe02@kwsoft.de wrote:
Zitat von "Walter H." walter.h@mathemainzel.info:
stimmt, im Mail-Header steht aber das
MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64
https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-ma...
Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;
Es geht darum das man entweder die MIME Struktur ändert wenn der Mailclient das toleriert
sagte ja Bug ..., es darf auch ein Fehler geliefert werden ...
D.h. das Argument das es *nur* ein Fehler im Mailclient ist der die kaputte MIME Struktur akzeptiert ist falsch.
Nein das ist der Bug schlechthin;
Es ist ein Fehler das man extern (HTML) Inhalte zulässt, aber das war schon immer ein Fehler.
das kommt davon, wenn Mail clients aus Browsern herausgewachsen sind; kritischer als das ist die Tatsache, daß ein Mail auch ausführbare Skripte enthalten kann ...
Am 2018-05-14 18:32, schrieb Robert Schetterer:
Die Berichterstattung empfinde ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach nicht mehr zu retten"
Heise scheint da tatsächlich etwas zu übertreiben. https://blog.fefe.de/?ts=a4076a8a
participants (5)
-
J. Fahrner -
lst_hoe02＠kwsoft.de -
Robert Schetterer -
Walter H. -
Walter H.