SSL/TLS-Prüfung Clients/Server

1. Einleitung

Das Protokoll Transport Layer Security (TLS), welches umgangssprachlich nach wie vor auch oft als Secure Sockets Layer (SSL) bezeichnet wird, stellt eine Grundlage der sicheren Client-Server-Kommunikation im Internet dar. Das Protokoll wurde 1999 unter dem Namen SSL veröffentlicht. Ab Version 3.1 des Protokolls wurde dieses unter dem Namen TLS weiterentwickelt. SSL Version 3.1 entspricht daher TLS 1.0.

TLS spielt vor allem in Zusammenhang mit dem Protokoll HTTP eine zentrale Rolle. Durch die Anwendung von HTTP über TLS können sichere HTTPS-Verbindungen zwischen Web-Servern und Web-Browsern etabliert werden. Über diese sicheren Verbindungen können Daten verschlüsselt, authentifiziert und integritätsgesichert ausgetauscht werden. Dementsprechend kommt TLS in Verbindung mit HTTPS vor allem bei sicherheitskritischen webbasierten Anwendungen häufig zum Einsatz. Beispiele dafür sind die Bereiche E-Government oder E-Banking. Damit ist TLS auch für Behörden von zentraler Bedeutung.

In einer Kurzstudie [1] wurden von A-SIT österreichische gv.at-Domänen in Bezug auf deren Verwendung der Protokolle TLS und HTTPS analysiert. Dabei konnten einige Domänen identifiziert werden, die Cipher-Suites und Schlüssellängen verwenden, die nicht diesen Empfehlungen entsprechen.

Die durchgeführte Kurzstudie untermauert damit die Annahme, dass eine generelle Notwendigkeit für Empfehlungen zur Verwendung und Konfiguration der TLS-Technologie im Behördenumfeld besteht. Dieser Notwendigkeit wird durch das vorliegende Dokument nachgekommen, indem dieses Empfehlungen zur serverseitigen Verwendung und Konfiguration des TLS-Protokolls zusammenfasst. Besonderes Augenmerk wird dabei auf die Auswahl geeigneter Cipher-Suites gelegt, welche kryptographische Algorithmen und Schlüssellängen definieren, die zur Absicherung von TLS-Verbindungen zur Anwendung kommen. Damit baut dieses Dokument auf der von A-SIT erstellten Studie auf, in der allgemeine Empfehlungen zur Verwendung kryptographischer Algorithmen und Schlüssellängen gegeben wurden [2].

Die Struktur des vorliegenden Dokuments entspricht im Wesentlichen der Methodik, die zur Erarbeitung den eben erwähnten Empfehlungen verfolgt wurde. In Abschnitt 2 werden zunächst grundlegende Begriffe und Konzepte, die im Rahmen von TLS relevant sind, eingeführt und erläutert. Im Speziellen wird auf die Rolle und Verwendung von Cipher-Suites eingegangen. Im Anschluss wird in Abschnitt 3 die Verfügbarkeit verschiedener Cipher-Suites auf aktuellen Web-Browsern und durch verbreitete Web-Server-Software untersucht. Auf diese Weise werden jene Cipher-Suites identifiziert, die über eine entsprechend breite Unterstützung verfügen. In Abschnitt 4 werden potentielle Cipher-Suites anhand definierter Kriterien in Bezug auf deren Sicherheitsniveau untersucht. Aus den Ergebnissen dieser Untersuchungen werden in Abschnitt 5 Empfehlungen zur Verwendung von SSL/TLS gegeben. In Abschnitt 6 wird schließlich noch das von A-SIT entwickelte Tool zur Überprüfung von SSL/TLS-Konfigurationen vorgestellt.

2. Grundlagen

Über TLS können sichere Verbindungen zwischen einem Server und einem Client hergestellt werden. Bei Verwendung im Zusammenhang mit HTTP kann so etwa ein sicherer Datenaustausch zwischen Web-Servern und Web-Browsern gewährleistet werden. Die Absicherung des Kommunikationspfades zwischen Server und Client basiert auf kryptographischen Methoden. Diese bieten im Rahmen von TLS folgende Features:

• Authentifizierung des Servers

• Authentifizierung des Clients (optional und im Web-Kontext eher unüblich)

• Verschlüsselung der Nutzdaten

• Integritätssicherung der Nutzdaten

Da für die Umsetzung dieser Features unterschiedliche kryptographische Methoden benötigt werden, müssen sich Server und Client vor der eigentlichen Datenübertragung auf eine Menge zu verwendender Methoden einigen. Diese Menge wird als Cipher-Suite bezeichnet und im Rahmen des Verbindungsaufbaus ausgehandelt. Dies ist in Abbildung 1, welche einen vereinfachten TLS-Verbindungsaufbau zeigt, dargestellt.

Abbildung 1. TLS-Verbindungsaufbau (adaptiert von [3]). Im ersten Schritt (Client Hello) übermittelt der Client an den Server eine nach Priorität geordnete Liste unterstützter Cipher-Suites. Aus dieser Liste wählt der Server anhand definierter Prioritäten eine geeignete Cipher-Suite aus. Diese wird dem Client im zweiten Kommunikationsschritt (Server Hello) mitgeteilt.

Cipher-Suites können über eine ID bestehend aus zwei Bytes identifiziert werden. Üblich ist auch die Repräsentation in Form einer Zeichenkette, aus der die in der Cipher-Suite enthaltenen Algorithmen und Schlüssellängen ersichtlich sind. Dabei haben sich mit der IANA-Notation und der OpenSSL-Notation zwei unterschiedliche Formate etabliert. Beispielsweise wird die Cipher-Suite mit der ID 0xC013 durch folgende Bezeichnungen beschrieben:

• IANA-Notation: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

• OpenSSL-Notation: ECDHE-RSA-AES128-SHA

Aus Gründen der Einheitlichkeit und im Sinne der Unabhängigkeit von einer bestimmten TLS-Implementierung werden in diesem Dokument Cipher-Suites im Folgenden immer in IANA-Notation angeführt.

Über den Namen einer Cipher-Suite werden, wie aus obigem Beispiel ersichtlich, vier Algorithmen identifiziert. Der erste Algorithmus (im obigen Beispiel ECDHE) bezeichnet das für den Schlüsselaustausch zu verwendende Verfahren. Der zweite Algorithmus (im obigen Beispiel RSA) gibt an, welches Verfahren für die Authentifizierung des Servers verwendet werden muss. Der dritte angegebene Algorithmus beschreibt das Verfahren zur Verschlüsselung von Nutzdaten. Im obigen Beispiel ist dies AES mit 128 Bit Schlüssellänge im CBC-Verfahren. Der vierte Algorithmus (im obigen Beispiel SHA) bezeichnet schließlich das zu verwendende Verfahren zur Gewährleistung der Integrität der übertragenen Nutzdaten.

Da über die zwischen Client und Server ausgehandelte Cipher-Suite die zur Kommunikationsabsicherung über TLS verwendeten kryptographischen Algorithmen festgelegt werden, ist die Wahl einer geeigneten Cipher-Suite von entscheidender Bedeutung. Die Wahl der Cipher-Suite kann bei der Verwendung von TLS im Rahmen von HTTPS prinzipiell auf zweierlei Art und Weise beeinflusst werden:

• Der Web-Browser (bzw. die Benutzerin oder der Benutzer) kann die Verwendung sicherer Cipher-Suites erzwingen, indem dieser im Rahmen des Kommunikationsaufbaus (Client Hello) nur jene Cipher-Suites vorschlägt, die den Sicherheitsanforderungen entsprechen.

• Der Web-Server kann über eine interne Prioritätenliste im Zuge des Verbindungsaufbaus (Server Hello) jene Cipher-Suites auswählen, die den gegebenen Sicherheitsanforderungen entsprechen.

In der Praxis ist der erste Ansatz nur schwer umsetzbar, da Benutzerinnen und Benutzer in der Regel nicht über das nötige Know-How verfügen, um unterstützte Cipher-Suites im Web-Browser entsprechend zu konfigurieren. In den meisten Fällen werden Web-Browser daher mit jenen Cipher-Suites betrieben, die vom Browser-Hersteller konfiguriert wurden.

Ziel dieses Dokuments ist es daher, Betreibern von Servern in Form von Empfehlungen eine Grundlage zu liefern, welche Cipher-Suites serverseitig für eine priorisierte Verwendung konfiguriert werden sollen. Für die Erarbeitung dieser Empfehlungen werden dabei folgende Aspekte berücksichtigt:

• Sicherheit: Es werden nur jene Cipher-Suites empfohlen, die ein geeignetes Sicherheitsniveau gewährleisten können.

• Verbreitung und Unterstützung: Es werden primär jene Cipher-Suites empfohlen, die in aktuellen Web-Browsern eine breite Unterstützung finden und auch von gängigen TLS-Implementierungen unterstützt werden.

Neben der Empfehlung konkreter Cipher-Suites werden in diesem Dokument außerdem weitere relevante Empfehlungen zur Konfiguration und zur Verwendung von SSL/TLS gegeben.

3. Analyse der Verfügbarkeit und Unterstützung

In diesem Abschnitt wird die Verfügbarkeit und Unterstützung verschiedener Cipher-Suites durch aktuelle Web-Browser und Web-Server analysiert. Dazu werden zunächst potentielle Cipher-Suites gesammelt und aus diesen jene identifiziert, die sowohl durch Browser als auch durch Web-Server breit unterstützt werden.

3.1. Identifikation potentieller Cipher-Suites

Um eine Grundlage für eine systematische Analyse und Identifikation geeigneter und zu empfehlender Cipher-Suites zu schaffen, wird in einem ersten Schritt eine weitgehend erschöpfende Liste verfügbarer Cipher-Suites erstellt. Dazu werden unterschiedliche Quellen herangezogen:

• Relevante Standards wie zum Beispiel:

o RFC 5289 [4] o RFC 4492 [5] o RFC 6460 [6] o RFC 5246 [7]

• Dokumentationen zu existierenden TLS-Implementierungen wie:

o OpenSSL [8] o Microsofts SChannel [9]

• Einschlägige Web-Ressourcen wie beispielsweise:

o Qualys SSL Labs [10] o The Sprawl [11]

• Einschlägige Analyse-Tools wie zum Beispiel:

o A-SIT SSL/TLS-Prüftool [12] o Qualys SSL Server Test [13] o Qualys SSL Browser Test [14] Aus diesen Quellen kann eine weitgehend vollständige Liste von derzeit definierten Cipher-Suites erstellt werden. Für jede dieser Cipher-Suites werden in weiterer Folge folgende Daten erhoben:

• ID

• Name

• SSL/TLS-Protokoll

• Verfahren für den Schlüsselaustauch

• Verfahren für die Authentifizierung

• Verschlüsselungsalgorithmus

• Schlüssellänge des Verschlüsselungsalgorithmus

• MAC-Verfahren

Die resultierende Liste an Cipher-Suites inklusive deren Eigenschaften kann Anhang A dieses Dokuments entnommen werden.

3.2. Analyse der Verbreitung identifizierter Cipher-Suites

Die Identifizierung potentieller Cipher-Suites ergibt eine Liste von über 250 Cipher-Suites. In der Praxis ist jedoch nur eine Untermenge dieser Cipher-Suites von tatsächlicher Bedeutung. Viele der in Anhang A angeführten Cipher-Suites werden von aktuellen Web-Browsern nicht unterstützt.

Um jene Cipher-Suites, die auch in der Praxis von Bedeutung sind, zu identifizieren, wird für jede in Anhang A angeführte Cipher-Suite deren Unterstützung durch aktuelle Web-Browser und Web-Server untersucht. Dabei wird der Fokus auf die laut W3Counter [15] am weitesten verbreiteten Web-Browser Google Chrome, Mozilla Firefox, Microsoft Internet Explorer und Apple Safari gelegt. Von jeder Browser-Software wird jeweils die aktuellste Version für eine spezielle Plattform untersucht. Hier ist zu beachten, dass sich auf unterschiedlichen Plattformen und Betriebssystemen mitunter Unterschiede in den unterstützten Cipher-Suites ergeben können.

Ähnlich wird auch in Bezug auf Web-Server vorgegangen. Laut Netcraft [16] sind aktuell die Web-Server Apache, Microsoft IIS, nginx und Google Web Server (GWS) am weitesten verbreitet. Dementsprechend wird der Fokus zunächst auf diese Web-Server gelegt. Daneben wird auch Server-Software der Firmen IBM und Oracle analysiert. Von IBM wurde anhand verfügbarer Dokumentation [23] untersucht, welche Cipher-Suites von der Web-Server Software Websphere, bzw. von der von dieser Software genutzten Komponente IBM Global Security Kit (GSKit), unterstützt werden. Oracle bietet ein breites Portfolio an Server-Komponenten, für die Cipher-Suites konfiguriert werden können [25]. Für einige Oracle-Produkte enthält die zugehörige Dokumentation eine explizite Auflistung unterstützter Cipher-Suites [27], für andere Server-Lösungen wird in Bezug auf unterstützte Cipher-Suites auf die aktuelle Java Secure Socket Extension (JSSE) verwiesen [26]. In diesem Dokument wird die aktuelle JSSE-Version als relevante SSL/TLS-Implementierung angenommen. Unterstützte Cipher-Suites können der zugehörigen Dokumentation entnommen werden [24]. Obwohl sowohl Apache als auch nginx theoretisch unterschiedliche TLS-Implementierungen unterstützen, wird für die vorgenommene Analyse eine Verwendung von OpenSSL angenommen, da dies die derzeit meistverwendete TLS-Implementierung ist. Auch hier wird stets die aktuellste Version der Web-Server-Software bzw. der verwendeten TLS-Implementierung analysiert.

Die Unterstützung von Cipher-Suites auf unterschiedlichen Web-Browsern und Web-Servern wird auf zweierlei Art und Weise evaluiert. Zunächst werden – wo verfügbar – vorhandene Produktdokumentationen analysiert. Die auf diese Weise erhaltenen Angaben werden zusätzlich über einschlägige Tools [12][13][14] überprüft. Das Resultat dieser Analyse ist in Anhang B dargestellt, wo für jede identifizierte Cipher-Suite unterstützende Web-Browser und Web-Server angeführt sind. Anhang B enthält nur jene Cipher-Suites, die zumindest von einem der analysierten Browser oder Web-Server unterstützt werden. Da unterstützte Cipher-Suites sowohl auf Web-Servern als auch auf Web-Browsern konfiguriert und verändert werden können, können die in Anhang B gezeigten Daten punktuell von tatsächlich im Einsatz befindlichen Systemen abweichen. Speziell sind aus Gründen der Vollständigkeit in Anhang B auch jene Cipher-Suites gelistet, die vom Hersteller standardmäßig deaktiviert sind, jedoch prinzipiell unterstützt und damit auch aktiviert werden können.

Anhang B zeigt die Unterstützung von Cipher-Suites exemplarisch für die vier oben genannten Web-Browser auf bestimmten Plattformen. Detailliertere Informationen zur Unterstützung von Cipher-Suites auf verschiedenen (auch mobilen) Web-Browsern können [14] entnommen werden. Insgesamt zeigt sich, dass wie erwartet die aktuell verfügbaren Web-Browser der limitierende Faktor sind. Cipher-Suites, die von Web-Browsern unterstützt werden, sind auch auf den meisten Web-Servern verfügbar. Umgekehrt wird jedoch nur ein Bruchteil aller von Web-Servern, bzw. deren TLS-Implementierungen, unterstützten Cipher-Suites auch auf Web-Browsern unterstützt.

4. Analyse der Sicherheit

Um potentielle Cipher-Suites in Bezug auf deren Sicherheit zu evaluieren, werden im Folgenden Sicherheitskriterien definiert und motiviert. Diese werden im Anschluss auf potentielle Cipher-Suites angewendet. Dadurch können schlussendlich jene Cipher-Suites extrahiert werden, die ein geeignetes Maß an Sicherheit aufweisen.

4.1. Kriterien

In der Praxis muss bei der Konfiguration unterstützter Cipher-Suites ein Balanceakt zwischen Sicherheit und breiter Unterstützung gefunden werden. Als sehr sicher eingestufte Cipher-Suites werden von vielen Web-Browsern oft (noch) nicht unterstützt. Gleichzeitig bieten breit unterstützte Cipher-Suites oft nicht (mehr) das geforderte Sicherheitsniveau. Durch automatische Updates wird von Seiten der Browser-Hersteller versucht, dieses Problem zu minimieren. Jedoch kann in der Praxis nicht immer davon ausgegangen werden, dass der Nutzer immer die aktuellste Version eines Browsers benutzt. Erschwerend kommt hinzu, dass eine Vielzahl mobiler Endgeräte weit über den vom Hersteller gewollten Produktlebenszyklus hinaus verwendet werden. Dadurch ergibt sich eine nicht zu vernachlässigende Anzahl an Endgeräten, welche nicht dem aktuellen Stand der Entwicklung entsprechen. Exemplarisch wird hier auf die aktuelle Verteilung unterschiedlicher Android-Versionen [29] verwiesen. Folglich kann auch keine breite Unterstützung für Cipher-Suites mit höchstmöglichem Sicherheitsniveau angenommen werden.

Die Anforderungen an die Sicherheit von Cipher-Suites können sich je nach Anwendungsszenario unterscheiden. Sicherheitskritische Anwendungen werden in der Wahl zulässiger Cipher-Suites in der Regel restriktiver sein als weniger kritische Anwendungen. Um verschiedene Anwendungsfälle mit unterschiedlichen Sicherheitsanforderungen abdecken zu können, werden in diesem Abschnitt zwei Kategorien von Kriterien definiert.

• MUSS-Kriterien: Diese müssen in jedem Fall und unabhängig vom konkreten Anwendungsszenario eingehalten werden.

• SOLL-Kriterien: Diese müssen für weniger kritische Anwendungsfälle nicht eingehalten werden, sehr wohl jedoch in Szenarien mit erhöhten Sicherheitsanforderungen.

MUSS- und SOLL-Kriterien für Cipher-Suites werden in den folgenden Unterabschnitten näher definiert. Diese greifen auch die in RFC 7525 [28] definierten Empfehlungen auf.

4.1.1. MUSS-Kriterien

• Die Cipher-Suite MUSS Verschlüsselung unterstützen. Der NULL-Cipher ist nicht erlaubt. Nur so ist sichergestellt, dass die Vertraulichkeit der über die TLS-Verbindung übertragenen Daten gewährleistet bleibt.

• Die Cipher-Suite MUSS einen sicheren Verschlüsselungsalgorithmus verwenden. Schwache Algorithmen wie RC2, RC4, DES, IDEA, GHOST28147 oder SEED sind nicht zulässig. Nur so ist sichergestellt, dass die Vertraulichkeit der über die TLS-Verbindung übertragenen Daten gewährleistet bleibt.

• Die Cipher-Suite MUSS Authentifizierung unterstützen. Anonyme Cipher-Suites sind nicht zulässig. Nur so kann der Client den Server eindeutig authentifizieren.

• Die unterstützte Authentifizierung MUSS zertifikatsbasiert sein. PSK-Varianten sind nicht zulässig. Nur so kann der Client den Server sicher authentifizieren.

• Die Cipher-Suite MUSS Perfect Forward Secrecy (PFS) unterstützen. Nur so ist sichergestellt, dass über TLS übertragene Daten auch im Falle einer späteren Kompromittierung des Schlüssels weiter geschützt bleiben [1] .

4.1.2. SOLL-Kriterien

• Die Cipher-Suite SOLL TLS 1.2 zugeordnet sein.

• Die Cipher-Suite SOLL AES als Verschlüsselungsalgorithmus verwenden. Damit wird für die Verschlüsselung von Daten ein bewährter und standardisierter Algorithmus verwendet.

• Die Cipher-Suite SOLL einen SHA2-basierten Ansatz oder GCM zur Integritätssicherung verwenden. SHA1 SOLL vermieden werden. Damit wird der Einsatz eines potentiell schwachen Hash-Algorithmus verhindert.

4.2. Anwendung der Kriterien auf potentielle Cipher-Suites

Durch die Anwendung der definierten Sicherheitskriterien kann schließlich eine finale Menge relevanter Cipher-Suites erarbeitet werden. Die erhaltenen Cipher-Suites können in zwei Kategorien unterteilt werden.

• Cipher-Suites für sicherheitskritische Anwendungsszenarien erfüllen alle MUSS- und alle SOLL-Kriterien.

1 Prinzipiell sind Anwendungsfälle denkbar, in denen PFS keine notwendige Anforderung ist. Für Anwendungen im Behördenumfeld, an das sich dieses Dokument richtet, ist die durchgehende Verwendung von PFS jedoch sinnvoll, zumal eine breite Unterstützung entsprechender Cipher-Suites auf aktuellen Web-Browsern bereits gegeben ist. Die Unterstützung von PFS wird in diesem Dokument daher als MUSS-Kriterium definiert.

• Cipher-Suites für weniger kritische Anwendungsszenarien erfüllen alle MUSS-Kriterien.

Die auf diese Weise identifizierten Cipher-Suites sind in Anhang C tabellarisch angeführt.

5. Empfehlungen

Basierend auf den Resultaten der durchgeführten Analysen kann für die Verwendung und serverseitige Konfiguration von SSL/TLS eine Reihe von Empfehlungen formuliert werden. Diese Empfehlungen werden in den folgenden Unterabschnitten gegeben.

5.1. Empfohlene Mindestschlüssellängen

Detaillierte Empfehlungen zu kryptographischen Algorithmen und Schlüssellängen wurden in einem getrennten Dokument formuliert [2]. Aus diesem können folgende Richtwerte übernommen werden:

• Für symmetrische Verfahren kann derzeit bei Verwendung eines entsprechenden Algorithmus eine Mindestschlüssellänge von 100 Bit empfohlen werden. Damit ergeben sich bei Verwendung von üblichen Algorithmen wie 3DES oder AES tatsächliche empfohlene Schlüssellängen von 112 (3DES) bzw. 128 (AES) Bit.

• Für asymmetrische Verfahren kann eine Mindestschlüssellänge von 1500 Bit für bestehende bzw. von 2000 Bit für neue Systeme empfohlen werden. Für RSA kann damit eine Schlüssellänge von 1536 Bit bzw. von 2048 Bit als geeignet angesehen werden. Entsprechend kann für kryptographische Verfahren basierend auf elliptischen Kurven wie ECDSA eine Schlüssellänge von 192 Bit bzw. 224 Bit empfohlen werden.

• Für Hash-Verfahren wird aktuell eine Länge von 155 bis 224 Bit empfohlen. Damit ist etwa SHA-1 mit einer Länge von 160 Bit bereits am unteren Ende des empfohlenen Spektrums. Stattdessen kann die Verwendung anderer Hash-Algorithmen wie Vertreter der SHA2-Familie empfohlen werden.

• Seit Bekanntwerden der Logjam-Attacke [30] wird bei der Verwendung von Diffie-Hellman Cipher-Suites (Präfix DHE) in jedem Fall eine Parameterlänge entsprechend der Mindestschlüssellänge asymmetrischer Verfahren empfohlen. Unabhängig davon wird die Verwendung von selbstgenerierten Diffie-Hellman Gruppen empfohlen. Weitere Details und eine schrittweise Anleitung zu entsprechender Konfiguration verbreiteter Webserver sind unter [31] verfügbar.

5.2. Empfohlene Versionen von SSL und TLS

Es wird empfohlen, SSL 2.0 unter keinen Umständen zu verwenden, da diese Version seit längerer Zeit Schwachstellen aufweist. Es wird außerdem empfohlen, SSL 3.0 nicht mehr zu verwenden [2] . Die niedrigste SSL/TLS-Version, die verwendet und serverseitig unterstützt werden sollte ist TLS 1.0. Niedrigere Versionen sollten serverseitig deaktiviert werden, um mögliche Risiken, die sich durch einen Fallback auf SSL 2.0 oder SSL 3.0 ergeben können, auszuschließen. Generell wird empfohlen, stets die höchst mögliche TLS-Version (derzeit TLS 1.2) zu verwenden. Niedrigere TLS-Versionen wie TLS 1.0 oder TLS 1.1 sollten wenn nötig nur aus Kompatibilitätsgründen verwendet werden. Speziell bei der Verwendung von TLS 1.0 muss auf eine korrekte Konfiguration des Servers geachtet werden, um potentielle Sicherheitsprobleme ausschließen zu können.

5.3. Empfohlene Cipher-Suites

Es werden drei Kategorien von Cipher-Suites empfohlen. Die erste Kategorie enthält Cipher-Suites, die ein hohes Maß an Sicherheit bringen und eine adäquate Unterstützung auf aktuellen Web-Browsern aufweisen. Die zweite Kategorie enthält ebenfalls Cipher-Suites mit hoher Sicherheit, die derzeit auf aktuellen Web-Browsern jedoch noch nicht breit unterstützt werden. Die 2 Durch Vermeidung von SSL 3.0 kann etwa der kürzlich entdeckten POODLE-Schwachstelle [33] entgegengewirkt werden.

dritte Kategorie enthält schließlich Cipher-Suites mit nach wie vor ausreichender Sicherheit, die aber eine breitere Unterstützung auf aktuellen Web-Browsern bieten. Die geeignete Kategorie kann je nach Anwendungsfall gewählt werden. In jedem Fall sollte stets die höchstmögliche Anzahl an Cipher-Suites serverseitig unterstützt werden, um ein ausreichendes Maß an Kompatibilität mit verschiedenen Clients zu gewährleisten.

5.3.1. Cipher-Suites mit hoher Sicherheit und adäquater Unterstützung

Die folgende Tabelle enthält empfohlene Cipher-Suites mit hoher Sicherheit und adäquater Unterstützung durch aktuelle Clients. Diese Cipher-Suites können jederzeit bedenkenlos unterstützt werden.

Tabelle 1. Empfohlene Cipher-Suites mit hoher Sicherheit und guter Browser-Unterstützung.

5.3.2. Cipher-Suites mit hoher Sicherheit und beschränkter Unterstützung

Die folgende Tabelle enthält empfohlene Cipher-Suites mit hoher Sicherheit, jedoch beschränkter Unterstützung durch aktuelle Clients. Auch diese Cipher-Suites können jederzeit bedenkenlos unterstützt werden. Neben diesen sollten jedoch noch weitere Cipher-Suites unterstützt werden, um ein entsprechendes Maß an Client-Kompatibilität zu gewährleisten.

Tabelle 2. Empfohlene Cipher-Suites mit hoher Sicherheit und geringer Browser-Unterstützung.

5.3.3. Cipher-Suites mit ausreichender Sicherheit und breiter Unterstützung

Die folgende Tabelle enthält empfohlene Cipher-Suites mit ausreichender Sicherheit und breiter Unterstützung. Diese Cipher-Suites sollten zusätzlich zu den oben empfohlenen Cipher-Suites mit hoher Sicherheit verwendet werden, wenn eine breite Unterstützung auf möglichst vielen (vor allem älteren) Web-Browsern Priorität hat.

Tabelle 3. Empfohlene Cipher-Suites mit ausreichender Sicherheit und breiter Unterstützung.

Bei der Konfiguration unterstützter Cipher-Suites ist auch auf deren Priorisierung zu achten. Es wird empfohlen, sichere Cipher-Suites (Tabelle 1 und Tabelle 2) priorisiert zu konfigurieren, sodass diese bevorzugt verwendet werden, falls diese vom Web-Browser unterstützt werden. Nur wenn keine gemeinsame Cipher-Suite aus Tabelle 1 oder Tabelle 2 zwischen Web-Server und Web-Browser ausgehandelt werden kann, soll auf Cipher-Suites aus Tabelle 3 zurückgegriffen werden. Andere als die in den obigen Tabellen gelisteten Cipher-Suites sollen nicht verwendet werden.

5.4. Empfohlene Transferformate

In Folge werden Formate für den Transfer von Zertifikaten oder privaten Schlüsseln empfohlen. Bei der Speicherung, Übermittlung und Verwahrung privater Schlüssel ist zu beachten, dass dies ein kritisches Element hinsichtlich der Sicherheit darstellt. Es sind besondere Sicherheitsmaßnahmen vorzusehen, um eine Kompromittierung effektiv zu verhindern. Die hier definierten Empfehlungen haben keine Relevanz in Bezug auf die Sicherheit dieser Elemente, sondern definieren lediglich Formate, die einen Austausch zwischen verschiedenen gängigen Plattformen und Produkten unterstützen.

Für die Speicherung privater Schlüssel wird das Format PKCS#12 [17] empfohlen. Zusätzlich wird für die Speicherung der Server-Zertifikate das Format PKCS#7 [18] empfohlen. In diesem Format sind Zertifikate in einer festgelegten ASN.1-Struktur und nach den Distinguished Encoding Rules (DER) kodiert abgespeichert. Eine zusätzliche BASE64-Kodierung ist optional möglich, jedoch nicht notwendig. Es wird empfohlen, den gesamten Zertifizierungspfad inklusive des Root-Zertifikats zu speichern.

5.5. Empfehlungen zur Konfiguration und zum Betrieb von Web-Servern

Als Ergänzung zu den bisher gemachten Empfehlungen sind noch einige weitere Aspekte für die sichere Verwendung von SSL/TLS zu beachten. Diese werden im Folgenden angeführt.

• Es wird empfohlen, beim Betrieb von TLS-Implementierungen wie OpenSSL stets deren aktuellste verfügbare Version zu verwenden. Die Heartbleed- [19] und die FREAK-Sicherheitslücke [20] zeigten, dass auch TLS-Implementierungen von Schwachstellen betroffen sein können. Eine im September 2015 veröffentlichte Seitenkanalattacke [22] dokumentiert, dass Implementierungsfehler, die nicht unmittelbar TLS-Implementierungen selbst betreffen, auch zu in der Praxis ausnutzbaren Sicherheitslücken führen können. Jedoch stellt auch in diesem Zusammenhang eine Aktualisierung der eingesetzten TLS-Implementierung eine ausreichende Gegenmaßnahme dar. Zusammenfassend lässt sich festhalten, dass nur durch die ständige Aktualisierung der verwendeten Bibliotheken und Implementierungen ein Schutz gegen bekannte Schwachstellen erreicht werden kann.

• Es wird empfohlen, bei der Konfiguration von Web-Servern, die TLS unterstützen, auf gängige Best Practices zurückzugreifen. Hier ist zu beachten, dass sich diese mitunter im Laufe der Zeit ändern können. So gilt beispielsweise erst seit Bekanntwerden der CRIMEoder BREACH-Attacke [21] die serverseitige Deaktivierung der Datenkompression bei Verwendung von TLS-Verbindungen als Best Practice.

Neben den hier definierten Empfehlungen gibt das Dokument Applied Crypto Hardening der Organisation bettercrypto.org [32] weitere Empfehlungen und Anleitungen zur richtigen und sicheren Konfiguration und zum Betrieb von Web-Servern.

6. SSL/TLS-Prüftool

Als Ergänzung zu den in diesem Dokument definierten Empfehlungen und als Unterstützung bei der Konfiguration von Web-Servern wurde ein Tool entwickelt, über das TLS-Konfigurationen von Web-Servern und Web-Browsern überprüft werden können. Das Tool erlaubt die Prüfung bezüglich dieser Empfehlungen auf http://demoapps.a-sit.at/ssl-tool/ bzw. steht unter [12] auch zum Download bereit und ergänzt bestehende einschlägige Tools wie jene, die unter www.ssllabs.com bereitgestellt werden.

7. Fazit

SSL/TLS ist eine zentrale und breit verwendete Technologie für den sicheren Datenaustausch im Internet. Verbindungen, die über SSL/TLS abgesichert sind, sind prinzipiell in der Lage, die Authentizität, Integrität und Vertraulichkeit kommunizierter Daten zu gewährleisten. Voraussetzung dafür ist jedoch eine korrekte Verwendung des Protokolls bzw. die korrekte Konfiguration der Protokoll-Implementierung.

Um Behörden diesbezüglich zu unterstützen, wurden im vorliegenden Dokument diverse Empfehlungen zur Verwendung von SSL/TLS gegeben. Hauptaugenmerk wurde dabei auf die Wahl geeigneter kryptographischer Algorithmen, Schlüssellängen, Protokollversionen und Cipher-Suites gelegt. Daneben wurden einige allgemeine Empfehlungen definiert, die Behörden bei der sicheren Verwendung von SSL/TLS unterstützen können.

Neben der Erarbeitung und Definition einschlägiger Empfehlungen wurde zudem ein Tool entwickelt und bereitgestellt, das bei der Analyse von SSL/TLS-Servern und entsprechender Clients wie Web-Browsern hilfreich sein kann. Über dieses Tool können bestehende SSL/TLS Konfigurationen wie etwa konfigurierte und unterstützte Cipher-Suites einfach überprüft werden. Zusammen mit den definierten Empfehlungen bietet dieses Tool somit Behörden eine Unterstützung bei der Verwendung und Konfiguration von SSL/TLS.

Referenzen

[1] Peter Teufl, Andreas Reiter, Alexander Marsalek, Sandra Kreuzhuber: Kurzstudie HTTPS (SSL, TLS) Analyse österreichischer GV.AT Domänen. A-SIT. 2014.

[2] Thomas Zefferer: Sicherheitsempfehlungen für Behörden – Teil 1: Kryptographische Methoden. A-SIT. 2014.

[3] IBM Knowledge Center: An Overview of the SSL or TLS handshake. http://129.33.205.81/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.sec.doc/q00993 0_.htm?lang=en. Aufgerufen am 11.01.2016.

[4] Network Working Group: RFC 5289 - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). http://tools.ietf.org/html/rfc5289. 2008.

[5] Network Working Group: RFC 4492 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). http://tools.ietf.org/html/rfc4492. 2006.

[6] Internet Engineering Task Force (IETF): RFC 6460 - Suite B Profile for Transport Layer Security (TLS). http://tools.ietf.org/html/rfc6460. 2012.

[7] Network Working Group: RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2. http://www.ietf.org/rfc/rfc5246.txt. 2008.

[8] OpenSSL Software Foundation: OpenSSL documents, ciphers. https://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES. Aufgerufen am 30.09.2014.

[9] Microsoft: Cipher Suites in Schannel. http://msdn.microsoft.com/en- us/library/windows/desktop/aa374757%28v=vs.85%29.aspx. Aufgerufen am 11.01.2016.

[10] Qualys SSL Labs. https://www.ssllabs.com/index.html. Aufgerufen am 11.01.2016.

[11] The Sprawl: TLS and SSL Cipher Suites. http://www.thesprawl.org/research/tls-and-ssl- cipher-suites/. Aufgerufen am 11.01.2016.

[12] A-SIT: SSL/TLS Test. http://demoapps.a-sit.at/ssl-tool/. Aufgerufen am 11.01.2016.

[13] Qualys SSL Server Test. https://www.ssllabs.com/ssltest/. Aufgerufen am 11.01.2016.

[14] Qualys SSL/TLS Capabilities of Your Browser. https://www.ssllabs.com/ssltest/clients.html.

[15] W3Counter: December 2015 Market Share. http://www.w3counter.com/globalstats.php?year=2015&month=12. Aufgerufen am 11.01.2016.

[16] Netcraft: December 2015 Web Server Survey. http://news.netcraft.com/archives/2015/12/31/december-2015-web-server-survey.html.

[17] RSA Laboratories: PKCS #12: Personal Information Exchange Syntax Standard. http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs12-personal-information- exchange-syntax-standard.htm. Aufgerufen am 14.01.2016.

[18] RSA Laboratories: PKCS #7: Cryptographic Message Syntax Standard. http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-7-cryptographic- message-syntax-standar.htm. Aufgerufen am 14.01.2016.

[19] The Heartbleed Bug. http://heartbleed.com/. Aufgerufen am 14.01.2016.

[20] Tracking the FREAK Attack. https://freakattack.com/. Aufgerufen am 11.01.2016

[21] Breachattack. http://breachattack.com/. Aufgerufen am 06.01.2014.

[22] Florian Weimer: Factoring RSA Keys With TLS Perfect Forward Secrecy. https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf. Aufgerufen am 13.01. 2016

[23] IBM: IBM Global Security Kit (GSKit) 8.0.14 Security Target. Version 3.5. 2012.

[24] Oracle: Java Cryptography Architecture Oracle Providers Documentation for JDK 8. http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html.

[25] Oracle: Oracle Products and Services. http://www.oracle.com/us/products/index.html.

[26] Oracle: Oracle® Fusion Middleware Administering Security for Oracle WebLogic Server 12.2.1.http://docs.oracle.com/middleware/1221/wls/SECMG/ssl_overview.htm#SECMG718.

[27] Oracle: Oracle® Fusion Middleware Administering Oracle Traffic Director. http://docs.oracle.com/middleware/1221/otd/admin/security.htm#OTADG235. Aufgerufen am 11.01.2016.

[28] Internet Enginnering Task Force (IETF): RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). https://tools.ietf.org/html/rfc7525. Mai 2015. Aufgerufen am 11.01.2016

[29] Android. Distribution of Android operating systems used by Android phone owners in October 2015, by platform version. http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices- with-android-os/. Aufgerufen am 11.01.2016.

[30] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann 22nd ACM Conference on Computer and Communications Security (CCS ’15), Denver, CO, October 2015 https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

[31] Guide to Deploying Diffie-Hellman for TLS https://weakdh.org/sysadmin.html Aufgerufen am 11.01.2016

[32] Bettercrypto.org: Applied Crypto Hardening. https://bettercrypto.org/static/applied-crypto- hardening.pdf. Aufgerufen am 11.01.2016.

[33] Google: This POODLE bites: exploiting the SSL 3.0 fallback. http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl- 30.html. Aufgerufen am 17.10.2014.

Anhang A: Cipher-Suites

Die folgende Tabelle enthält eine möglichst vollständige Auflistung verfügbarer Cipher-Suites. Zu jeder Cipher-Suite sind deren Eigenschaften wie zugrundeliegende SSL/TLS-Protokollversion und verwendete Algorithmen und Schlüssellängen angeführt. Jene Cipher-Suites, die in diesem Dokument als empfehlenswert klassifiziert werden, sind entsprechend dem in diesem Dokument verwendeten Farbschema farblich markiert.

0x00C075 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 Erweiterung zu TLS 1.2 ECDH ECDSA CAMELLIA_256_CBC 256 SHA384

Anhang B: Unterstützung von Cipher-Suites durch Web-Browser und Web-Server

Die folgende Tabelle enthält eine Auflistung jener Cipher-Suites, die von gängigen Web-Browsern und Web-Server-Software unterstützt werden. Die nachstehende Tabelle entspricht damit jener aus Anhang A, ist jedoch um jene Cipher-Suites reduziert, die von keiner der betrachteten Software-Komponenten unterstützt werden. In diesem Dokument empfohlene Cipher-Suites sind wieder entsprechend dem verwendeten Farbschema markiert.

Anhang C: Empfohlene Cipher-Suites

Die folgende Tabelle enthält alle empfohlenen Cipher-Suites. Alle angeführten Cipher-Suites erfüllen die in diesem Dokument definierten MUSS-Kriterien. Dunkelgrün hinterlegte Cipher-Suites erfüllen zusätzlich alle SOLL-Kriterien, bieten damit eine hohe Sicherheit und darüber hinaus eine adäquate Unterstützung auf gängigen Web-Browsern. Hellgrün hinterlegte Cipher-Suites bieten ebenfalls hohe Sicherheit durch Unterstützung aller MUSS- und SOLL-Kriterien, allerdings nur beschränkte Unterstützung auf Web-Browsern. Serverseitig können diese Cipher-Suites bedenkenlos unterstützt werden. Um die Client-Kompatibilität weiter zu erhöhen, können zusätzlich die orange hinterlegten Cipher-Suites serverseitig unterstützt werden. Diese bieten ein ausreichendes Maß an Sicherheit, erfüllen jedoch nicht alle in diesem Dokument definierten SOLL-Kriterien.