© AI Studio/Shutterstock.com
Entwickler Magazin
Wie funktioniert EFAIL und wie schlimm ist das alles wirklich?

EFAIL: Angriff auf verschlüsselte Mails

Eine E-Mail ist wie eine Postkarte in der Briefpost: Wer sie sieht, kann sie lesen. Deshalb sollte man eigentlich nur verschlüsselte Mails verschicken, die dieses unbefugte Lesen verhindern. Über die EFAIL-Angriffe kann die Verschlüsselung aber ausgehebelt werden. Ist das wirklich die große Katastrophe, als die es dargestellt wird?

Carsten Eilers


ArtikelserieTeil 1: Grundlagen der E-Mail-VerschlüsselungTeil 2: EFAIL

Die Grundlagen der E-Mail-Verschlüsselung habe ich im Entwickler Magazin 5.2018 beschrieben [1]. Darin wurde alles vorgestellt, was wir für die Verschlüsselung von E-Mails brauchen. Was jetzt noch fehlt, ist nur noch eine Vereinbarung, wie man die Mails formatieren soll. Dafür gibt es drei Möglichkeiten: PGP/INLINE, PGP/MIME und S/MIME.

Die Formate im Schnelldurchlauf

PGP/INLINE wird von PGP/GnuPG verwendet und im OpenPGP-Message-Format-Standard in RFC 4880 [2] standardisiert. Der Text der E-Mail (nur reiner Text, HTML wird nicht unterstützt) wird als sog. ASCII Armor codiert und im Body der Mail übertragen.

PGP/MIME wird wie PGP/INLINE von PGP/GnuPG verwendet, basiert auf den Standards RFC 4880 (OpenPGP Message Format [2]) und RFC 3156 (MIME Security with OpenPGP [3]). RFC 4880 definiert Methoden und Aufbau von mit OpenPGP verschlüsselten bzw. signierten Daten. RFC 3156 definiert, wie die in RFC 1847 (Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted [4]) beschriebenen MIME-Inhaltstypen in OpenPGP-spezifische Inhaltstypen zur Verschlüsselung und Signierung übertragen werden müssen.

In RFC 1847 [4] werden zwei MIME Content Types definiert, die auch von PGP/MIME verwendet werden:

multipart/signed für signierte Nachrichten und multipart/encrypted für verschlüsselte Nachrichten.

S/MIME, erstmals in RFC 2633 und aktuell in RFC 5751 [5] spezifiziert, unterstützt multipart/signed für signierte Nachrichten, verwendet aber das eigene Format application/pkcs7-mime für die verschlüsselten Nachrichten. Dabei kann wieder frei gewählt werden, ob E-Mails nur verschlüsselt, nur signiert oder signiert und verschlüsselt werden sollen. Mehr zu den Formaten sowie Beispiele dazu finden Sie in [6].

Mitte Mai: EFAIL – verschlüsselte Mails in Gefahr!

Eine Forschergruppe rund um Sebastian Schinzel von der Fachhochschule Münster hat sich sowohl die Standards zur E-Mail-Verschlüsselung als auch ihre konkrete Umsetzungen in den Mailclients und deren Plug-ins genauer angesehen und dabei festgestellt, dass es mit der Sicherheit von S/MIME und OpenPGP nicht zum Besten steht. Die Ergebnisse wurden am 15. Mai veröffentlicht, was von Sebastian Schinzel am 14. Mai auf Twitter angekündigt worden war [7].

Am 15. Mai wurde dann die Webseite zur Schwachstelle samt Paper veröffentlicht [8]. Das auf der Webseite verlinkte Paper für das 27th USENIX Security Symposium ist noch eine Vorversion. Eine aktuelle Vers...

Entwickler Magazin
Wie funktioniert EFAIL und wie schlimm ist das alles wirklich?

EFAIL: Angriff auf verschlüsselte Mails

Eine E-Mail ist wie eine Postkarte in der Briefpost: Wer sie sieht, kann sie lesen. Deshalb sollte man eigentlich nur verschlüsselte Mails verschicken, die dieses unbefugte Lesen verhindern. Über die EFAIL-Angriffe kann die Verschlüsselung aber ausgehebelt werden. Ist das wirklich die große Katastrophe, als die es dargestellt wird?

Carsten Eilers


ArtikelserieTeil 1: Grundlagen der E-Mail-VerschlüsselungTeil 2: EFAIL

Die Grundlagen der E-Mail-Verschlüsselung habe ich im Entwickler Magazin 5.2018 beschrieben [1]. Darin wurde alles vorgestellt, was wir für die Verschlüsselung von E-Mails brauchen. Was jetzt noch fehlt, ist nur noch eine Vereinbarung, wie man die Mails formatieren soll. Dafür gibt es drei Möglichkeiten: PGP/INLINE, PGP/MIME und S/MIME.

Die Formate im Schnelldurchlauf

PGP/INLINE wird von PGP/GnuPG verwendet und im OpenPGP-Message-Format-Standard in RFC 4880 [2] standardisiert. Der Text der E-Mail (nur reiner Text, HTML wird nicht unterstützt) wird als sog. ASCII Armor codiert und im Body der Mail übertragen.

PGP/MIME wird wie PGP/INLINE von PGP/GnuPG verwendet, basiert auf den Standards RFC 4880 (OpenPGP Message Format [2]) und RFC 3156 (MIME Security with OpenPGP [3]). RFC 4880 definiert Methoden und Aufbau von mit OpenPGP verschlüsselten bzw. signierten Daten. RFC 3156 definiert, wie die in RFC 1847 (Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted [4]) beschriebenen MIME-Inhaltstypen in OpenPGP-spezifische Inhaltstypen zur Verschlüsselung und Signierung übertragen werden müssen.

In RFC 1847 [4] werden zwei MIME Content Types definiert, die auch von PGP/MIME verwendet werden:

multipart/signed für signierte Nachrichten und multipart/encrypted für verschlüsselte Nachrichten.

S/MIME, erstmals in RFC 2633 und aktuell in RFC 5751 [5] spezifiziert, unterstützt multipart/signed für signierte Nachrichten, verwendet aber das eigene Format application/pkcs7-mime für die verschlüsselten Nachrichten. Dabei kann wieder frei gewählt werden, ob E-Mails nur verschlüsselt, nur signiert oder signiert und verschlüsselt werden sollen. Mehr zu den Formaten sowie Beispiele dazu finden Sie in [6].

Mitte Mai: EFAIL – verschlüsselte Mails in Gefahr!

Eine Forschergruppe rund um Sebastian Schinzel von der Fachhochschule Münster hat sich sowohl die Standards zur E-Mail-Verschlüsselung als auch ihre konkrete Umsetzungen in den Mailclients und deren Plug-ins genauer angesehen und dabei festgestellt, dass es mit der Sicherheit von S/MIME und OpenPGP nicht zum Besten steht. Die Ergebnisse wurden am 15. Mai veröffentlicht, was von Sebastian Schinzel am 14. Mai auf Twitter angekündigt worden war [7].

Am 15. Mai wurde dann die Webseite zur Schwachstelle samt Paper veröffentlicht [8]. Das auf der Webseite verlinkte Paper für das 27th USENIX Security Symposium ist noch eine Vorversion. Eine aktuelle Vers...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang