Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

TBone
19.05.2018 14:27:15
k.osmo schrieb:

Entweder liegt der Schadcode bei mir, beim Absender oder bei einem Provider, sonst gäbe es keinen Zugang zu den Mails.

Doch. Es gibt MTAs, die überhaupt keine Verschlüsselung unterstützen (oder nur Schwache) und dann gibt es eine Menge Anbieter, welche Zertifikate nicht prüfen und damit anfällig für MITM sind, dafür muss auf keinem der genannten Systeme Schadcode sein. Abgesehen davon muss zur Herausgabe der Mails seitens eines der Provider kein Schadcode vorhanden sein, eine gewisse Sklavenmentalität reicht dazu schon aus. (oder kriminelles Potential)
https://de.ssl-tools.net/providers

k.osmo schrieb:

Saubere Quellen und Senken, genauso der Transportweg bleiben entscheidend, Verschlüsselung hin oder her. Genau darauf weist EFAIL hin.

Es weißt darauf hin, dass einige Mail-Clients schwachsinnig Implementiert sind und das XOR einfach auszunutzen ist (was davor schon bekannt war). GPG ist ja dazu gedacht, dass ich eben dem Transportweg (inkl Provider) nicht vertrauen muss.

k.osmo
18.05.2018 16:13:03

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.

TBone
17.05.2018 16:45:09
k.osmo schrieb:

Nun, klar. Wie kommt der Schadcode auf die Platte?

Was meinst du denn mit Schadcode? Den img-Tag?
Eventuell speichert dein Mail-Client die e-Mail auf deiner Platte, das macht aber überhaupt keinen Unterschied, ob er es nun speichert oder nicht.

k.osmo
17.05.2018 15:27:03
TBone schrieb:
k.osmo schrieb:

Wozu 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
16.05.2018 18:14:09
Kabbone schrieb:

@TBone: ehrlich gesagt ist mir auch nicht ganz klar auf was du hinaus willst. Ich tippe auf unterschiedliche Interpretation der Ausdrucksweise big_smile

Das war auch mein erster Eindruck.

Kabbone schrieb:

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

Genau, es bezieht sich aber auf alle Mitschnitte, auch aktuelle.

stefanhusmann schrieb:

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.

Nein, diese Analogie ist falsch.
Korrekter wäre:
"Angenommen es regnet nie. Wozu brauch ich dann Regenschirme. Es regnet ja nie. Ergo brauche ich keine Regenschirme."

Ich sage nicht, es ist eine sinnvolle Annahme, dass es nie regnet, ich sage nur, gegeben dieser Annahme. Falls es nicht nur dagegen schützt, wogegen schützt es denn dann noch? (Abgesehen von der Signierung, von dieser ist hier aber keine Rede.)

k.osmo schrieb:

Wozu braucht's des überhaupt?

Spam ergibt ohne HTML-Rendering meistens keinen Sinn.


Edit:

Wer ein Problem mit der Aussage hat, kann das gerne mit jemand anderem diskutieren. e-Mail findet ihr hier: https://efail.de/imprint.html
Sagt einfach, ihr bezieht euch auf folgenden Absatz:

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!

k.osmo
16.05.2018 15:18:03

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?

stefanhusmann
16.05.2018 14:23:51

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.

Kabbone
16.05.2018 14:00:46

@TBone: ehrlich gesagt ist mir auch nicht ganz klar auf was du hinaus willst. Ich tippe auf unterschiedliche Interpretation der Ausdrucksweise big_smile

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?

TBone
16.05.2018 13:40:53
schard schrieb:

@TBone
Du weist offensichtlich nicht, wie E-Mail und / oder PGP/GPG funktionieren.

Nein, du bist dumm11elf (Ich meine mit dieser Aussage, bitte begründe doch, was du meinst)

TBone schrieb:

GPG soll ja genau davor schützen, dass es jemand mitschneidet.

Okay, ich korrigiere mich: Es soll verhindern, dass jemand den Plaintext mitschneidet. Ich meine natürlich nicht, dass auf magische Weise keine Bits verschickt werden.

schard
16.05.2018 11:04:42

@TBone
Deine Schlussfolgerung ist unsinnig.
Du weist offensichtlich nicht, wie E-Mail und / oder PGP/GPG funktionieren.

TBone
15.05.2018 20:32:07
Schard-nologin schrieb:

@TBone
Nein. Es soll davor schützen, dass jemand den Inhalt mitlesen kann.

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. (Ja, ich meine damit auch, dass der Mail-Provider nicht darauf zugreifen kann)

Schard-nologin
15.05.2018 18:41:01

@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
15.05.2018 18:15:20
Kabbone schrieb:

ok, das macht natürlich Sinn, ist aber dann auch nicht allein mit der gefundenen Sicherheitslücke umsetzbar.

Sind Mitschnitte vorhanden: Ja, es ist alleine damit möglich. GPG soll ja genau davor schützen, dass es jemand mitschneidet.

TBone
15.05.2018 18:14:47
schard schrieb:

Die müsste der Angreifer dann aber erneut dem Opfer zuspielen, da nur das Opfer die E-Mails entschlüsseln kann.

Einfach von einem beliebigem Mail-Accout manipulieren und neu senden.

Kabbone
15.05.2018 16:47:17
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.

Fußzeile des Forums

Powered by FluxBB