#efail

[lst_hoe02 at kwsoft.de]

Zitat von "Walter H." <walter.h at mathemainzel.info>:

> On Tue, May 15, 2018 09:03, lst_hoe02 at kwsoft.de wrote:
>>
>> Zitat von "J. Fahrner" <jf at 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.