So, wie ich das in diversen Funktionserklaerungen ueber Efail gelesen habe, betrifft es nur HTML-Mails? Koennt ihr meine Meinung dazu teilen? Hilft natuerlich nichts, wenn der Client bereits okkupiert wurde.
  • [gelöscht]

Nicht nur. HTML verschärft das Problem nur, indem über entsprechende HTML Elemente der Klartext bei der Interpretation des HTML Texts an einen möglichen Angreifer gesendet werden kann. Das eigentliche Problem ist aber, dass sowohl S/MIME als auch PGP/GPG nicht MITM resistent sind.
Ein Angreifer kann E-Mails ändern, ohne dass dies bemerkt würde und so entsprechenden Content injizieren.
Imho ist die einzig versünftige Lösung, AEAD in PGP/GPG zu verankern.
Verdammt... und ich dachte bisher, GPG gibt eine gewisse Sicherheit, da GPG/PGP ja an sich ziemlich sicher ist.
Die meisten Mailer sind ja schon gefixt und jegliches verbieten von HTML soll die bisherigen Einfallsszenarien auch ausschließen.
Schard-nologin schrieb. Das eigentliche Problem ist aber, dass sowohl S/MIME als auch PGP/GPG nicht MITM resistent sind.
Ein Angreifer kann E-Mails ändern, ohne dass dies bemerkt würde und so entsprechenden Content injizieren.
So wie ich das verstanden habe ist es ein Problem der E-Mail-Clients. Nicht von PGP an sich.
HTML-eMails sollten seit Aufkommen der transparenten 1px-Grafiken vor etlichen Jahren ohnehin "no-go" sein...
was mir allerdings noch schleierhaft ist, ist die anfängliche Behauptung der Möglichkeit alte Nachrichten entschlüsseln zu können. Ich habe das Paper nicht gelesen, aber der in den News gezeigte poc kann doch lediglich die entschlüsselte Nachricht zeigen, aber nicht den Schlüssel an sich preisgeben.
@Kabbone:
Dies bezieht sich auf die Voraussetzung, dass jemand das entsprechende E-Mail Konto gehackt hat.
Dann kann der Angreifer gespeicherte Nachrichten im Postfach nachträglich so manipulieren, dass diese über den HTTP Exploit bei der Anzeige im verwundbaren E-Mail Client entschlüsselt werden.
TBone schriebOder jemand hat alte Mitschnitte, als Mails noch nicht mit SSL versendet wurden. (Gibt es heute noch)
Die müsste der Angreifer dann aber erneut dem Opfer zuspielen, da nur das Opfer die E-Mails entschlüsseln kann.
schard schrieb@Kabbone:
Dies bezieht sich auf die Voraussetzung, dass jemand das entsprechende E-Mail Konto gehackt hat.
Dann kann der Angreifer gespeicherte Nachrichten im Postfach nachträglich so manipulieren, dass diese über den HTTP Exploit bei der Anzeige im verwundbaren E-Mail Client entschlüsselt werden.
ok, das macht natürlich Sinn, ist aber dann auch nicht allein mit der gefundenen Sicherheitslücke umsetzbar.
  • [gelöscht]

@TBone
Nein. Es soll davor schützen, dass jemand den Inhalt mitlesen kann.
Die verschlüsselte Email abzufangen ist trivial.
Allerdings kann der Angreifer mit dem (verschlüsselten) Inhalt nichts anfangen.
@TBone
Deine Schlussfolgerung ist unsinnig.
Du weist offensichtlich nicht, wie E-Mail und / oder PGP/GPG funktionieren.
@TBone: ehrlich gesagt ist mir auch nicht ganz klar auf was du hinaus willst. Ich tippe auf unterschiedliche Interpretation der Ausdrucksweise 😃

Falls "Mitschnitte" (ich gehe mal davon aus, damit sind frühere verschlüsselte Mails gemeint) vorhanden sind, kann ich diese durch die Lücke nur ausnutzen indem sie erneut manipuliert gesendet werden (ohne aktiviertes HTML, aber auch dann nicht mehr). Du erhälst ja durch die Lücke nicht den private Key, sondern "nur" den in der manipulierten Mail enthaltenen Plaintext (also zzgl. evtl. enthaltener Gesprächsverläufe).
Gibt es bis dahin Unterschiede unserer Auffassungen?
Angenommen, niemand ist in der Lage, die e-Mail mitzuschneiden. Wozu brauche ich dann die Verschlüsselung? Die Daten sind ja eh nie in anderen Händen. Ergo, es schützt davor, dass jemand die Mail mitschneidet.
Aristoteles meint dazu: Angenommen es regnet nie. Wozu brauch ich dann Regenschirme. Es regnet ja nie. Ergo verhindern Regenschirme den Regen.
Hauptsache Schirm, egal ob's regnet oder brennt. Kann ja z. B. auch 'ne ~Mütze sein (Brillenträger wissen mehr)…

Sokratische Schlussfolgerung: HTML-Rendering abschalten, und gut is' erstma'. :cool: Wozu braucht's des überhaupt?
TBone schrieb
k.osmo schriebWozu braucht's des überhaupt?
Spam ergibt ohne HTML-Rendering meistens keinen Sinn.
Spam bleibt SPAM; wenn da ein Sinn sein soll, war's wohl als Witz gedacht. edit: Oder meintest Du doch die Spamfilter?
No. The EFAIL attacks require the attacker to have access to your S/MIME or PGP encrypted emails. You are thus only affected if an attacker already has access to your emails. However, the very goal of PGP or S/MIME encryption is the protection against this kind of attacker. For those users who rely on PGP and S/MIME encryption, the EFAIL attacks may be a big deal!
Nun, klar. Wie kommt der Schadcode auf die Platte?
TBone, ich betone dein Zitat (edit) aktuell (/edit) so:
No. The EFAIL attacks require the attacker to have access to your S/MIME or PGP encrypted emails. You are thus only affected if an attacker already has access to your emails. However, the very goal of PGP or S/MIME encryption is the protection against this kind of attacker. (…)
Entweder liegt der Schadcode bei mir, beim Absender oder bei einem Provider, sonst gäbe es keinen Zugang zu den Mails. Saubere Quellen und Senken, genauso der Transportweg bleiben entscheidend, Verschlüsselung hin oder her. Genau darauf weist EFAIL hin. Verschlüsselung macht den Unterschied zwischen Brief und Postkarte. Schon wenn mir Eines (lies: eine Person; aber auch: ein Programm) beim Schreiben zusieht, ist es ein Leak.