Transportverschlüsselung und Forward Secrecy – sichere Verschlüsselung für Web und E-Mail?

Nach einem Bericht von cNet versuchen US-Regierugsbehörden der geheimen Schlüssel von Internet-Diensteanbietern habhaft zu werden, um auch Ende-zu-Ende-verschlüsselte Kommunikation, wie sie etwa über https-Verbindungen erfolgt, umfassend abhören und überwachen zu können. Da die NSA offenbar große Mengen verschlüsselter Kommunikation auf Vorrat gespeichert hat, wäre es für die Behörde damit auch möglich, in der Vergangenheit erfolgte Kommunikation nachträglich zu entschlüsseln.

Ende-zu-Ende-Verschlüsselung ist zwar gegen Man-in-the-Middle-Angriffe grundsätzlich geschützt: Die Kommunikation wird mit einem zu Beginn ausgehandelten Sitzungsschlüssel zunächst symmetrisch verschlüsselt und vor dem Übertragung zusätzlich mit dem öffentlichen Schlüssel des Empfängers assymetrisch verschlüsselt. Wenn allerdings die gesamte verschlüsselte Kommunikation inklusive des Sitzungsschlüssels abgefangen wird und der Angreifer zusätzlich in Besitz des nicht übetragenen geheimen Schlüssel des Diensteanbieters kommt, so kann damit der gemeime Sitzungsschlüssel und damit der Nachrichteninhalt entschlüsselt werden.

Welche Maßnahmen können getroffen werden, um dies zu verhindern oder zumindest zu erschweren?

Mit dem Diffie-Hellman-Verfahren (Diffie und Hellman 1976, RFC 2631) hält die Kryptographie einen Mechanismus bereit, der es räumlich getrennten Kommunikationspartnern ermöglicht, sich auf einen gemeinsamen geheimen Sitzungsschlüssel zum Verschlüsseln von Nachrichten zu einigen, ohne dass dieser jemals übertragen wird und somit nicht durch eine einfache Man-in-the-Middle-Attacke abgefangen werden kann.

In der Kryptographie wird diese Eigenschaft eines Verschlüsselungsverfahrens auch als Perfect Forward Secrecy (PFS) bezeichnet.

Forward Secrecy beim Abholen von E-Mails

Wir benutzen in unserem Szenario Dovecot als IMAP-Server, von dem E-Mails mittels eines E-Mail-Clients wie Thunderbird oder Outlook abgeholt werden.

Damit Dovecot die Art der dabei verwendeten Verschlüsselung beim Login mitschreibt, ändern wir in der Dovecot-Konfiguration ggf. das Logging-Format:

login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c with cipher %k

Auf diese Weise wird sichtbar, welche Verschlüsselung beim IMAP-Login zwischen E-Mail-Client und IMAP-Server verwendet wird. Dabei handeln Client uns Server die Art der Verschlüsselung aus. PFS wird nur genutzt, wenn sowohl Client als auch Server dies unterstützen.

Thunderbird 17 nutzt Diffie-Hellman (DHE) zum Schlüsseltausch und starke 256-Bit-Verschlüsselung:

dovecot: imap-login: […] TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)

...im Gegensatz zu Outlook 2007, K-9 Mail für Android und dem nativen Mail-Client von Android 4.1.1, die kein DHE nutzen und nur mäßige 128-Bit-Verschlüsselung bieten:

dovecot: imap-login: […] TLSv1 with cipher AES128-SHA (128/128 bits)

Forward Secrecy zwischen zwei Mail-Servern

Der Transport zwischen zwei E-Mail-Servern erfolgt nur dann per PFS, wenn beide Server entsprechende Verfahren, etwa das Diffie-Hellman-Verfahren, bereitstellen. Damit dies überhaupt möglich ist, müssen auch beide Server zunächst überhaupt eine verschlüsselte Verbindungen erlauben. Der Standard hierfür ist das STARTTLS-Verfahren (RFC 3207).

Falls der sendende und der empfangende Mail-Server Verschlüsselung über via STARTTLS unterstützen, ist dies bei entsprechender Konfiguration im Header einer auf diese Weise empfangenen E-Mail sichtbar:

Received: from example.com (example.com [198.51.100.1])
	(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))

Hier wird das STARTTLS-Verfahren (TLS) für die Übertragung verwendet, wobei Anonymous Elliptic Curve Diffie Hellman (AECDH) als Chiffre zum Schlüsselaustausch zum Einsatz kommt und der Inhalt der E-Mail mittels des AES-Chiffres mit einer Schlüssellänge von 256 Bit (AES256) verschlüsselt wird.

Mit folgendem Python-Skript lässt sich prüfen, ob verschiende Server STARTTLS unterstützen:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Copyright © Alexander Finkenberger

from dns import resolver
import smtplib

domains = ('finkenberger.org', 'gmx.de', 'web.de', 'hotmail.com', 'yahoo.com',
           'aol.com', 'gmail.com', 't-online.de')

def get_mx_servers_by_priority(domain):
    # returns list of mx servers sorted by priority
    try:
        mx_records = [x.to_text().split() for x in resolver.query(domain, 'MX')]
        mx_records.sort()
        servers_by_priority = [record[1][:-1] for record in mx_records]
        return servers_by_priority
    except (resolver.NoAnswer, resolver.NXDOMAIN, resolver.Timeout):
        return None

def check_mx_tls(domain_mx):
    try:
        smtp = smtplib.SMTP(domain_mx)
        smtp.ehlo()
        result = smtp.has_extn('STARTTLS')
        smtp.quit()
        return result
    except Exception:
        return None

result_table=[]

for domain in domains:
    domain_mx_servers = get_mx_servers_by_priority(domain)
    if domain_mx_servers:
        for mx_server in domain_mx_servers:
            result_list = [domain]     # first element of list: domain
            result_list.append(mx_server)
            tls_result = check_mx_tls(mx_server)
            if tls_result:
                result_list.append('TLS supported')
                break
            if tls_result == False:
                result_list.append('TLS not supported')
                break
            if tls_result == None:
                result_list.append('no answer')
        result_table.append(result_list)
        print result_list[0].ljust(22), result_list[1].ljust(37), result_list[2].ljust(20)

Zu beachten ist dabei, dass viele SMTP-Server IP-Adressen von DSL- und Kabel-Providern blockieren, so dass dieses Skript falsche Resultate liefern kann, wenn es von solchen Verbindungen aus ausgeführt wird.

Adaption von TLS durch Hochschulen, Freemail-Anbieter und Unternehmen

Anhand des obigen Skripts wurden die Mail-Server von 69 deutschen Universitäten getestet, zwölf Freemail-Dienste, die 24 britischen Russell-Universitäten, eine Stichprobe von 79 Hochschulen in den USA, die zehn Ivy-League-Universitäten der USA sowie 26 der größten Unternehmen Deutschlands. Das folgende Diagramm veranschaulicht den Anteil der STARTTLS-unterstützenden Mail-Server in Prozent, zum Zeitpunkt August 2013 (graue Säulen) und Mai 2014 (blaue Säulen):

Insgesamt schnitten die britischen Universitäten 2013 am schlechtesten ab, gefolgt von den deutschen Universitäten, von denen im August 2013 nur knapp die Hälfte Transportverschlüsselung auf ihren Mail-Servern unterstützte. Damit schnitten die deutschen Universitäten deutlich schlechter ab als die verbreitetsten Freemail-Dienste. Dagegen wird STARTTLS auf 96 Prozent der Mail-Server großer deutscher Unternehmen eingesetzt.

Die geringe Verbreitung von Verschlüsselungsverfahren insgesamt überrascht insofern, als dass das dafür entwickelte STARTTLS-Verfahren erstmals bereits 1999 standardisiert wurde (RFC 2487).

Darüber hinaus erscheint es verwunderlich, warum gerade Hochschulen, an denen E-Mail entwickelt wurde und zuerst Verbreitung fand, in Sachen Verschlüsselung gegenüber Unternehmen und teilweise gegenüber vornehmlich privat genutzten Freemail-Diensten hinterherhinken.

Literatur

Diffie, W. und Hellman, M. E. (1976): New Directions in Cryptography. In: IEEE Transactions on Information Theory. 22, Nr. 6, 1976, S. 644–654. Online: http://www-ee.stanford.edu/~hellman/publications/24.pdf (PDF). Hoffman, P. (1999): RFC 2487: SMTP Service Extension for Secure SMTP over TLS Hoffman, P. (2002): RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security Rescorla, E. (1999): RFC 2631: Diffie-Hellman Key Agreement Method
Home