Seit wenigen Tagen überschlägt sich die Presse mit Meldungen, dass Verschlüsselungen "im Internet" geknackt worden sein. Leider wurde hierbei so oft voneinander zitiert, dass sich auch viele Übertreibungen und Vereinfachungen in den Nachrichten finden, die mit der Wahrheit wahrscheinlich nicht mehr all zu viel zu tun haben. Nachdem ich die ersten Schlagzeilen gelesen habe, dachte ich mir anfangs, dass ich es mir nicht vorstellen konnte, dass die unterschiedlichen mathematischen Probleme, auf den Verschlüsselungen beruhen, geknackt worden sind. Nach dem Lesen der Artikels bemerkte ich, dass ich recht hatte: Nicht die Verschlüsselungen wurden geknackt, sondern, im Gegenteil, es wurde getrickst und beeinflusst, um Verschlüsselungen, durch absichtlich inkorrekte Implementierung, unsicherer zu gestalten.

Wie ich bereits im Beitrag Grundlagen der Verschlüsselung auf mögliche Schwachstellen hingewiesen habe, möchte ich nun einmal kurz & leicht verständlich auswerten, was eigentlich in den Presse in den letzten Tagen bekannt geworden ist. Ich stütze mich hierbei auf die Berichte der New York Times, des Guardian und des Online-Portal ProPublica. Weiterhin habe ich mir Texte von Bruce Schneier als Quelle genommen, ein anerkannter, renommierter Kryptographieexperte, der ebenfalls Zugriff auf die geleakten Dokumente hatte.

Ist die SSL Verschlüsselung unwirksam und somit sinnlos?

Nein, nach den bisher vorliegenden Informationen nicht. Den Berichten zur Folge wurden Wege gefunden, dennoch verschlüsselte Informationen mitlesen zu können. Die Wege sind bei weitem nicht neu, nur die Größenordnung und die hohe Systematik dahinter ist neu. Um die "Schwachstellen" von SSL nachvollziehen zu können, müssen wir im im Bereich der SSL bzw. TLS Verschlüsselungen ins Detail gehen, hierbei werde ich auch auf das Thema Perfect Forward Secrecy (PFS) eingehen.

Der TLS-Handshake: Der Verbindungsaufbau

Wird eine https-verschlüsselte Webseite aufgerufen, müssen zahlreiche Nachrichten zwischen den Server und dem Browser ausgetauscht werden, bevor im Browser der Inhalt der Webseite angezeigt werden kann.

Die Graphik sollte selbsterklärend sein, ich möchte deshalb nur auf einige wenige Punkte eingehen. Im Schritt 2 sendet der Client dem Server unter anderem die generierten Zufallsdaten und Informationen zu Chiper-Suiten, die (z.B. vom Browser) unterstützt werden:

Die Reihenfolge der Chiper-Suiten legt gleichzeitig die Priorisierung der Suiten fest. Der Server vergleicht diese mit denen, die von ihm unterstützt werden und gibt die zu verwendende Suite im schritt 4 an den Client zurück:

Mit dem Schritt 13 im oberen Bild fällt und steht die Sicherheit des Verfahrens: Das Pre-Master-Secret muss verschlüsselt und vor fremden Blicken geschützt an den Server übertragen werden. Mit Hilfe der folgenden Formel wird das Master Secret berechnet:

Aus dem TLS Master Secret wird unter anderem das Passwort für den (symmetrisch) verschlüsselten Daten Channel abgeleitet. TLS versendet die Daten aus performancegründen über eine symmetrisch verschlüsselte Leitung.

Perfect Forward Secrecy

Erklärt wurde oben der Schlüsselaustausch mit Hilfe des RSA Verfahrens. Aus der Graphik ersichtlich sind zwei Dinge:

• Der Key der symmetrische Verschlüsselung ändert sich nach jedem TLS Handshake.
• Zur Entschlüsselung des Datenverkehrs müsste der auch der TLS Handshake mitgeloggt und geknackt werden, insofern der symmetrische Key nicht direkt angegriffen wird.

Eine nachträgliche Entschlüsselung von Datenverkehr ist dann möglich, wenn es gelingt, den TLS Handshake zu knacken, z.B. wenn der Private Key des Servers öffentlich geworden ist. Durch den Private Key ist es möglich, das Pre-Master-Secret des Clients zu entschlüsseln und somit das Master Secret zu berechnen.

Um eine nachträgliche Entschlüsselung zu verhindern, ist im TLS Standard die Möglichkeit implementiert worden, ein Cipher zu wählen, der PFS unterstützt. Perfect Forward Secrecy ermöglicht eine vollkommen unabhängige Schlüsselgenerierung: Wird der Private Key des Servers offengelegt, ist eine nachträgliche Entschlüsselung des Traffics, anders als z.B. bei reinem RSA, trotzdem nicht möglich.

Ein PFS Cipher lässt sich am "E" (für Ephemeral, dt. vergänglich, kurzlebig) am Ende des Schlüsselaustauschverfahrens erkennen:

• DHE
• ECDHE

Die TLS Cipher-Suite

Im Punkt 2 und 4 der ersten Graphik werden die so genannte Crypto-Infos ausgetauscht, unter anderem sendet der Client (also meistens der Browser) eine Liste von Cipher-Suites, die der Client unterstützt. Eine Cipher-Suite setzt sich aus folgenden Elementen zusammen:

• Das Schlüsselaustauschverfahren (u.a. RSA, DH, ADH, DHE, ECDHE)
• Das Authentifizierungsverfahren (u.a. RSA, DSS, ECDSA)
• Die zu verwendende Hashfunktion (u.a. MD5, SHA)
• Das Verschlüsselungsverfahren (u.a. AES, CAMELLIA, RC4, IDEA, 3DES)

Die Schlüsselaustauschfunktion wird verwendet, um das Pre-Master-Secret zu berechnen, aus welchem wiederum der Verschlüsselungs-Key und das MAC-Geheimnis berechnet wird. Das Pre-Master-Secret darf nur dem Client und dem Server bekannt sein, jedoch keinem Dritten. Beispiele für Schlüsselaustauschverfahren:

• RSA ist ein sowohl ein Authentifizierungsverfahren als auch ein Schlüsselaustauschverfahren. Die Funktionsweise von RSA habe ich im ersten Bild detailliert erläutert.
• DH ist eine Abkürzung für das Diffie Hellman Verfahren. Hierbei sendet der Server dem Client fixe Diffie Hellman Parameter aus denen das Pre-Master-Secret berechnet werden kann. Im reinen Diffie Hellman Verfahren generiert der Client und der Server jedes mal das selbe Pre-Master-Secret.

Kurzer Abriss zur Funktionsweise des Diffie Hellman Verfahrens:

1. Bob und Alice wollen verschlüsselte Nachrichten austauschen.
2. Im ersten Schritt überlegen sich Alice und Bob eine ungerade Primzahl p und eine ihrer Primitivwurzeln a. Die Zahlen werden offen über eine unsichere Leitung kommuniziert.
3. Anschließend generiert Alice einen x bezeichneten Zufallswert: 2 <= x <= p - 1
4. Alice errechnet ax (mod p) = A und sendet A an Bob.
5. Bob generiert im nächsten Schritt einen y bezeichneten Zufallswert: 2 <= y <= p - 1
6. Bob errechnet ay (mod p) = B und sendet B an Bob.
7. Bob errechnet (A)y (mod p) = (ax)y (mod p).
8. Anschließend errechnet Alice (B)x (mod p) = (ay)x (mod p) = (ax)y (mod p)!
9. Der private Schlüssel ist hiermit (ax)y (mod p)

Trotz des Austausches über eine vollkommen unsichere Leitung haben Bob und Alice nun einen Schlüssel errechnet, den nur die beiden kennen.

• DHE steht für Ephemeral Diffie Hellmann, eine Variation von DH, bei dem keine fixen Diffie Hellman Parameter versendet werden, sondern temporäre. Dieses Verfahren bietet Perfect Forward Secrecy.
• ECDHE ist DHE mit elliptic key cryptography kombiniert, es bietet ebenfalls Perfect Forward Secrecy.

TLS unterstützt weiterhin drei verschiedene Authentifizierung-Verfahren:

• Nur der Server authentisiert sich gegenüber dem Client (Standard),
• nur der Client authentisiert sich gegenüber dem Server oder
• beide authentisieren sich gegenseitig.

Zur Authentifizierung stehen verschiedene Möglichkeiten bereit. In der oberen Graphik handelt es sich hierbei um die Schritte 5-9.

Das Verschlüsselungsverfahren wird genutzt, um die "Nutz"-Daten nach dem TLS Handshake zu versenden. Mit Hilfe dieses Verfahrens wird also beispielsweise der Inhalt einer Webseite übertragen.

Eine Liste der unterstützten Cipher-Suites des eigenen Browsers kann auf einer Webseite der Uni Hannover abgerufen werden.

Cipher-Suites, die nicht mehr genutzt werden sollten

Die Beantwortung der Frage ist leider ein kleines Dilemma: Wirklich gut geschützt ist ein Nutzer aktuell nur mit dem relativ "neuem" TLS 1.2 Standard, der jedoch sowohl auf der Client, als auch auf der Serverseite nur vereinzelt bereits implementiert worden ist:

In der Presse der letzten Tage und Woche lässt sich folgendes herauslesen:

• RC4 als Verschlüsselungsalgorithmus ist nicht mehr vertrauenswürdig (RC4-Weakness).
• Algorithmen im CBC Modus sind anfällig für BEAST Attacken.
• CRIME oder BREACH Attacken ermöglichen Session Hijacking.
• Unternehmen werden aufgefordert, ihren Private Key für die Verschlüsselung offenzulegen.
• Bruce Schneier, einer der bekanntesten Kryptografie-Experten, der ebenfalls Zugriff auf die Snowden Dokumente hatte, rät von der Nutzung von Algorithmen ab, die auf Elliptic Key Cryptography basieren.

Das Problem mit BEAST Attacken bzw. RC4: Bis zu Version TLS 1.1 ist man gezwungen, sich entweder für einen Algorithmus zu entscheiden, der als äußerst Schwach gilt (RC4) oder als Anfällig für BEAST Attacken (z.B. AES-CBC). Erst mit der Version TLS 1.2 wurde der AES-GCM Mode implementiert, der nicht mehr anfällig für BEAST Attacken ist (auch der CBC Mode ist ab TLS 1.2 übrigens nicht mehr anfällig).

Konsequenzen der TLS Schwachstellen

In Konsequenz auf die bekannt gewordenen TLS Schwachstellen ist die wichtigste Regel, wann immer es geht, TLS 1.2 zu nutzen. SSL 3.0 sollte in Browser deaktiviert werden.

Die Cipher Suites sollten wie folgt beschränkt werden:

• DHE als Schlüsselaustauschverfahren, bevorzugt vor ECDHE.
• RSA als Authentifizierungsverfahren, bevorzugt vor ECDSA.
• Als Verschlüsselungsverfahren bleiben AES-256 oder AES-128 bzw CAMELLIA-256 oder CAMELLIA-128 übrig.

Die empfohlene Cipher-Suite ab TLS Version 1.2 sollte somit folgende sein:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Diese Empfehlung wurde vor kurzem auch von der IETF herausgegeben: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00#section-4. Für Serveradministratoren ist das gesamte Dokumente äußerst lesenswert.

In Firefox lassen sich die Verfahren auf der Seite "about:config" unter "security.ssl3" konfigurieren. Um die Sicherheit weiter zu erhöhen sollte die minimale TLS Version auf 1.0 festgelegt und die TLS Version 1.1 unter Firefox aktiviert werden (ebenfalls auf der Seite about:config):

• security.tls.version.min auf 1
• security.tls.version.max auf 2

Weitere Schwachstellen, die nicht so einfach zu lösen sind

Vollkommen ungelöst bleiben jedoch folgende Risiken:

• Die Implementierung von Hintertüren in Anwendungen und Diensten, zu denen amerikanische Unternehmen per Gesetz gezwungen werden können.
• Es gibt unzählige Zertifizierungsstellen, die gültige Zertifikate ausstellen können, die sich für Man-In-The-Middle Angriffe nutzen lassen können.
• Absichtliche Designschwächen in Algorithmen. Diesen Verdacht gibt es aktuell bei der Elliptic Curve Cryptography.

Zusammenfassung

TLS bzw. SSL wie es früher genannt wurde, bietet weiterhin, bei korrekter Implementierung und Anwendung, ein sehr hohes Maß an Sicherheit. Es ist bisher kein Verfahren bekannt, dass eine sicher konfigurierte TLS Verbindung knacken bzw. mitlesen könnte.

Bildnachweis:

• Beitragsbild: © momius - Fotolia.com