debianforum.de

Nachdem ja jetzt PGP und S/MIME unsicher ist!!11!! und ich das hier gelesen habe: https://lists.gnupg.org/pipermail/gnupg ... 60315.html würde ich gerne mal testen ob mein Mailclient solche modifizierten Nachrichten tatsächlich erkennen würde.

Wie kann ich mir eine Nachricht zukommen lassen, die so modifiziert wurde? einen PoC Code oder so wäre ja auch schonmal nicht schlecht... So wie ich das sehe, ist da noch nix released - kommt aber vermutlich noch in den nächsten Tagen.

Du kannst dich darauf verlassen, dass der MDC funktioniert. Hab das selbst immer mal wieder auf verschiedenste Arten getestet, und bislang hat GnuPG jede noch so kleine Manipulation bemerkt. Der MDC wird auch immer zufällig über die jeweiligen Daten verteilt, und ist nicht vorhersehbar zu erkennen. Und wenn das via E-Mail testen willst, dann brauchst bspw. einen Proxy, der die Nachrichten manipuliert bevor sie dein Mailprogramm erreichen.

Die Frage ist ja nicht ob das MDC funktioniert, sondern ob der Mailclient die Warnung korrekt ausgibt. So wie ich den Fehler verstehe ist die "EFail", dass die Clients diese Warnung einfach ignorieren.

Angeblich reicht es ja einen Plaintext vor den verschlüsselten Teil zu setzen - nur sollte dann nicht eine Warnung kommen, dass nur ein Teil der Nachricht verschlüsselt / signiert ist?

Vielleicht warte ich mal bis die das Paper veröffentlichen.

reox hat geschrieben:

14.05.2018 21:22:28

Angeblich reicht es ja einen Plaintext vor den verschlüsselten Teil zu setzen - nur sollte dann nicht eine Warnung kommen, dass nur ein Teil der Nachricht verschlüsselt / signiert ist?

Um MDC zu testen, erstelle dir eine Multi-part email, verschlüssel part 1 mit dem public key, verschlüssel danach part 2 mit dem public key, schicke beide teile ab. Der empfangende Email-Client sollte dann meckern.
Einfach nur plain-text als multi-part vor oder hinter die verschlüsselte Email sollte/dürfte noch weniger funktionieren. Das wäre dann nicht EFail sondern Komplett-Versagen.

Sie haben scheinbar jetzt schon veröffentlicht. Also der Fail bei der Sache scheint dieser zu sein: Wenn man einen MIME anhang hat und davor und danach einen MIME Anhang einschleußt, welcher zusammen ein HTML Tag ergeben, dann wird der mittlere Anhang entschlüsselt und zusammen mit den anderen beiden als HTML geparsed.
Najo

edit: Hab mich ein wenig mit den multipart messages herumgespielt. Aber so ganz komm ich noch nicht an Ziel. Die Nachricht schaut jetzt so aus: mutt sagt beim aufmachen der Nachricht dann das hier: unten steht aber weiterhin "Rufe PGP auf...".
Die Inhalte der Nachrichten stimmen soweit.

reox hat geschrieben:

14.05.2018 21:22:28

So wie ich den Fehler verstehe ist die "EFail", dass die Clients diese Warnung einfach ignorieren.

Das eigentliche Problem liegt nicht direkt in den Emailprogrammen, sondern in heutzutage ungenügenden kryptographischen Standards. Insbesondere S/MIME bietet überhaupt keine Authentifizierung von Daten, womit hier bei Manipulation mangels Wissen darüber, erst garnichts gemeldet werden kann. Somit wird einfach entschlüsselt wie es reinkommt. Dagegen verfügt GnuPG über den OpenPGP-Standard hinaus, über den MDC als Authentifizierung, der aber trotz Wirksamkeit ungenügend ist. Es gibt zwar eine Warnmeldung bei Manipulation, jedoch erst nach der Entschlüsselung wenn das Problem bereits existiert. Faktisch müsste verhindert werden, dass die Entschlüsselung so überhaupt möglich ist. Aber zumindest hinsichtlich des OpenPGP-Standards RFC4880, gibt es seit 2017 einen Draft zur Aktualisierung, um modernere Verschlüsselungsverfahren implementieren zu können. Und diese Standardisierung dauert eben, auch wenn GnuPG das bereits kann aber offiziell nicht nutzen darf.

Insbesondere S/MIME bietet überhaupt keine Authentifizierung von Daten,

Doch. Fast der ganze S/MIME Standard geht um Authentifizierung.
Von den 40 Seiten ursprünglichem S/MIME Standard geht gerade mal eine um Verschlüsselung.
Schon in der Einleitung heißt es:

Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to
reduce data size.

Und so ist es: Signatures stellen Authentifizierung bereit. Verschlüsslung nicht. Und wenn man das kapiert hat, ist das völlig unproblematisch.

Faktisch müsste verhindert werden, dass die Entschlüsselung so überhaupt möglich ist.

Nein. Dass manipulierte Nachrichten entschlüsselt werden können ist Feature, nicht Bug. Das rauszubauen, nur weil einige Mailprogramme zu blöd sind, damit umzugehen, dass es einen unterschied zwischen Vertrauenswürdig und Geheim gibt ist einzig und alleine ein Armutszeugnis der E-Mail Programme.

So ich habe mal ein Nachrichten erstellt.
Denke die Dateinamen sind weitestgehend selbsterklärend. Ihr müsst natürlich erst secret-key importieren, damit ihr entschlüsseln könnt.
https://nextcloud.zdv.uni-tuebingen.de/ ... cG7kjaF8sB

PS: Ich habe mir nicht die mühe gemacht den CRC anzupassen und habe den weggeschnitten. Eventuell reiche ich da noch welche mit korrekten nach.
Testet zuerst mal ob mit correct-withoutcrc alles gut läuft. Der sollte noch korrekt sein hat nur keine CRC mehr.

wanne hat geschrieben:

15.05.2018 15:43:33

Nein. Dass manipulierte Nachrichten entschlüsselt werden können ist Feature, nicht Bug. Das rauszubauen, nur weil einige Mailprogramme zu blöd sind, damit umzugehen, dass es einen unterschied zwischen Vertrauenswürdig und Geheim gibt ist einzig und alleine ein Armutszeugnis der E-Mail Programme.

Scheinbar hast das zugrundeliegende Problem noch nicht verstanden. Denn es geht hier nicht nur um die E-Mail-Clients, sondern die Verschlüsselung selbst ist das Problem, weil sie auf veralteten Verfahrensweisen der 90er basiert. Gäbe es hier eine echte AEAD-Verschlüsselung, dann wäre dieses Problem niemals aufgekommen, da eine Manipulation dieser Art ausgeschlossen wäre. Das hier nun an mehreren Ecken ausgebessert werden soll, ist letztlich nur Flickwerk, während eigentlich der S/MIME und OpenPGP-Standard aktualisiert werden muss. Ich finde auch nicht das es ein Feature ist, wenn verschlüsselte Daten so entschlüsselt werden. Im Gegenteil, für mich ist das fahrlässig, da offenkundig defekte Daten verworfen werden sollten, was bspw. bei Krypto-Messengern gängige Praxis ist.

Schau dir das hier mal genau an:
https://efail.de

breakthewall hat geschrieben:

15.05.2018 19:38:22

Schau dir das hier mal genau an:
https://efail.de

Habe ich. Kurz zusammen gefasst:
Wir haben ein paar Bugs in HTML-E-Mail Programmen gefunden. Da es davon aber Zig pro Jahr gibt und wir Aufmerksamkeitsgail sind behaupten wir mal, dass wir PGP gebrochen haben. Das können wir zwar im geringsten ist aber scheiß egal, weil die Presse eh nur die Überschrift übernimmt. Scheiß egal, wieviel Wahrheit drin steckt.

breakthewall hat geschrieben:

15.05.2018 19:38:22

Denn es geht hier nicht nur um die E-Mail-Clients, sondern die Verschlüsselung selbst ist das Problem,

Ne. Die funktioniert wie intendiert. Verschlüsslung garantiert Geheimhaltung, Signaturen Authentizität. Ob das jetzt irgend welche Kinder (nach den 90ern geboren) nicht mehr verstehen ist völlig Wurst. Genau so wenig wie ein Waschbrett ist ja auch nicht kaputt ist, weil heutige Kinder nicht mehr wissen wie man es bedient.

breakthewall hat geschrieben:

15.05.2018 19:38:22

weil sie auf veralteten Verfahrensweisen der 90er basiert.

Sorry, aber ich will Verschlüsslung haben, die etwas länger als 10 Jahre hält. Das ist für PGP der Fall. Völlig egal was heute üblich ist. Guck es dir doch an. Weder Mutt noch Sylpheed noch sonst irgend ein Programm aus der passenden Zeit hat ein Problem. Wenn irgend welche Solcial/Web sonstwas Programme ein Problem haben, dann ist das einzig und alleine ihr Problem.

breakthewall hat geschrieben:

15.05.2018 19:38:22

Gäbe es hier eine echte AEAD-Verschlüsselung, dann wäre dieses Problem niemals aufgekommen, da eine Manipulation dieser Art ausgeschlossen wäre.

Nein. Die aller meisten Angriffe würden auch mit AEAD-Verschlüsselung funktionieren. Sie währen möglicherweise nur etwas leichter zu beheben. Lediglich der wesentlich komplexere CFB Gadget Attack Teil wäre dadurch behoben worden. IMHO ist das auch der einzige Grund eine derartig komplexe Attacke in das Paper eingebaut zu haben. Damit man eine hat, die durch andere Verschlüsselung verhindert worden wäre.

breakthewall hat geschrieben:

15.05.2018 19:38:22

Das hier nun an mehreren Ecken ausgebessert werden soll, ist letztlich nur Flickwerk, während eigentlich der S/MIME und OpenPGP-Standard aktualisiert werden muss.

Ne. Frikelwerk ist, wenn die Verschlüsselung unterbinden soll, dass der E-Mail Client (der den Schlüssel besitzt) die entschlüsselten Daten kopiert. Das ist absoluter Nonsens.
Das war es schon zu DVD-CSS Zeiten und wird es immer bleiben. – Egal wie viele Leute danach schreien.

breakthewall hat geschrieben:

15.05.2018 19:38:22

Ich finde auch nicht das es ein Feature ist, wenn verschlüsselte Daten so entschlüsselt werden. Im Gegenteil, für mich ist das fahrlässig, da offenkundig defekte Daten verworfen werden sollten, was bspw. bei Krypto-Messengern gängige Praxis ist.

Ich weiß, dass es unter Mobieltelefonnutzern üblich ist zu meinen, dass weniger Funktionalität besser ist und dass anderes Verhalten unbedingt unterbunden werden muss. Ich werde das auch weiterhin für absoluten Quatsch halten. Sorry, dafür bin ich zu alt. Vielleicht habe ich da nur zu viel Propaganda gegen Diktatoren abbekommen.
GnuPG sagt, im Zweifelsfall, dass die Mail (möglicherweise) verfälscht wurde. Das ist schlicht korrekt. Dass nur die Wahrheit nicht ausreichen soll sondern man auch noch nur möglicherweise falsche Inhalte unbedingt vernichten muss kann ich nicht verstehen. Ist nicht meine Welt. Vielleicht würde ich das, wenn ich 1933 Student gewesen wäre. Aber dazu bin ich wiederum zu jung.