Perfect Forward Secrecy: Mehr Sicherheit in der E-Mail-Kommunikation mit goneo

Eine E-Mail hat normalerweise den Vertraulichkeitsgrad einer Postkarte – an vielen Stellen in der Übermittlungskette kann man den Inhalt in Klarschrift lesen. Dabei bietet das E-Mail-System einige Verschlüsselungsmechanismen. goneo unterstützt die Verschlüsselung von Haus aus per SSL/TLS und einem Secured Forward Protokoll, das einen unsicheren Austausch des Sitzungsschlüssel vermeidet. Das schafft ein großes Plus an Vertraulichkeit.

Vielen haben die Enthüllungen des Whistleblowers  Edward Snowden über den US-Geheimdienst NSA und die britische Sicherheitsbehörde GCHQ deutlich werden lassen, wie leicht E-Mail-Kommunikation mitgelesen werden kann.  Verschlüsselung ist zwar möglich, aber die allermeisten User verzichteten bisher darauf.

Sie können bei goneo ein Verschlüsselungsverfahren einsetzen, das auf SSL basiert. Als Option steht in Ihrem E-Mailprogramm SSL/TLS zur Verfügung.  Dies können Sie aktivieren, um E-Mails verschlüsselt zu übertragen.Wenn Sie goneo Webmail verwenden, kommt dieser Schutz automatisch zum Tragen.

Forward Secrecy: Der offene Schlüsselaustausch wird vermieden

Mit den goneo Mailservern steht Ihnen auch das Verschlüsselungsprinzip nach Perfect Forward Secrecy (PFS) zur Verfügung. Es bietet mehr Schutz als die Verschlüsselung mittels eines geheimen und eines sitzungsbasierten Schlüssels wie sie zum Beispiel mit einfachem RSA realisiert ist.

Grund: Mit dem herkömmlichen Verschlüsselungsverfahren muss ein Sitzungsschlüssel bei der Verbindung zwischen Anwender und Mailserver ausgehandelt, also übertragen werden. Diese Übertragung lässt sich abfangen und abspeichern, so dass der ausgehandelte Sitzungsschlüssel herausgefischt werden kann. Zwar gibt es auch noch einen Schlüssel, der mailserverseitig vorgehalten wird und zur Verschlüsselung mitverwendet wird. Doch wenn dieser Schlüssel einer überwachenden Stelle bekannt ist oder später bekannt wird, lässt sich auch die bereits abgespeicherte, verschlüsselte Kommunikation mitlesen.

Bas Prinzip von Forward Secrecy setzt an der Stelle an, wo konventionelle Verfahren einen Schlüsselaustausch erfordern. Mit der Schlüsselerzeugung nach Diffie-Hellman können zwei Kommunikationspartner einen geheimen Schlüssel generieren, ohne dass sie diesen austauschen müssen.

Beide Seiten müssen eine gemeinsame Primzahl austauschen und eine Zahl mit einer bestimmten Eigenschaft: Es muss sich um eine sogenannte Primitivwurzel handeln. Primitivwurzeln sind die Zahlen, die man mit allen möglichen Resten aus einer Modulo-Operation (Teilen mit Rest) potenzieren kann, wobei in der Reihe der Ergebnisse der Modulo Operationen einmal jeder mögliche Rest (jedes Element der Restklassengruppe) als Ergebnis auftritt.

Mit diesem Prinzip kann man so einen gemeinsamen Schlüssel errechnen, ohne dass die beiden Ausgangswerte der Kommunikationspartner übereinstimmen müssen.

b = a ^i mod(m) zu berechnen, ist einfach, wenn, m, a und i bekannt sind, aber es ist sehr aufwändig, ein i zu finden, wenn b bekannt ist. Es gibt keinen bekannten effizienten Algorithmus, der die dies kann und der Aufwand für das Ausprobieren von Lösungen (Brute Force) steigt mit großen Primzahlen, die in der Praxis verwendet werden, exponentiell. Allerdings gibt es auch keinen Beweis, dass es keinen entsprechenden Algorithmus gibt, so dass die Diffie-Hellmann nur unbewiesen sicher ist.

Daher verwendet man, um das Sicherheitsniveau weiter zu erhöhen, elliptische Kurven statt Restklassengruppen, um nach der Diffie-Hellmann-Idee gemeinsame Schlüssel zu generieren.

Schematisch kann man sich dies so vorstellen:

goneo_email_verschluesselung_diffie_hellman

(1) Die Kommunikationspartner – hier Mailuser und Mailserver – stellen die „Bestandteile“ für eine Schlüsselgenerierung bereit und tauschen diese aus. Dies muss nicht geheim erfolgen. Nicht dargestellt: Die Kommunikationspartner identifizieren sich über ein Zertifikat, damit man sicher ist, mit dem richtigen Partner zu kommunizieren.
(2) Aus den Elementen erreichnet jeder Partner für sich den Schlüssel
(3) Mit diesem Schlüssel verschlüsselt der Mailuser seine Mail und (4) sendet diese  an den Mailserver.
(5) Von hier aus kann ein verschlüsselter Weitertransport erfolgen.

Entsprechende Verfahren sind auf den Servern von goneo implementiert. Sie können sich davon selbst überzeugen.

Nutzen Sie ein Tool wie Openssl, um sich die Rückmeldungen der Mailserver anzusehen:

„s_client –connect imap.goneo.de:993“

Nach den Zertifikatsinformationen sehen Sie im Output die möglichen Verschlüsselungsalgorithmen, die Cipher-Suite.

Bei goneo Mailservern steht unter der Protokollzeile die Cipher-Info:

DHE-RSA-AES256-SHA

„DHE“, das an der Spitze steht, zeigt Ihnen, dass Forward Secrecy zum Einsatz kommen kann. Dies ist die entsprechende Implementierung (TLS – Erweiterung). Unsere Mailserver ermöglichen also dieses Schlüsselaustauschverfahren. Damit Ihr installiertes E-Mailprogramm es nutzen kann, müssen Sie die SSL/TLS-Ports verwenden bzw. Ihr Mailprogramm dazu veranlassen, dies zu tun.

Auch Webseiten sind bei goneo geschützt

Übrigens gilt dies bei goneo nicht nur für den E-Mail-Dienst. Auch den Browsern wird Forward Secrecy angeboten. Manche wie etwa Chrome oder Firefox nutzen dies, manche, z.B. der Internet Explorer von Microsoft, nicht.

Sie können das beispielsweise mit Google Chrome nachvollziehen: Klicken Sie beim Aufruf einer unserer Websites auf das grüne Schloß-Symbol und dann auf den Reiter „Verbindung“, um die Information zu sehen.

screenshot_goneo_de_ssl_DHE

Das ist auch bei Webmail der Fall (https://webmail.goneo.de), dem Kundencenter (https://kundencenter.goneo.de) und bei unserer goneoCloud der Fall (https://cloud1.goneo.de)

Das Perfect Forward Secrecy – Verfahren bedeutet keinen perfekten Spionage-Schutz. Den wird niemand ernsthaft versprechen können. Dennoch bietet diese Technologie ein Stück mehr Vertraulichkeit Ihrer Inhalte im E-Mail-System.

Gegen Attacken, die als „Man-in-the-middle“-Angriff bezeichnet werden, kann PFS auch nichts unternehmen. In so einem Angriffsszenario müsste man sich als Lauscher in die Kommunikationskette einklinken, also beispielsweise die Kommunikation mit dem Mailserver abfangen, auswerten, verändern und dann weiterleiten. Dafür muss man dem Mailclient die Identität des Servers vorgaukeln, den der Client eigentlich erreichen wollte. Das geht technisch natürlich, aber für eine massenhafte Überwachung taugt dieses Verfahren aufgrund des großen Aufwands nicht.

Dieser Beitrag wurde unter Sicherheit, Technische Neuerungen abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

18 Kommentare zu Perfect Forward Secrecy: Mehr Sicherheit in der E-Mail-Kommunikation mit goneo

  1. Hallo Markus,

    Das Perfect Forward Secrecy – Verfahren bedeutet keinen perfekten Spionage-Schutz. Den wird niemand ernsthaft versprechen können. Dennoch bietet diese Technologie ein Stück mehr Vertraulichkeit Ihrer Inhalte im E-Mail-System.

    ich finde es gut, dass Du PFS ehrlicherweise nicht als perfekten Spionage-Schutz darstellst, sondern als das, was es ist: „. . . ein Stück mehr Vertraulichkeit . . .“ Den perfekten Spionage-Schutz wird es wohl nie geben. Und auch erfahrene Internet-Benutzer werden sich nicht vollständig vor Internet-Spionage schützen können, sondern höchstens ihren Inhalten gemäß ihren Fähigkeiten mehr Vertraulichkeit geben können.

    Mit freundlichem Gruß
    Gerhard Hallstein

  2. Dominik sagt:

    Hi

    Also Webmail kann Forward Secrecy wenn ich nicht den IEx nutze -.-
    Aber in dem Beitrag steht nun nicht ob Webmail auch die SSL/TSL Verschlüsselung nutzt. Im Programmen kann ichs einstellen aber im Webmail nicht.

  3. Hallo Markus,

    vielen Dank erstmal für Deinen interessanten Beitrag. Ich kannte diese Art von Verschlüsselung der Mails noch gar nicht. Und ja, nachdem das alles mit der NSA raus gekommen ist macht man sich schon seine Gedanken.

    Gruß Tanja

  4. Hey Markus,

    fand Deinen Beitrag sehr gelungen. Gerade in der heutigen Zeit und bei den Veröffentlichungen in den Nachrichten über PRISM und Co und ein Stück Vertraulichkeit doch von Vorteil!

  5. Markus sagt:

    Hallo Markus

    Danke für den guten Beitrag zum Thema.

    Zwei Anmerkungen noch:
    Der aktuelle Firefox23 unterstützt Forward Secrecy zwar schon, das kommt aber bei der von Goneo gewählten vom Server bevorzugten Cipher Suite Reihenfolge (beim Apache die SSLCipherSuite Einstellung) nicht zur Wirkung. Auf der SSL-Testseite https://www.ssllabs.com/ssltest/analyze.html?d=webmail.goneo.de kann man sich das anschauen. In dieser Reihenfolge sollte man TLS_RSA_WITH_RC4_128_SHA (0x5) (= RC4-SHA)
    etwas weiter hinter schieben damit der Firefox die Suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) (= DHE-RSA-AES256-SHA) und damit Forward Secrecy nutzt.
    Ein aktueller Internet Explorer kann ebenfalls Forward Secrecy aber nur mit den ECDHE-Suiten, die der Apache erst ab Version 2.4 unterstützt. Was der Browser unterstützt kann man sich hier https://cc.dcsec.uni-hannover.de anschauen.

    Grüße

    • Hallo,
      danke für den Hinweis bez. der Cipher Suite Reihenfolge. Vielleicht können wir das kurzfristig ändern. Den neusten IE habe ich ehrlich gesagt gar nicht ausprobiert. Das Enhancement mit den elliptische Kurven, also ECDHE, setzen wir derzeit nicht ein. Das macht zur Zeit noch Probleme in der technischen Umsetzung.

  6. André sagt:

    Hallo Markus,

    schön zu lesen, dass ihr nun auf PFS mit DHE setzt. Mir ist jedoch aufgefallen, dass dies von den *.ssl-secured-server.de Systemen noch nicht eingesetzt wird. Wann wird dies für diese Adressen eingeführt werden?

    Weiterhin stelle ich mir die Frage, ob Ihr bei Eueren Systemen nicht gleich noch einen Schritt weiter gehen wollt und ECDHE aktiviert? Damit würden dann beim DHE gleich noch die noch elliptischen Kurven verwendet werden, was den Schlüsselaustausch ja noch sicherer machen soll.

    Gruß
    André

    • Hallo André
      ich habe das eben nochmal überprüft. Stimmt, der Schlüsselaustausch ist auf ssl-secured-server.de noch konventionell. Wir werden man sehen, dass wir das ändern können.

      Die stärkere Secrecy im Schlüsselaustausch mittels elliptischer Kurven ist vermutlich eine Performancefrage. Wir werden das aber auch noch mal bei Ops hinterfragen.

      Viele Grüße
      Markus

    • Markus sagt:

      Inwiefern machen elliptische Kurven den Schlüsselaustausch sicherer?

      Es ist doch eher so das Bruce Schneier als anerkannter Kryptologe von elliptische Kurven abrät. Siehe zum Beispiel http://www.golem.de/news/elliptische-kurven-die-herkunft-der-nist-kurven-1309-101567.html

      • Das Problem ist dann aber nicht die Idee der elliptischen Kurven an sich, sondern die Vermutung, ein NSA Mitarbeiter, der an diversen Kryptostandards mitgearbeitet hat, hätte eine oder einige wenige besondere elliptische Kurven gefunden, die sich auf einen Wert (oder zählbar wenige Ausgangswerte) zurück rechnen lassen. Somit wäre in den Verschlüsselungsalgorithmen eine Hintertür offen.

        Wie es aussieht, müsste die NSA über mehr theoretisches Wissen verfügen als die öffentlich zugängliche Forschung. Zumindest in einer Wissenschaft, die – wie die Mathematik – nicht von sehr aufwändigem und teuerem technischen Gerät zum Experimentieren lebt, darf das bezweifelt werden. Auch wenn NSA solche Großtaten behauptet wie, sie könne SSL-Verschlüsselungen brechen: Man muss nicht alles glauben. Vielleicht muss die NSA PR Abteilung der amerikanischen Öffentlichkeit einfach nur erklären, was mit den Steuermilliarden eigentlich so passiert. In diesem Bestreben kann man schon mal zur Übertreibung neigen.

        • Markus sagt:

          Die veröffentlichten Akten von Snowden haben einiges bestätigt was vorher als paranoide Spinnerei und nicht durchführbar abgetan wurde.

          Sicher eine AES-256Bit Verschlüsselung zu bruteforcen ist Utopie, aber es gibt viele andere Wege das zu Bewerkstelligen, was auch getan wird.

          Wenn führende Kryptologen da Zweifel äußern kann man das natürlich auch als Übertreibung/Wichtigtuerei abtun oder etabliertes bevorzugen. Das wäre in dem Fall das bekannte RSA (mit entsprechend langen Schlüsseln natürlich). Wir reden da natürlich von Kritik auf hohem Niveau. Die jeweilige Implementierung ist noch eine andere Geschichte, die DHE-Methoden in Kombination mit PFS haben auf einem Apache auch ihre Schwächen.
          Deswegen gern auch ECDHE-Methoden, vor allem für die Internet Explorer Nutzer.

Schreibe einen Kommentar zu Gerhard Hallstein Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.