Hallo, eben drüber gestolpert: "Betroffen sind beide Verfahren, mit denen weltweit E-Mails verschlüsselt werden: S/Mime und PGP. Firmen verwenden in der Regel S/Mime, Aktivisten, Whistleblower und Journalisten hingegen PGP." "Geheimnisse von Konzernen weltweit, aber auch vertrauliche Botschaften, die sich Menschenrechtsaktivisten, Anwälte und Journalisten schicken: Alle diese Nachrichten könnten nun im Nachhinein entschlüsselt werden." http://www.sueddeutsche.de/digital/exklusiv-verschluesselte-e-mails-sind-nicht-sicher-1.3978608 Gruß Gustav
Warten wir erstmal auf morgen bis die Details rauskommen.
Sehe da kein großes Risiko. Es muss ein präparierte Mail an den Client, der das PW besitzt geschickt werden. Dieser muss auch noch so manipuliert werden, das er den entschlüsselten Text wieder zurückschickt. Die Verschlüsselung ist also keinesfalls geknackt, nur der Client.
Hallo Gustav, das war doch immer klar. Es gibt keine dauerhafte Sicherheit durch Verschlüsselung. Man kann bestenfalls die Hürden der Entschlüsselung in die Höhe treiben. Die Folge ist, mit ausreichender Infrastruktur und Zeit ist jede Verschlüsselung auch ohne Schlüssel zu Knacken. Wer also Interesse daran hat wird sich die passende Kundschaft akquirieren schon um die Kosten im Zaum zu halten. Das bedeutet, aber auch das parallel mit stärkerer werdender Verschlüsselung auch die Entschlüsselungsindustrie wächst. Namaste
Winne, das sind jetzt aber völlig triviale Allgemeinplätze, die zudem mit dem vorliegenden Problem herzlich wenig zu tun haben. Verschlüsselte Kommunikation bedeutet nie absolute Sicherheit, sondern nur Zeitgewinn. Das Problem, das hier zu Tage kam, hängt mit html-Mail zusammen - wenn das abgeschaltet ist, funktioniert der Trick nicht.
HTML in Mails gehört sowieso verboten. Das ist Sicherheitsrisiko Nummer 1 (für Anwender die nicht wissen wie man das abschalten kann oder Webmail benutzen wo es nicht abschaltbar ist). Im Heise Forum schrieb gerade jemand man hätte statt HTML damals auch einfach sowas wie BBcode einführen können, man hätte nie von solchen Problemen gehört. Also nicht PGP wurde geknackt, sondern es ist nur eine weitere Sicherheitslücke im Client bei der Darstellung von HTML...
ich htate mal vor eneiign Jerhan enien Text Vhrllücssseeer geribceeshn, der den Text so mchist dass er iemmr noch labser ist. Dmait stleoln auimoattcshe Turnenxtekenegn doch was zu kanbebrn heban.
Uhu U. schrieb: > Verschlüsselte Kommunikation bedeutet nie absolute Sicherheit, sondern > nur Zeitgewinn. Viele scheinen aber gerade das nicht zu erfassen und verlassen sich auch in inoportunen Situationen auf ewigen Geheimnisschutz durch Cryptotechniken. Namaste
Angehängte Dateien:
-
Screenshot.png
36 KB
Ma W. schrieb: > Markus M. schrieb: >> TextCoder.exe > > Netter Versuch. > Deinen Virus darfst du behalten. Malware.HighConfidence
Wenn der Schlüssel genau so lang ist wie der verschlüsselte Inhalt, dann kann die Verschlüsselung nicht gebrochen werden bzw. ich liefere Dir für jeden Wunschtext einen passenden Schlüssel.
Hier ist die Sache beschrieben: https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-Efail-4048873.html Doppelte Verschlüsselung dürfte den Trick auch mit eingeschaltetem HTML austricksen...
Winfried J. schrieb: > das war doch immer klar. Es gibt keine dauerhafte Sicherheit durch > Verschlüsselung. Man kann bestenfalls die Hürden der Entschlüsselung in > die Höhe treiben. Das ist m.E. nicht wahr. Meist ist das Problem ein Fehler in der Implementierung des verwendeten Verfahrens, seltener ein Problem im Verfahren selber. Ein sicheres Verfahren zu entwerfen, das auch in 200 Jahren nicht gebrochen werden wird, halte ich für ohne weiteres denkbar. Das Argument mit der größeren verfügbaren Rechenleistung ist schlicht falsch -- weil die Problemgrößen bei ordentlichen Verfahren exponentiell sind. Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die Richtung der gesamten Energieproduktion der Milchstraße für eine Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen Fehler im Verfahren gebrochen werden, und sicherlich nie durch "schnellere Rechner" oder "mehr Industrie".
:
Bearbeitet durch User
Keine Ahnung warum in der EXE ein Virus erkannt wurde, ich habe diese gerade nochmals mit dem aktuellen Lazarus übersetzt. Mein Virenscanner meldet kein Alarm.
Markus M. schrieb: > ich habe diese > gerade nochmals mit dem aktuellen Lazarus übersetzt. Mein Virenscanner > meldet kein Alarm. Netter zweiter Versuch. Leider fällt niemand darauf herein.
Sven B. schrieb: > Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur > um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo > dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die > Richtung der gesamten Energieproduktion der Milchstraße für eine > Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen > Fehler im Verfahren gebrochen werden, und sicherlich nie durch > "schnellere Rechner" oder "mehr Industrie". Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen "niemals" passieren werden...
Markus M. schrieb: > Keine Ahnung warum in der EXE ein Virus erkannt wurde Das ist ein bekanntes Problem. Wenn es ein Hello World oder ähnlich simpel ist oder mit gcc übersetzt wurde finden das die Virenskanner komisch, weil zu grosser unterschied zu durchschnittlichen Programmen. Es lebe machine learning: https://www.google.ch/amp/s/www.csoonline.com/article/3216765/security/heres-why-the-scanners-on-virustotal-flagged-hello-world-as-harmful.amp.html
Sebastian H. schrieb: > Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen > "niemals" passieren werden... Die Thermodynamik ist aber ein recht hartes Limit. Oder behauptest du, sie wäre falsch?
Hallo! Mac G. schrieb: > HTML in Mails gehört sowieso verboten. Das ist Sicherheitsrisiko Nummer 1 Sehe ich anders. Das größte Sicherheitsrisiko sitzt 60cm vor dem Bildschirm. Mac G. schrieb: > man hätte statt HTML damals auch einfach sowas wie BBcode einführen können, Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird? Im Browser ist es somit HTML. Man hätte also zusätzlich zu BBCode auch eine ganze Menge an Prüfmechanismen einbauen müssen die vor der Anzeige oder besser vor dem Absenden der Email selbige erstmal umfangreich prüfen. Und wie es immer ist liese sich auch BBCode manipulieren. Wer glaubt BBCode sei sicher ist m.E. gewaltig auf dem Holzweg. Einen nicht manipulierbaren Ersatz für HTML mit den selben Eigenschaften kann es m.E. nicht geben. Eine Möglichekeit, Sicherheit zu gewährleisten, sehe ich in der Sandbox. Bei der dem Emailclient bzw. einem HTML-Code verboten wird auf das System zuzugreifen. Oder man ändert die Art und Weise wie der HTML-Code verarbeitet wird. Gruß, René
:
Bearbeitet durch User
Sebastian H. schrieb: > Sven B. schrieb: >> Um alle Schlüssel für AES-256 durchzuprobieren braucht man, alleine nur >> um die Bits umzukippen, um den zu probierenden Schlüssel mal irgendwo >> dastehen zu haben, aus rein thermodynamischen Überlegungen sowas in die >> Richtung der gesamten Energieproduktion der Milchstraße für eine >> Milliarde Jahre. Dieses Verfahren wird nur durch einen eventuellen >> Fehler im Verfahren gebrochen werden, und sicherlich nie durch >> "schnellere Rechner" oder "mehr Industrie". > > Das es noch immer Leute in der IT gibt, die sagen, daß manche Sachen > "niemals" passieren werden... Das ist kein IT-Argument, sondern ein Thermodynamik-Argument. Das ist ein bisschen was anderes, weil ja, es wird niemals passieren, dass Rechner weniger Energie benötigen als die physikalisch vorgegebene Untergrenze. Das ist ungefähr so, wie eine Solarzelle die in der Gegend liegt nie mehr Strom liefern wird als Licht von der Sonne auf sie drauf fällt. Da sagst du ja auch nicht "ja aber der Wirkungsgrad ist von 1% auf 2%, dann von 2% auf 5%, dann auf 20%, dann auf 40% gestiegen, also sind wir in 10 Jahren bei 80% und dann bei 160%".
René H. schrieb: > Mac G. schrieb: >> man hätte statt HTML damals auch einfach sowas wie BBcode einführen können, > > Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird? "Sowas wie BBCode" heißt nicht BBCode. Eine Implementierung für Mail müsste natürlich auf dem jeweiligen Mail-Client lokal laufen...
Wer Angst hat setzt auf "Nur-Text-Mail". Das erspart Experimente und Diskussionen. Und in vielen Firmen gibt es generell keine HTML-Mails.
:
Bearbeitet durch User
René H. schrieb: > Wer Angst hat setzt auf "Nur-Text-Mail". Das erspart Experimente und > Diskussionen. Leider nicht ganz: wenn der Kommunikationspartner bei HTML bleibt, dann ist das Loch auch offen - deswegen sollte html tatsächlich dafür "verboten" werden, auch wenn das den Schlapphüten nicht gefällt.
:
Bearbeitet durch User
Ein Verbot kommt aber einer Bevormundung gleich. Man kann nicht alles gesetzlich verbieten nur weil eine Gefahr existiert. Würde man alles verbieten was gefährlich ist müssten wir wieder in Höhlen oder auf Bäumen leben. Alle Verkehrsmittel sind gefährlich, Waffen sind gefährlich, und viele Menschen sind gefährlich.
:
Bearbeitet durch User
Keiner, den es interessiert, was denn da so verschlüsselt wurde, wird darauf warten wollen bis Bruteforce in sinnvollem Zeitrahmen realisierbar ist. Die gängigstem Methoden sind daher diverse Orakel, known Plaintext, Seitenkanalattacken und die Daten dann abgreifen, wenn sie unverschlüsselt sind. Zu letzterem zählt meiner Meinung auch das aktuelle Problem. Selbst eine ideale Verschlüsselung wie das One-Time-Pad lässt sich "knacken", wenn man die Daten vor der Verschlüsselung oder nach der Entschlüsselung ausleitet. Aber damit ist nicht die Verschlüsselung geknackt, sondern die konkrete Implementierung. Aus gegebenen Anlass sollte es für die meisten Fälle reichen, keine externen Inhalte zu erlauben, was bei mir z.B. schon seit der Einrichtung eingestellt ist. Aber hundertprozentig darauf verlassen würde ich mich da auch nicht. Man könnte jetzt z.B. dem Thunderbird via Firejail und iptables alle Ports außer 465 und 995 und UDP 53 (DNS) abdrehen, allerdings muss man dann wieder Ausnahmen für den/die CalDAV und CardDAV Server einpflegen, sonst funktionieren Lightning und der SOGO-Adaper nicht mehr richtig. Am einfachsten lässt sich das Problem wohl im Mailprogramm bzw. Plugin lösen. Z.B. bei unsignierten Mails oder welchen mit ungültiger Signatur explizit nachfragen, ob entschlüsselt werden soll. In dem Fall könnte man dann Rücksprache mit dem Absender halten. Nutzer von PGP (nicht GPG) scheinen meinen Beobachtungen nach aber generell nicht zu signieren... Letztendlich bewahrheitet sich wieder einmal, dass Komfort und (richtige) Sicherheit sich diametral gegenüberliegen. Jörg
Im Übrigen wird diese Lücke auch nur wieder von den Medien aufgebauscht. Dass diese Sicherheitslücke wirklich ausgenutzt wird darf bezweifelt werden. Vor ein paar Monaten ging eine "gefährliche" Sicherheitslücke in Windows durch die Medien. Alle haben "Hilfe, Hilfe... böses Microsoft..." geschriehen. Geblieben ist davon nichts als überflüssiges Medien-Geschmiere. Und das war auch nicht der einzige Aufschrei von dem am Ende nichts blieb. Die lukrativste Sicherheitslücke ist noch immer menschliche Gier nach dem schnöden Mammon, dafür muss man keine Schlösser knacken (eine Email mit viel Geld-Versprechungen reicht), was von Betrügern auch sehr erfolgreich ausgenutzt wird.
:
Bearbeitet durch User
René H. schrieb: > Ein Verbot kommt aber einer Bevormundung gleich. Man kann nicht alles > gesetzlich verbieten nur weil eine Gefahr existiert. Du scheinst auch den feinen Unterschied zwischen "Verbot" und Verbot nicht zu kennen... Gewisse Dinge verbieten sich einfach von selbst, z.B. das Baden in einer Jauchegrube, oder das Nasebohren mit einer Hilti - dazu braucht man kein Gesetz...
René H. schrieb: > Im Übrigen wird diese Lücke auch nur wieder von den Medien aufgebauscht. > Dass diese Sicherheitslücke wirklich ausgenutzt wird darf bezweifelt > werden. Ja und nein - weil eigentlich jeder Depp angelernt werden kann, die Lücke auszunutzen, ist sie sehr gefährlich. Dass die Presseheinis sich ohne einen Funken Hintergrundwissen darüber auslassen, ist ein verbreitetes Phänomen, das in diesem Fall dem technisch gebildeten Leser klar machen sollte, dass derlei "Experten" auch zu anderen Themen im Brustton der Überzeugung großen Mist zu verzapfen pflegen und er deswegen gut daran tut, sein Hirn nicht nur im Bereich Technik einzuschalten...
Uhu U. schrieb: > René H. schrieb: >> Mac G. schrieb: >>> man hätte statt HTML damals auch einfach sowas wie BBcode einführen können, >> >> Du weisst aber schon dass BBCode serverseitig in HTML umgewandelt wird? > > "Sowas wie BBCode" heißt nicht BBCode. Eine Implementierung für Mail > müsste natürlich auf dem jeweiligen Mail-Client lokal laufen... Genau das. Der Client kann das natürlich völlig problemlos direkt rendern ohne HTML als Zwischenschritt. Ja... da hätte jemand mal ein paar Tage dran programmieren müssen statt einfach den Webbrowser ins Programm einzubinden, das wäre die Mühe aber Wert gewesen. Es reichen ja schon ein paar ganz einfache Formatierungen.
Das Problem ist ja nicht das html an sich, sondern das unsichere Nachladen vom Drittanbieter. Der Trick funktioniert ja so, dass man den verschlüsselten Text unangetastet lässt und mit einem "<img src="meinserver.xx/" und einem ">" umgibt. Der Mailclient versucht dann das externe Bild nachzuladen und überträgt als "Dateinamen" die vorher entschlüsselte Mail zum Server. Verbietet man das Nachladen von Graphiken, ist Schluss damit.
soul e. schrieb: > sondern das unsichere Nachladen vom Drittanbieter. Microsoft hat ja schon den richtigen Weg eingeschlagen, aber nicht richtig zuende gebracht. Das automatische Laden von Bildern kann ja in Outlook schon jetzt blockiert werden. Nur sind Bilder nicht die einzigen Links die Angreifer ausnutzen können. M.E. muss man das Emailformat nicht neu erfinden. Die technischen Möglichkeiten gibt es schon jetzt. Die Sicherheit erhöhen ist schon jetzt möglich. Man könnte z.B. den Emailheader analysieren bevor die Email in den Posteingang gelangt. Den Absendernamen kann man ja manipulieren, und genau das kann man zur Analyse nutzen. Manipulierte Emails könnten in einen speziellen Quarantäneordner verschoben werden. Innerhalb des Quarantäneordners wäre nur lesen und löschen (am Papierkorp vorbei) möglich, alle anderen Funktionen (Antworten, verschieben, Links anklicken, entschlüsseln etc.) wären nicht möglich. Linkshortener könnte man in Klartext umwandeln lassen. Und es wäre noch mehr möglich.
René H. schrieb: > soul e. schrieb: >> sondern das unsichere Nachladen vom Drittanbieter. > > Microsoft hat ja schon den richtigen Weg eingeschlagen Den hier? https://sec-consult.com/en/blog/2017/10/fake-crypto-microsoft-outlook-smime-cleartext-disclosure-cve-2017-11776/ SCNR :D
Die Heise-Artikel, tagesschau.de, und SZ geben die fehlerhafte Homepage und das Paper wieder. Das Paper mach claims und liefert dann nicht. Die Crypto ist nicht kaputt und OpenPGP funktioniert auch weiterhin. Enigmail schaltet HTML rendering per default aus, ebenso z.B. Torbirdy. HTML in Emails war schon immer eine schlechte Idee. Offizielle Stellungnahme der GnuPG und Enigmail Autoren: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html > We have three things to say, and then we're going to show you why we're right. > > 1. This paper is misnamed. > 2. This attack targets buggy email clients. > 3. The authors made a list of buggy email clients. > ... > The authors have done the community a good service by cataloguing buggy > email email clients. We're grateful to them for that. We do wish, > though, this thing had been handled with a little less hype. A whole lot > of people got scared, and over very little. https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060333.html > BTW, the lack of all version numbers of the plugins or crypto engines is > a major flaw in the paper. With version numbers it would be much easier > to see what is wrong with some claims. https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html > We've known about problems in OpenPGP's feedback mode for at least > thirteen years. (See https://eprint.iacr.org/2005/033.pdf for an > example.) The OpenPGP working group resolved these problems by adopting > modification detection codes (MDCs). GnuPG properly implements MDCs and > gives clear and unambiguous warnings if a message lacks an MDC. The > paper authors acknowledge that if an email client handles these warnings > sensibly, their attack fails. > > In other words, their attack is completely dependent on email clients > handling our warnings in a broken way. Great: that they've found bugs in > major email clients is a good thing, but where's the flaw in the OpenPGP > protocol or GnuPG's implementation of it? And does this really deserve > the hype-tastic title "Breaking S/MIME and OpenPGP Email Encryption" when > it really doesn't do that? > > In grad school my adviser told me to follow Napoleon's Rule in paper > titles. "If you tell the world you're going to conquer Russia, you'd > better conquer Russia." This paper doesn't deliver on what its title > promises. Mit den Autoren der betroffenen Software wurde nicht kommuniziert: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such time > as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll reach > out next time. Undiplomatisch ausgedrückt, gilt leider in diesem Fall wieder: https://plus.google.com/+LinusTorvalds/posts/PeFp4zYWY46 Ich hätte von der Ankündigung und dem medialem Trommelwirbel her erwartet, dass endlich RSA brauchbar faktorisiert/anderweitig gebrochen wurde. Bin sehr underwhelmed.
René H. schrieb: > Man könnte z.B. den Emailheader analysieren bevor die > Email in den Posteingang gelangt. Ein aktuelles Enigmail implementiert Memory Hole/Protected Headers: https://github.com/autocrypt/memoryhole D.h. das (endlich) auch die Emailheader (Subject, From, Date, ...) verschlüsselt und signiert werden können. Öffentlich einsehbar ist dann nur ein dummy header (z.B. generisches "Subject: Encrypted"). > Den Absendernamen kann man ja > manipulieren, und genau das kann man zur Analyse nutzen. Man kann natürlich alle Headerzeilen manipulieren, nicht nur den Absendernamen. Außer natürlich man packt das alles in einen kryptographisch gesicherten Teil der Email (s.o.).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.