GnuPG verschärft Integritäts-Checks

Danke an Werner Koch und das Team!

Feine Sache, nur leider wird es wohl noch zwei Jahre dauern, bis diese Version in den gängigen Linux-Versionen ankommt. Bei mir ist auf zwei verschieden Ubuntu-Derivaten (Mint 18.3, Ubuntu Mate 16.04) gnupg 2.1.11 installiert.

Die 1.4er Version bekam gerade ein Update auf 1.4.20, die ist noch älter.

Und natürlich weiß man nicht, was die Versionsnummern wirklich bedeuten, da sie distributionsabhängig modifiziert sein können. Steht vieleicht im Changegelog...

Ich weiß, man kann gnupg selbst kompilieren, das habe ich früher aus sportlichem Ehrgeiz auch gemacht, inzwischen habe ich keine Zeit mehr für so etwas, und es ist seit Version 2.* auch komplizierter geworden. Massenkompatibel ist das jedenfalls nicht.

Paradoxe Situation, unter Windows kann ich jede beliebige Version mal eben installieren, unter Linux ist das eher den Experten vorbehalten.

Viele Grüße,

muzel

Quote from muzel

Paradoxe Situation, unter Windows kann ich jede beliebige Version mal eben installieren, unter Linux ist das eher den Experten vorbehalten.

Stimmt. Das ist eine der Tücken mit Linux. Es betrifft leider nicht nur GnuPG. Zum Glück gibt es den Großteil an Software fertig über die Distributionen oder anderen Paketquellen. Weshalb selbst die großen Distributionen u.a. bei GnuPG so hinterherhinken, ist mir nicht bekannt.

Ich bin den manuellen Weg auf die Version 2.2.7 erst kürzlich aufgrund eines anderen Themas hier im Forum gegangen. Das war aufgrund der vielen Abhängigkeiten alles andere als anwenderfreundlich. Im Vergleich zu der ohnehin schon oftmals als kompliziert empfundenen Anwendung zur E-Mailverschlüsselung ist das für manche Linuxer möglicherweise eine noch viel größere Hürde.

Der Schritt auf die 2.2.8 hingegen war dann nur noch ein Klacks. Die anderen Bibliotheken lagen durch die 2.2.7 schon in der aktuellen Version vor. Dadurch genügten die üblichen drei Befehle configure, make und make install. Insofern freue ich mich nun doch, dass ich den etwas zähen Schritt auf die 2.2.7 durchgeführt hatte.

Quote from Volker_

Wird dagegen eine Nachricht signiert & verschlüsselt, dann ist wohl MDC überflüssig.

Das ist nach meiner Kenntnis nicht korrekt. Die digitale Signatur schützt nicht vor Angriffen wie Efail. Soweit ich mich erinnere wurde das auch so kommuniziert. Der Grund ist, dass gemäß RFC 4880 folgende Reihenfolge gilt:

Signieren -> Komprimieren -> Verschlüsseln

Eine verschlüsselte und signierte Nachricht muss zunächst entschlüsselt werden, bevor die Signatur überprüft werden kann. Dann ist es im Fall von Efail bereits zu spät. Mit dem Entschlüsseln durch den E-Mailclient wird die Nachricht bereits an den Angreifer gesendet.

Es sollte auch nicht vergessen werden, dass GnuPG nicht allein der Verschlüsselung von E-Mails dient. Es gab bereits in der Vergangenheit Angriffe, die durch MDC verhindert werden können. Nicht ohne Grund wurde das bereits vor vielen Jahren in GnuPG implementiert.

Quote from Volker_

Das ist korrekt.

Gut, danke.

Nur verstehe ich dann den Rest des Einwandes nicht. In dem Moment, in dem der Mailclient und damit der Benutzer bemerkt, dass die erwartete Signatur fehlt oder gebrochen wurde, ist der entschlüsselte Text bereits an den Angreifer versendet worden.

Man kann im besten Fall bemerken, dass man angegriffen wurde. Der Angriff ist zu diesem Zeitpunkt aber schon abgeschlossen und der Angreifer am Ziel.

Die Signatur bietet keinen Schutz vor Efail. Das besagt auch das erwähnte Paper schon in der Überschrift des Abschnitts:

Quote from Volker_

Nachzulesen in efail-attack-paper.pdf, Kapitel 4.2, Abschnitt "Meaningless signatures"

Meaningless bedeutet ja soviel wie gegenstands- oder sinnlos.

Übrigens bezieht sich der erwähnte Abschnitt auf S/MIME und nicht auf GnuPG, was in diesem Fall aber keine Rolle spielt.

Um zur Eingangsthese zurückzukehren: Sie ist nicht richtig. MDC ist nicht überflüssig, auch dann nicht, wenn eine E-Mail signiert wurde.

Quote from Volker_

Vielleicht ist doch PGP/INLINE sicherer, da i.d.R. kein Automatismus im E-Mail Programm abläuft.

Bei PGP/INLINE werden HTML-Inhalte normalerweise nicht interpretiert. Das bietet einen gewissen Schutz. Jedoch war zu lesen, dass das Deaktivieren aktiver Inhalte allein möglicherweise nicht genügt, weil verfeinerte Angriffe denkbar seien.

Wer nach heutigem Stand sicher sein will oder es gar muss, der kann dies nur erreichen indem er die aktuellen Versionen von Enigmail und GnuPG sowie MDC-konforme Schlüssel verwendet.

Quote from Volker_

Mein Einwand bezieht sich darauf, dass durch die fehlende Signatur der E-Mail Empfänger gewarnt wird.

Worauf bezieht sich dieser Einwand? Damit ob MDC sinnvoll ist oder nicht, hat das nichts zu tun. Ich gehe zurück zu Beitrag #5, weil dort die Aussage steht, um die es ging:

Quote from Volker_

Naja, irgendwie wird MDC überschätzt. Wenn eine Nachricht NUR verschlüsselt wird, dann macht MDC Sinn.

Wird dagegen eine Nachricht signiert & verschlüsselt, dann ist wohl MDC überflüssig.

Zum ersten Teil der Aussage sind wir uns nach meinem Verständnis inzwischen einig. Eine Signatur schützt nicht vor Efail. Im besten Fall erhält man einen Hinweis, nachdem es schon zu spät ist.

Kommen wir zum zweiten Teil.

Nein, MDC ist nicht überflüssig. Es schützt selbst dann, wenn der MDC vom Angreifer entfernt wurde, weil GnuPG und Enigmail in den neuen Versionen dann die Entschlüsselung der E-Mail hart verweigern.

Damit schließt sich der Kreis in diesem Thread, denn das ist gerade die Neuerung, um die es in diesem Thread geht. Ich zitiere aus dem eingangs verlinkten Artikel:

Quote

Allerdings erzeugte das Fehlen von MDCs bei früheren GnuPG-Versionen nur Warnungen, die viele Programme beziehungsweise Anwender ignorierten. Außerdem gab es, wenn alte Schlüssel zum Einsatz kamen, einen automatischen Fallback auf Verschlüsselung ohne MDC, was unter Umständen Downgrade-Angriffe ermöglicht. Ab GnuPG 2.2.8 ist damit Schluss: "Entschlüsselung von Nachrichten ohne MDC führt nun zu einem harten Fehler" und "MDC wird jetzt immer genutzt" erklärt der Entwickler Werner Koch ...

Das bedeutet, MDC ist nicht überflüssig, wie oben behauptet, sondern es leistet genau das, was eine Signatur in diesem Fall nicht vermag. Es verhindert einen Angriff durch Efail und ähnlichen Attacken.

MDC ist zunächst einmal ein Hash. Wie bei jedem Hash muss der zuvor ge-hashte Inhalt verfügbar gemacht werden, um den Hash-Wert überprüfen zu können. Das liegt in der Natur der Sache. Dies kann lokal im Speicher geschehen oder in Form einer Datei, die im Fehlerfall gelöscht wird, noch bevor sie einem anderen Prozess zur Verfügung steht.

Das bietet theoretische Angriffsmöglichkeiten wenn die Ausgabe ge-piped ist oder ein Angriff direkt auf den Speicher oder gelöschte Files auf der Festplatte geführt werden kann.

Im Falle des Pipings benötigt es deshalb auch entsprechende Maßnahmen beim Client.

Für GnuPG schreibt Werner Koch dazu:

Quote

When giving a filename on the command line an output file is even not reated. This can't be done in pipe mode because gpg allows to process huge amounts of data. MUAs are advised to consider the DECRYPTION_FAILED status code and not to show the data or at least use a proper way to display the possible corrupted mail without creating an oracle and to inform the user that the mail is fishy.

Hier kommt Enigmail ins Spiel. Wenn kein MDC vorhanden ist oder GnuPG einen Fehler festgestellt hat, dann wird der entschlüsselte Text nicht mehr an Thunderbird zur weiteren Bearbeitung übergeben, selbst wenn er ge-piped war. Somit gelangt ein aktiver Inhalt nicht zur Ausführung.

Soweit mein Wissen dazu. Ich habe keine Kenntnis darüber, wie das genau in GnuPG und Enigmail implementiert wurde. Ich habe aber volles Vertrauen darin, dass die Aussagen beider Entwickler-Teams nach besten Wissen und Gewissen korrekt sind: Mit dem strickten Vorgehen in GnuPG 2.2.8 und Enigmail 2.0.7 ist der Anwender vor Efail Angriffen geschützt.

Ja, das war ein Tippfehler. Es geht in diesem gesamten Thread um die 2.2.8. Danke für den Hinweis. Ich korrigiere es oben.