1. Patent gegen Abschnorcheln
In welchem Ausmaß die NSA und andere Geheimdienste weltweit die Telekommunikation und insbesondere das Internet verdachtsunabhängig überwachen bleibt weiterhin unklar. Auch ist nicht geklärt ob US-Behörden tatsächlich die geheimen SSL-Schlüssel von Internet-Dienstleistern anfordern. Letztendlich spielt es keine Rolle, ob der geheime SSL-Schlüssel angefordert, gestohlen oder verloren geht. Rückwirkend lässt sich damit eine aufgezeichnete Kommunikation prinzipiell entschlüsseln.
Mit Perfect Forward Secrecy (PFS) lässt sich dies vermeiden. Das Verfahren verhindert, dass eine in der Vergangenheit verschlüsselt aufgezeichnete Kommunikation durch Bekanntwerden des geheimen Schlüssels wieder entschlüsselt werden kann. PFS nutzt das Diffie-Hellman-Schlüsselaustauschverfahren, bei dem sich beide Kommunikationspartner auf einen temporären Sitzungsschlüssel einigen. Dieser Schlüssel wird nicht zwischen den Kommunikationspartner ausgetauscht und kann daher nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung wird damit unmöglich.
Für die Webservices nginx und Postfix stellte die Umstellung auf PFS kein Problem dar. Anders die Kombination zwischen dem E-Mail Server Dovecot und Apple Mail (iOS und Mac OS X) – erst nach Wireshark Mitschnitten kam ich auf die Lösung.
2. Perfect Forward Secrecy mit Dovecot
Über das IMAP-Protokoll stellt Dovecot E-Mails für meine Endgeräte zur Verfügung. Zwischen Client und Server wird dazu eine SSL-verschlüsselte Verbindung über Port 993 (IMAPS) initiiert und im Anschluss die Mails abgerufen.
Eine erste Analyse für die PFS-Eignung von Dovecot liefert mit dem Kommandozeilenprogramm von OpenSSL folgendes Ergebnis:
openssl s_client -connect mail.kuketz.de:993
Bevor eine verschlüsselte Kommunikation zwischen zwei Partnern erfolgt, wird zunächst eine Chiffriermethode (Cipher-Suite) ausgehandelt. Dazu schickt der Client eine Liste von Cipher-Suiten die er beherrscht und eine verschlüsselte Kommunikation mit ihm ermöglicht. Im Beispiel oben haben sich Client und Mail-Server auf den »DHE-RSA-AES256-SHA« Cipher verständigt.
Demnach unterstützt Dovecot, als auch das Kommandozeilenprogramm den »DHE-RSA-AES256-SHA« OpenSSL-Cipher und damit das Diffie-Hellman-Verfahren. Im Detail bedeuten die Parameter folgendes:
-
- TLSv1/SSLv3 Protokoll
- DHE steht für Diffie-Hellman-Schlüsselaustausch
- RSA dient der asymmetrischen Verschlüsselung des Schlüsselpaars
- Die eigentliche Kommunikation wird anschließend über AES256 symmetrisch verschlüsselt
- SHA stellt die Integrität der Daten mit einem Hashwert sicher
Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Bisher kein ECDHE
DHE als Schlüsselaustauschverfahren ist prinzipiell in Ordnung. Sofern beide Kommunikationspartner die aktuellere ECDHE Variante unterstützen, ist diese allerdings klar gegenüber DHE vorzuziehen. Die EC-Variante basiert auf elliptischen Kurven und hat gegenüber der DHE-Variante folgende Vorteile:
- Geringere Rechenzeit für die Schlüsselberechnung
- Weniger Overhead bei der Kommunikation zwischen Client und Server
Das Kommandozeilenprogramm OpenSSL Version 1.0.1e unterstützt ECDHE bereits:
openssl ciphers -v
Dovecot hingegen unterstützt die EC-Variante bisher noch nicht. Jedenfalls nicht im offiziellen Debian Package für Wheezy. Im Changelog eines Nightly-Builds der Entwickler ist es dennoch schon aufgetaucht:
* src/lib-ssl-iostream/iostream-openssl-context.c: lib-ssl-iostream: Added support for ECDH/ECDHE cipher suites Based on the login-common patch by David Hicks. [dc99912e5047]
Client und E-Mail Server haben sich daher auf die langsamere »DHE-RSA-AES256-SHA« Variante geeinigt.
3. Apple Mail
Dovecot (Version 2.1.7-7) unter Debian Wheezy bietet als Schlüsselaustauschverfahren derzeit lediglich die etwas ältere DHE-Variante an. Apple Mail muss also ebenfalls DHE unterstützen, damit eine SSL-verschlüsselte Kommunikation im Sinne von PFS möglich wird.
Ein Wireshark-Mitschnitt belegt allerdings das Gegenteil:
Apple Mail und Dovecot haben sich auf die Cipher-Suite »RSA-AES128-SHA« verständigt. Das Diffie-Hellman-Schlüsselaustauschverfahren wird also nicht verwendet. Rückwirkend lässt sich damit eine aufgezeichnete Kommunikation prinzipiell entschlüsseln.
In einem weiteren Mitschnitt mit Wireshark wird die Liste mit Cipher-Suiten erfasst, welche Apple Mail an Dovecot übersendet. Mit einem überraschenden Ergebnis:
Apple Mail bietet zunächst die ECDHE-Varianten, gefolgt von den ECDH Chiffriermethoden für den Schlüsselaustausch an. Konsequent und logisch wäre als weitere Variante das DHE-Verfahren (grüner Balken) vorzuschlagen. Womöglich aus Performance-Gründen hat sich Apple allerdings für Cipher-Suiten (roter Balken) entschieden, welche NICHT Diffie-Hellman-fähig sind.
Dovecot erhält von Apple Mail also eine Liste mit Cipher-Suiten, in welcher die DHE-Variante eine geringe Priorität aufweist. Bei der Aushandlung wird also nicht die bestmögliche Variante gewählt, sondern die Liste sequentiell abgearbeitet, bis der Server eine Cipher-Suite findet, welche er auch beherrscht. Diese lautet dann »RSA-AES128-SHA«.
Im Übrigen ist es irrelevant, ob die Kommunikation über den Port 993 (IMAPS) oder Port 143 mit vorgeschaltetem STARTTLS verläuft. Das Ergebnis ist in beiden Fällen der »RSA-AES128-SHA« Cipher.
3.1 Anpassung Dovecot
Da Apple Mail leider keine Möglichkeit bietet in die Reihenfolge der übertragenen Cipher-Suiten einzugreifen, muss die Anpassung serverseitig erfolgen.
Standardmäßig unterstützt Dovecot folgende Chiffriermethoden:
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
Diese Zeile wird folgendermaßen angepasst:
ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4
Ursprünglich umfasst ALL alle Cipher-Suiten, mit der Ausnahme LOW, SSLv2, EXP und aNULL. In der Anpassung werden die möglichen Cipher-Suiten stark eingeschränkt und priorisiert. Bevorzugt wird die Variante »DHE-RSA-AES256-SHA« – eine Cipher-Suite auf Diffie-Hellman Basis, die Apple Mail ebenfalls unterstützt.
Ein Wireshark-Mitschnitt stellt das Ergebnis nach der Anpassung dar:
Funktioniert!
4. Fazit
PFS verhindert die nachträgliche Entschlüsselung von aufgezeichneter Kommunikation, falls der geheime Schlüssel in falsche Hände gerät. Doch nur wenn beide Kommunikationspartner aufeinander abgestimmt sind, funktioniert die Variante auch zuverlässig. Clientseitig lassen sich Cipher-Suiten im Normalfall leider nicht neu sortieren / priorisieren – ein Umstand der sich bei Apple Mail bemerkbar macht. Die dort gewählte Reihenfolge der Chiffriermethoden ist nicht ideal und kann lediglich durch einen Eingriff auf dem Server korrigiert werden kann.
Auch bei anderen Mail-Clients könnte diesbezüglich noch die ein oder andere Überraschung lauern. Letztendlich ist das Mitschneiden der Kommunikation erforderlich, um die einwandfreie Funktion von PFS zwischen Client und Server aufzuzeigen. Eine wenig befriedigende Vorstellung für den Anwender.
Die E-Mails selbst werden durch TLS/SSL selbstverständlich nicht verschlüsselt, sondern lediglich der Transportweg zwischen Client und Server. Die Verschlüsselung von E-Mails wird in diesem Beitrag erklärt: Verschlüsselte E-Mails mit GnuPG als Supergrundrecht.
Bildquellen:
Dog: „#46285025“, https://de.fotolia.com/id/46285025
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten
NSA abhörsichere SSL-Verschlüsselung für Apache und nginx
Postfix: ECDSA / RSA-Keys und TLS-Konfiguration
GnuPG-Schlüsselerstellung und Smartcard-Transfer – Nitrokey Teil2
ejabberd: Installation und Betrieb eines XMPP-Servers
5 Ergänzungen zu “Perfect Forward Secrecy mit Apple Mail?”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Hi, super Blog
just for Info mit
ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4
geht Outlook 2003 auf win7 mit pop3s nicht mehr, Thunderbird war auf Linux kein Problem
Danke, für den super interessanten Beitrag. Top Blog! Lieben Gruß, Mina
Welche Version von MacOSX benutzt du?
Ich versuche gerade auch Perfect Forward Secrecy mit Apple Mail in Betrieb zu nehmen. Ich habe MacOS 10.6.8. Bei mir bietet Apple Mail allerdings die ECDHE_* und ECDH_* ciphers nicht an. Daher frage ich mich, welche Version Du benutzt.
73, Mario
Ich nutze derzeit 10.8.5 – also Mountain Lion.
Hallo Mike,
danke für den aufschlussreichen Artikel!
Und eine Frage:
Ich habe versucht, das obige Szenario beim Email-Abruf meinem Provider (Strato) nachzuvollziehen.
In Wireshark sehe ich nun, dass beim Start des Email-Programms (z.B. Thunderbird oder Apple Mail) mehrere Client Hello / Server Hello Paare autauchen.
Die meisten handeln mittlerweile eine PFS Verschlüsselung (DHE/ECDHE) aus, aber ein Paar ist immer dabei, wo kein PFS verwendet wird.
Weißt Du, was es damit auf sich hat?
Wieso werden mehrfach Client/Server Hellos ausgetauscht, und wieso ist eins ohne PFS?
Indem ich micht nicht so genau mit den SSL Protokollabläufen und IMAP Details auskenne, bin ich etwas ratlos.
Bei Bedarf könnte ich auch den Wireshark Mitschnitt liefern…
Viele Grüße