Was ich vermisse:

[Missingno.]

Eine Auflistung der (bekanntesten) Clients und inwieweit sie von Efail betroffen sind (oder nicht). (Als Nutzer von The Bat!/Claws bin ich wohl allen Anschein nach relativ sicher.)

--
Dare to be stupid!

[My1]

mailvelope ist gegen die attacke mit mehreren teilen schonmal sicher da der PHP sehr stark isoliert wird. wegen manip vom ciphertext weiß ichs grad net.

Asperger inside(tm)

[Anonymer Nutzer]

mailvelope hat mit php nichts zu tun. es ist ein plugin für den browser. außerdem ist es nur deshalb sicher, weil es das gleiche tut wie gnupg: er verlangt zwingend einen mdc bei aes. würde es dies nicht tun, wäre es genauso anfällig wie andere clients.

man lese dazu bitte die aussagen der entwickler von mailvelope zu back channels unter https://www.mailvelope.com/en/blog/implications-efail-on-mailvelope etwas weiter unten.
ich zitiere: "Mailvelope does not block external resources loaded in HTML emails. As a result there is a general problem with leaking meta data. This is a known issue in Mailvelope and we are planning to block external resources in HTML emails by default and make loading only optionally available."
was also den datenschutz anbelangt, sit mailvelope aktuell wohl nicht zu empfehlen.

die frage, wie sicher gpg im browser allgemein ist, ist zusätzlich eine schwere. ich persönlich vertraue meinem browser, der nun doch angriffsziel nummer eins ist, keine gpg schlüssel an. aber das ist definitiv eine meinung.

[My1]

von H ein buchstabe nach links ist G. typischer tippfehler.

dazu hilft MDC nicht gegen die mime-level angriffe. und da hilft eine isolierung des PGP parts.

Asperger inside(tm)



1 mal bearbeitet, zuletzt am 22.05.18 19:26 durch My1.

[Anonymer Nutzer]

pgp kann unmöglich für die erste lücke verantwortlich gemacht werden. gnupg ist ein stück software, das mit der ersten lücke nicht das geringste zu tun hat. man kann weder gnupg als implementierung noch openpgp als protokoll diesen fehler von manchen email clients vorwerfen. ebenso wenig den entwicklern von gnupg. es ist nicht im geringsten ihr code.

würde man das tun, müsste man dem singal _protokoll_ auch vorwerfen, dass es eine sicherheitslücke im desktop client gab. ebenso müsste man tls vorwerfen, wenn jemand eine software schreibt und den rückgabewert einer funktion einer tls implementierung wie zb openssl ignoriert, der nicht ignoriert werden darf. und niemand würde je auf den gedanken kommen, eines der beiden dinge zu tun. bei gpg und openpgp geht dies allerdings schon, da man leider zu offensichtlich gewillt ist, hier fehler zu finden.

ich kann nur wiederholen: in welcher situation schützt mdc nicht und wo wurde hier von den gnupg entwicklern _fälschlicherweise_ angenommen, dass es schützt?

[My1]

sicher ist das kein problem von PGP selbst, aber es war auch ein bedeutender teil von efail.

Asperger inside(tm)